[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fexecve, round 2
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 Laight: david%l8s.co.uk@localhost
Main Index |
Thread Index |