Re: On trusting its parent process

[Ludovic Courtès]

Hi,

Due to lack of time, I'll make a short reply.  ;-)

"Jonathan S. Shapiro" <address@hidden> 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.