Re: fexecve

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Sun, Sep 08, 2019 at 06:27:11PM -0000, Christos Zoulas wrote:
> In article <20190908180303.GA6168%panix.com@localhost>,
> Thor Lancelot Simon  <tls%panix.com@localhost> 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