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 [email protected]
