Re: fexecve

[christos%astron.com@localhost (Christos Zoulas)]

In article <20190908183938.GA25294%panix.com@localhost>,
Thor Lancelot Simon  <tls%panix.com@localhost> wrote:
>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?

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