Hi, Due to lack of time, I'll make a short reply. ;-)
"Jonathan S. Shapiro" <[EMAIL PROTECTED]> writes: > 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 not unlike what exists in the Hurd. A password server is started at boot time and is attached to the `/servers/password' node. The `login' program is started shortly after, it looks up `/servers/password' and gets a capability to the password server this way. Now, whatever the user does, the "real" `login' already has a capability to the "real" password server which itself has a capability to the "real" root filesystem (since it is an essential service and got created first). If a user launches a new password server in a chroot, then that password gets run with this user's ID and it will not be able to give back "authentication caps" (user IDs) other than this ID anyway. As for `/etc/passwd', in a persistent system, it certainly doesn't need to exist: this is state that is private to the "authenticator" or "password server" and should remain private. In the Hurd, there's another issue (flexibility, again ;-)), namely the fact that users may run "sub-hurds". This makes the notion of "authenticity" all relative. Marcus raised this issue here: http://lists.gnu.org/archive/html/l4-hurd/2005-07/msg00040.html . Thanks for your reply, Ludovic. _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
