Re: [PATCH] fexecve

[Matt Thomas <matt%3am-software.com@localhost>]

On Nov 18, 2012, at 11:31 AM, Thor Lancelot Simon wrote:

> On Sun, Nov 18, 2012 at 07:27:27PM +0000, Julian Yon wrote:
>> On Sat, 17 Nov 2012 21:45:02 +0000
>> David Laight <david%l8s.co.uk@localhost> wrote:
>> 
>>> On Fri, Nov 16, 2012 at 12:52:30PM +0000, Julian Yon wrote:
>>>> 
>>>> What does this gain over passing a filename around? (NB. I'm not
>>>> claiming that's an entirely safe model either, but it's already
>>>> possible).
>>> 
>>> You don't need the executable image inside the chroot.
>> 
>> I don't believe that's intended to be possible, and if it is, I'm not
>> sure it's a gain.
> 
> I actually think it might be, if it didn't run the risk of blowing up
> code that wasn't written to expect it.
> 
> If we're going to commit this syscall at all, I think it should be
> accompanied by a new socket option for unix domain sockets, which
> defaults to "off", but if explicitly set to "on", allows file descriptors
> passed across the socket to be used for exec.

I assume that O_EXEC would need to be defined as 3 so that O_ACCMODE will work 
properly.  O_SEARCH would also need to be defined as an alias of O_EXEC (I 
don't think the current definition we use is correct).

Given that, you can't open a file for read & exec, just either read or just 
exec.  So how would verification work again?  Seems to me you need a fcntl that 
would allow you to change the access mode of the file descriptor.

One use of fexecve I can see is with named; it knows that it will need to 
fork/exec a few helper programs.  It can open these programs before doing
the chroot and then use fexecve to invoke leaving no executables inside the 
chroot as all.  So that if you managed to get compromise the named process, 
there is nothing named can do since in the chroot there is nothing to run.