Re: On trusting its parent process

[Jonathan S. Shapiro]

On Tue, 2005-10-11 at 10:36 +0200, Ludovic Courtès wrote:

> 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.

I object to this design, but note that it is "object" with a lower-case
"o". There is nothing wrong with the security of this design.

My concern about this design has to do with long-term maintenance.
Somebody, sooner or later, will decide to "improve" the login mechanism
in some way. They will fail to understand the race condition here, and
they will make some change that involves re-opening the file.

For this reason, it would be better never to have the file name in the
first place.

> 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.

Precisely.

> 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.

Yes, but this is not a problem. This was done in KeyKOS too. I am not
concerned with what is authentic in your sub-environment until something
leaks out into the main environment.

shap