[Somehow, my copy of Ludovic's note here was lost or deleted. Thankfully, it was forwarded to me! This reply will not preserve the mail server's discussion threading. Also, another long note. Please accept my apologies.]
Ludovic wrote: > LSM talks by Shapiro (on EROS and Coyotos) and Forsyth (on Plan 9) were > quite insightful. I just found this followup: > http://www.coyotos.org/pipermail/coyotos-dev/2005-July/000138.html . > > What strikes me in this message is this: > > 1. The *only* way that a process in plan-9 can obtain a capability is > from its parent. This is a problem if the capability refers to > important > state and the parent is untrusted. Consider, for example, that the > "passwd" program can no longer trust the content of /etc/passwd, > because > it has no way to know if it is receiving an authentic copy of the > file. [...] > Now, what does "authentic" mean in a system designed in such a way that > most system services can be replaced by the user? Should programs be > allowed to rely on a specific implementation of a given service? In the case of the EROS space bank, the program *must* rely on an implementation. More generally, any time that your program must make a guarantee of behavior of any kind, it necessarily relies on the behavior guarantees of its subprograms and servers. This is an implementation dependency, not an interface dependency. The idea that implementation dependencies do not or should not exist is simply silly. I think that a more useful question is: Given that implementation dependencies exist but are inconvenient, how can we architect a system that minimizes the need for them. In EROS, I can at least say that in practice these dependencies are very low level, and they mostly happen on things that are intrinsically system-wide. I will try to give a complete list in a moment, but here is an example: ignoring imaginary paper designs, it is hard to imagine a successful system in which there are competing allocators for bottom-level disk storage. If nothing else, they would need to coordinate to avoid stepping on each other. The problem in original Plan 9 (I am speaking of Plan 9 *before* factotum, which is really very elegant) is as follows: Following UNIX tradition, the 'su' program runs with magic privilege. In particular, it has the ability to switch user identities. The su program relies on being able to open the "official" password file in order to verify a password. This is done by opening "/etc/passwd". However, the user can mount over or replace /etc/passwd. In particular, they can replace it with a variant whose UIDs are correct but whose password has been altered to something the user knows. The user can therefore su to anyone at any time. This is almost as secure as NFS. :-) >From the perspective of the 'su' program, the difficult is that 'su' utterly relies on the fact that the password file is authentic. It can check that the format of the file is good, but it has no way to know if the file has been replaced entirely. In Plan 9, this is a case where the *identity* rather than the *interface* matters. To see how this problem of identity would generalize to code, imagine replacing the /etc/passwd file with a Hurd server that implements the file server but internally uses a database. Changing the implementation from file to code does not alter the fact that there is an "official" version, that substitution is possible, and that security relies on the ability to detect forgery here. In EROS [actually, I am now describing what was implemented in KeyKOS, but we planned to re-implement it in EROS], we are able to rely on global persistence and also on the fact that the instantiating (parent) process is not the only source of capabilities. This allows us to use a completely different design, and it lets us close the vulnerability by altering the protocol. The description that I am about to give has been simplified to remove some complications introduced by the possibility of multiple sessions. Since we do not have user ids, there is no program that is comparable to 'su'. I will instead describe what happens for login. Because window system sessions can be instantiated inside other windows recursively, there is a vulnerability that is parallel to the Plan 9 vulnerability if the password file is replaceable. Here is how we eliminate it. The KeyKOS password database consists of tuples of the form: (user-name, encrypted-password, session-restart-capability) Notice the session-restart-capability. That is the key to the solution. When the login protocol wishes to authenticate a new user, it already holds a capability to the password validation subsystem (which contains the database). The protocol is: authenticator->checkPass(user-name, alleged-password) => session-restart-capability | void-capability If a session restart capability is returned, this is re-attached to the window system and the windows reappear. The session restart capability is ONLY returned if the password checks. The system-level login program holds a capability to the password authenticator by prior introduction, so there is no way to replace the authenticator. However, an attacker could basically build a new system image using a newly created window system (think X-nest), instantiate and attach a new copy of the login program, but set it up with a *different* password agent. This is harmless, however, because if the attacker does not already have my session restart capability they cannot install it in the new password agent. And of course, if they *already* have it then there is no need to attack me. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
