Hi,
While reading the discussions of these days, I'm more and more thinking that
our setuid approach is wrong, in that it shouldn't be a special case.
Setuid allows only UID-based operations. While most things can work from
this, it will be insecure in general (is my intuition, I don't have specific
examples at the moment). So let's analyse the situation.
* What is the problem that setuid wants to solve?
Some processes should be able to instantiate other processes, which have more
permissions than they do themselves. Assuming a capability system, they
should have some capabilities that the instantiator doesn't have.
* Why isn't setuid a good solution?
Setuid solves this by giving them a specific UID (which is really a capability
bin, holding a lot of capabilities, most of which aren't actually needed in
any specific situation). On a capability based system, this is not optimal:
we would want to give only the capabilities that are needed.
But even with this approach there are problems: Assume we want a (semi)secure
login application, which only holds the UIDs of normal users, but not of root.
Obviously root will not be able to log in with it, but that's the whole point.
How would we do this with setuid? It isn't possible: setuid only has a place
for one UID, no more. So it will need to be setuid root anyway, since that's
the only UID which can change into other users.
This problem becomes even worse when doing the real capability approach: While
a UID gives way too many capabilities, having just one is almost always too
few.
* What would be a better solution?
It is probably obvious to anyone who read the discussion (or the subject line
of this e-mail :-) ), that we want a system which works like setuid, but on a
capability basis, and allowing to pass more than one capability. Reading
Shapiro's explanation of EROS constructors, that's exactly what they do.
However, I don't think we want it for all programs. Most programs should just
get all their capabilities from their parent, so they cannot accidentily get
more rights than their parent had.
On a UNIX system, setuid should be a sparsely used operation, because of
security concerns. While the security concerns of "setcapabilities" are much
less, I think it is a good idea to use it sparsely anyway.
* How can we do it?
The newly created process must get its capabilities from somewhere. Obviously
it must be a source which holds the capabilities. I think creating a
"constructor server" would be a good idea. This is very similar to the EROS
constructor.