[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [PATCH] fexecve
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
> 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
Main Index |
Thread Index |