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. These are just some thoughts, reactions are welcome. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
