can't exec /usr/sbin/named-xfer: Permission denied
Brian Elliott Finley
brian at thefinleys.com
Tue Mar 27 23:46:08 UTC 2001
Thus spake Kevin Darcy (kcd at daimlerchrysler.com):
>
> Brian Elliott Finley wrote:
>
> > Thus spake Kevin Darcy (kcd at daimlerchrysler.com):
> >
> > >
> > > Linux has a system-call tracer, doesn't it? "strace" or something like that? Fire that up to
> > > determine *exactly* what named is trying to execute.
> >
> > I have run it (and named-xfer) successfully by hand. The problem is
> > trying to get named to invoke strace when it automatically invokes
> > named-xfer.
>
> Doesn't strace have a "follow" option, like Solaris truss'es "-f" option, i.e. follow child
> processes?
I'll take a look -- good idea.
>
> > This is actually a very interesting point:
> > o named-xfer by hand works
> > o named-xfer invoked by named does not
> >
> > What could be different about how named-xfer is invoked automatically?
> > The arguments I'm using when running it manually (yes chrooted in the
> > same way) are arguments I've taken from a properly running named-xfer
> > invoked by named (as seen through ps -auxwww).
>
> The only thing that comes to mind right now is to replace named-xfer with a "wrapper" that just,
> say, writes its argv[] to a file. This would at least tell you that named-xfer is being invoked.
Another good idea.
>
> By the way, you indicated that you're running an exploitable version (8.2.2-p7).
This is true...
> It's conceivable
> that what you are encountering is an aborted or incomplete attempt to create a trojan horse.
Possible, but not likely. I have a script that sets up the chrooted
environment everytime named is started. It would have to be getting
attacked immediately upon starting up *each* time I start it up during
my testing.
> To be
> on the safe side, I'd wipe out and reconstruct the chroot jail completely
Again, as stated above, this does happen every time named is started.
> and run a secure version
> of BIND in it. Then see if you still have the problem.
At this point I really want to figure out what's actually happening. I
definitely want to run a secure (for now) version of BIND, but I'm now
determined to diagnose this first. I think your ideas above should
allow me to do that.
-Brian
>
>
> - Kevin
>
> > > By the way, can you run that named-xfer binary while *manually* chroot()'ed?
> > >
> > >
> > > - Kevin
> > >
> > > Brian Elliott Finley wrote:
> > >
> > > > Still having the same issues. Any one have another suggestion?
> > > >
> > > > -Brian
> > > >
> > > > Thus spake Brian Finley (Home) (brian at thefinleys.com):
> > > >
> > > > > Thus spake Jim Reid (jim at rfc1035.com):
> > > > >
> > > > > > >>>>> "Brian" == Brian Elliott Finley <brian at thefinleys.com> writes:
> > > > > >
> > > > > > Brian> named works fine, but named-xfer consistently farts with
> > > > > > Brian> this message:
> > > > > >
> > > > > > Brian> "can't exec /usr/sbin/named-xfer: Permission denied"
> > > > > >
> > > > > >
> > > > > > Brian> named is started with this command:
> > > > > >
> > > > > > Brian> "/usr/sbin/named -d 3 -u bind -g bind -t /chrootd/bind"
> > > > > >
> > > > > > Brian> What am I missing?
> > > > > >
> > > > > > Try making sure /usr/bin/named-xfer lives in you chroot jail
> > > > >
> > > > > $ ls -l /chrootd/bind/usr/sbin/named-xfer
> > > > > -rwxr-xr-x 1 root root 203004 Nov 11 17:11 /chrootd/bind/usr/sbin/named-xfer
> > > > >
> > > > > > and has
> > > > > > sufficient execute permission for the uid bind.
> > > > >
> > > > > Yup.
> > > > >
> > > > > > And make sure that
> > > > > > named-xfer has proper access permissions to write any zone files it
> > > > > > transfers into the chroot jail.
> > > > >
> > > > > I've even tried doing a "chown -R bind.bind /chrootd/bind/*" to be
> > > > > sure...
> > > > >
> > > > > Same error.
> > > > >
> > > > > -Brian
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > -------------------------------------------------------
> > > > > Brian Elliott Finley VA Linux http://valinux.com/
> > > > > http://thefinleys.com/ phone: 972.447.9563
> > > > > http://systemimager.org/ phax: 801.912.6057
> > > > > CSA, C2000, CNE, CLSE, MCP, and Certifiable Linux Nut
> > > > > -------------------------------------------------------
> > > >
> > > > --
> > > > -------------------------------------------------------
> > > > Brian Elliott Finley VA Linux http://valinux.com/
> > > > http://thefinleys.com/ phone: 972.447.9563
> > > > http://systemimager.org/ phax: 801.912.6057
> > > > CSA, C2000, CNE, CLSE, MCP, and Certifiable Linux Nut
> > > > -------------------------------------------------------
> > >
> > >
> > >
> >
> > --
> > -------------------------------------------------------
> > Brian Elliott Finley VA Linux http://valinux.com/
> > http://thefinleys.com/ phone: 972.447.9563
> > http://systemimager.org/ phax: 801.912.6057
> > CSA, C2000, CNE, CLSE, MCP, and Certifiable Linux Nut
> > -------------------------------------------------------
>
>
>
--
-------------------------------------------------------
Brian Elliott Finley VA Linux http://valinux.com/
http://thefinleys.com/ phone: 972.447.9563
http://systemimager.org/ phax: 801.912.6057
CSA, C2000, CNE, CLSE, MCP, and Certifiable Linux Nut
-------------------------------------------------------
More information about the bind-users
mailing list