Re: fexecve, round 2

[David Laight <david%l8s.co.uk@localhost>]

On Sat, Nov 17, 2012 at 11:48:20AM +0100, Emmanuel Dreyfus wrote:
> Here is an attempt to address what was said about implementing fexecve()
> 
> fexecve() checks that the vnode underlying the fd :
> - is of type VREG
> - grants execution right
> 
> O_EXEC  cause open()/openat() to fail if the file mode does not grant
> execute rights
> 
> There are security concerns with fd passed to chrooted processes, which
> could help executing code. Here is a proposal for chrooted processes:
> 1) if current process and executed vnode have different roots, then
> fexecve() fails 

I'm not sure how you were intending determining that.
You can follow ".." for directories, but not files.

> 2) if the fd was not open with O_EXEC, fexecve() fails.
> 
> First point avoids executing code from outside the chroot
> Second point enforces W^X inside the chroot.

If we don't want to allow chroot'ed process to exec a file that
is outside the chroot, then maybe the kernel could hold a reference
to the directory vnode (in the file vnode) whenever a file is opened
for execute (including the existing exec() family of calls calls).

As well as being used to police fexecve() withing a chroot,
it could be used by the dynamic linker for $ORIGIN processing
(Probably by some special flags to openat().).

        David

-- 
David Laight: david%l8s.co.uk@localhost