Unfortunately I'm having a hell of a day. I can't respond to the message below in full -- yet. But just to clear up a few nits:
On Thu, Nov 15, 2012 at 09:46:13PM +0000, David Holland wrote: > On Thu, Nov 15, 2012 at 11:03:15AM -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? 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? What about file descriptors for setuid executables, passed to a receiver running in an environment where the entire accessible namespace is mounted nosuid? > 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. > 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). Thor
