Re: [PATCH] fexecve

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Nov 15, 2012 at 04:53:26PM -0500, Thor Lancelot Simon wrote:
 > >  > > Here is a patch that implements fexecve(2) for review:
 > >  > > http://ftp.espci.fr/shadow/manu/fexecve.patch
 > >  > 
 > >  > This strikes me as profoundly dangerous.  Among other things, it
 > >  > means you can't allow any program running in a chroot to receive
 > >  > unix-domain messages any more since they might get passed a file
 > >  > descriptor to code they should not be able to execute.
 > > 
 > > I have two immediate reactions to this: (1) being able to pass
 > > executables to something untrusted in a controlled manner sounds
 > > useful, not dangerous; and (2) please define your threat model,
 > > because you appear to be assuming the chrooted process is colluding
 > > with something outside the chroot, and if that's really true it
 > > already effectively has access to everything outside the chroot.
 > 
 > Are you sure you want to make that assertion with regard to "everything"?
 > What about two processes in separate chroots?

None of that matters; if the two processes are colluding, either can
do anything the other can, simply by asking the other to do it.

Which is why you need to define the threat model.

 > What about a process which
 > can read, but not execute, a file passing an open descriptor for it it to
 > a process running as a UID which has permission to execute it?

A correct implementation of fexec should not allow that, just as a
correct implementation of write does not allow writing to a passed
descriptor that came from someone without permission to open it for
writing.

 > What about file descriptors for setuid executables,

It should probably not be allowed to exec a setuid executable that
came from outside your chroot.

 > passed to a receiver running in an environment where the entire
 > accessible namespace is mounted nosuid?

This doesn't make any difference. Running a setuid executable in an
unexpected and possibly hostile environment is already dangerous.

 > > Granted we may want to put some controls on fd passing that don't
 > > currently exist.
 > 
 > It's not clear to me what such controls would avoid unexpected behavior
 > both for existing applications which use chroot and fd passing, and also
 > for applications written to use this new interface.

It's not absolutely clear to me either, but we've spent only a few
minutes thinking about it.

It seems worth spending a bit of time to see if there's a viable model
to be had before dismissing the whole thing as impossible.

 > > What mechanism prevents processes from calling mprotect with PROT_EXEC
 > > on their own memory?
 > 
 > We have a mechanism quite precisely for that -- see the "PaX MPROTECT"
 > section in security(8).

ok, I admit I had been under the impression that PaX didn't actually
do anything useful.

-- 
David A. Holland
dholland%netbsd.org@localhost