Re: fexecve, round 2

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sun, Nov 18, 2012 at 06:51:51PM +0000, David Holland wrote:
 >  >  > 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.
 >  > 
 >  > The standard is clearly wrong on a number of points and doesn't match
 >  > the historical design and behavior of Unix. Let's either implement
 >  > something correct, or not implement it at all.
 > 
 > Also it seems that the specification of O_SEARCH (and I think the
 > implementation we just got, too) is flawed in the same way - it is
 > performing access checks at use time instead of at open time.

So, for the record, I think none of these flags should be added unless
they behave the same way opening for write does -- the flag cannot be
set except at open time, and only if the opening process has
permission to make the selected type of access; once opened the
resulting file handle functions as a capability that allows the
selected type of access. Anything else creates horrible
inconsistencies and violates the principle of least surprise, both of
which are not acceptable as part of the access control system.

Also, it obviously needs to be possible to open files O_RDONLY|O_EXEC
for O_EXEC to be useful, and open directories O_RDONLY|O_SEARCH, and
so forth. I don't know what POSIX may have been thinking when they
tried to forbid this but forbidding it makes about as much sense as
forbidding O_RDWR, maybe less.

Someone needs to sit down and figure out what restrictions need to be
applied to fd passing to make this safe, both in general and in
connection with chroot. One point riastradh@ raised is that if you get
a fd for a directory outside your current chroot, you shouldn't be
able to use it to openat() or with any of the *at() calls. There is
currently no mechanism in place to enforce this.

I have a feeling that what we want may be not a restriction on
fd-passing sockets or a restriction on file handles, but a restriction
on chroots.

Also there was a thread back in February titled O_NOACCESS that
everyone interested in this stuff should review.

 > (Also the implementation we just got seems to be missing any access
 > check at open time -- this seems entirely wrong.)

It turns out to be unexploitable but it's definitely wrong in several
ways (unrelated to whether its semantics are poorly chosen); I have
asked for it to be reverted.

-- 
David A. Holland
dholland%netbsd.org@localhost