Re: fexecve, round 2

[Thor Lancelot Simon <tls%panix.com@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 
> 2) if the fd was not open with O_EXEC, fexecve() fails.

This appears to contradict either the description of O_EXEC in the
standard, or the standard's rationale for adding fexecve().  The
standard says O_EXEC causes the file to be open for execution "only".

In other words, O_EXEC means you can't read nor write the file.  Now
the rationale for fexecve() doesn't hold, since you cannot read from
the fd, then exec from it without a reopen.

Further, requiring O_EXEC would seem to directly contravene the
standard's language about fexecve()'s behavior.

Since the principal reason why we should add this is allegedly standards
conformance I can't see how adding a nonconformant implementation of
O_EXEC or fexecve fits with the overall goal here.

This to me is illustrative of the danger of slavishly substituting the
XPG group's technical judgment for our own.  They frequently standardise
poorly thought out Linux hacks; twisting ourselves into knots to make
what they half-designed safe, at which point it doesn't conform to their
standard any more, does not seem like a good general plan to me.

(If we're really going to go down this road, I did make an alternate
proposal for making fexecve() safer in the presence of file descriptor
passing, one that I think doesn't break stuff that's in the standard;
did you see it?)

Thor