In article <20190908183938.ga25...@panix.com>, Thor Lancelot Simon <t...@panix.com> wrote: >On Sun, Sep 08, 2019 at 06:27:11PM -0000, Christos Zoulas wrote: >> In article <20190908180303.ga6...@panix.com>, >> Thor Lancelot Simon <t...@panix.com> 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?
Let us not forget that you need a binary inside the chroot that can call fexecve() on a file descriptor or the ability to build such a binary. christos