On Sun, Sep 08, 2019 at 06:27:11PM -0000, Christos Zoulas wrote: > In article <[email protected]>, > Thor Lancelot Simon <[email protected]> wrote: > >On Sun, Sep 08, 2019 at 01:23:46PM -0400, Christos Zoulas wrote: > >> > >> Here's a simple fexecve(2) implementation. Comments? > > > >I think this is dangerous in systems which use chroot into filesystems > >mounted noexec (or nosuid) and file-descriptor passing into the constrained > >environment to feed data. Now new executables (and even setuid ones) can > >be fed in, too. > > > >What can we do about that? > > - We can completely dissallow fexecve in chrooted environments. > > or > > - We can check the permissions of the mountpoint of the current working > directory in addition to checking the mountpoint of the executable's > vnode.
I'd like to figure out a way to make this _optional_ in chrooted environments because I think in a system designed to use it, it actually could provide a security enhancement. At the same time, I'm worried about the effect on systems designed as sketched out above but without this feature in mind. But I'm having trouble thinking through how it'd work. A flag of course and a test, but on what -- the receive side of the socket when the chroot's performed, perhaps? Or, maybe: 1) Find a way to take the properties of the listen socket from which the received-on socket was cloned into account; so if I chroot-then-listen and I don't have a writable, executable filesystem in which to create my listening socket, I can't receive an executable fd that way 2) At chroot time, block executable fd passing on any socket that hasn't been deliberately marked as "can receive executables" with fcntl Maybe those two in combination (neither looks easy, from my memory of the relevant code, particularly #1) would work? Thor
