can't exec /usr/sbin/named-xfer: Permission denied

[Brian Elliott Finley]

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
-------------------------------------------------------