Re: core statement on fexecve, O_EXEC, and O_SEARCH

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

On Wed, Dec 05, 2012 at 01:08:14PM -0500, Mouse wrote:
 > > This system call embodies a fairly fundamental shift away from the
 > > Unix model that object permissions are checked when you get a handle
 > > to an object -- not when you use that handle.
 > 
 > Actually, I think that's true only of file descriptors.

That may be, but it's still true of file descriptors. Traditionally
they're capabilities, and I really don't like the idea of rearranging
that arbitrarily and inconsistently.

I think to do this correctly, exec and search on file handles needs to
be handled the same as read and write: you must open with the
corresponding O_ flag, and that then gives you a capability that
remains valid until closed (or revoke(2)'d).

Because passing capabilities around is potentially dangerous, if we're
going to add new capabilities we need to either be certain that no
restrictions are needed, or add a mechanism to restrict capability
passing. Since we clearly aren't certain (if anything, we're certain
that restrictions are needed), someone needs to come up with a
mechanism.

There is a good bit of prior art we can take from in existing or
historical capability systems, so designing a suitable mechanism and
interface will probably take a bit of reading but shouldn't be very
hard. Just remember that the process root directory is also a form of
capability, and it shouldn't be that hard to figure out how to make
everything interact.

This does mean we aren't going to be POSIX-compliant on O_EXEC and
O_SEARCH (are there any other O_ flags involved?) but I think it's
become clear that this is inevitable. When we're done we can decide if
O_EXEC and O_SEARCH and the corresponding other bits should disappear
or not when _POSIX_SOURCE and friends are defined to request strict
POSIX.

We also need to decide if the process root dir and process current dir
are equivalent to file handles and are thus capabilities (meaning
search permission does not need to be checked again at use time) or
not. This could go either way and I don't currently have an opinion.

We're also going to need a way to encode capabilities such that they
can be passed down from syscall code into vfs and filesystem code.
When the only path requiring alternate forms of security check was
truncate, it was ok to deal with it on an ad hoc basis; but now there
are a lot of places that need to check either permissions or a
capability, and I really don't want to be doing it in anything other
than a systematic manner, especially in namei.

And, manu still hasn't reverted the broken O_SEARCH logic he committed
along with the *at calls. I guess I'm going to need to do that.

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