Re: Design principles and ethics

[Jonathan S. Shapiro]

On Mon, 2006-05-01 at 00:33 +0200, Marcus Brinkmann wrote:

> You seemed to have missed a whole thread a couple of weeks ago.

This is probably true. I was working toward a deadline, and things were
very difficult. Much of the Hurd mail did not get read for two weeks.
Sorry.

> At Sun, 30 Apr 2006 18:13:07 -0400,
> "Jonathan S. Shapiro" <address@hidden> wrote:

> > 1. There are overwhelmingly compelling reasons to set policies against
> > stupid passwords.
> 
> It is a matter of judgement if such policies need to be administrator
> or system enforced.

Yes. And the experimental evidence in favor of the need for policy
enforcement about choices of password is overwhelming. However, I agree
(below) that your proposed mechanism seems like it should work.

> > This is why cracklib exists -- one bad password
> > endangers an entire system.
> 
> If this is true, then it is a defect in the system.
> 
> The fault is in using passwords.  Passwords and humans don't mix well.

I agree with both statements. However...

Accepting that it is a defect in the system, it remains a defect that we
do not, in principle, know how to fully address. We can mitigate it. We
can make systems more robust. We can make the potential damage less
severe. After all of these things are done, it remains true that we
simply have no solution for guarding sufficiently against the threat of
an attacker with authorized access.

I agree that passwords don't work very well with humans. Given that this
is true, I still do not anticipate that people will abandon them any
time soon. And of course, if a user can "plug in" an authentication
mechanism, most users will plug in a bad one.

In single-user systems this may be acceptable. I *hope* that Hurd might
work for multi-user scenarios as well. As a practical matter, I do not
know how to get rid of passwords within the next decade, and I do not
know how to fully defend a system with a malicious user who has
successfully authenticated.

I will say something stronger: in the entire field of computer security,
both in research and in practice, *nobody* knows how to sufficiently
defend this type of system.

> > This implies that even if the user owns the
> > password file, we wish to restrict the conditions under which that file
> > can be written. Indeed, using a purely user-defined authentication
> > methods are a bad idea because of this.
> 
> Here is a way to do it in the case where the user provides the
> password file, and the system reads it:
> 
> The system checks the conditions for the password that is _entered at
> the login prompt_, rather than the password in the file.
> 
> It is then the user's responsibility (with adequate support, of
> course) to set a password that complies to the conditions.

Yes, I think (provisionally -- still thinking) that this would work. I
also agree that it seems like a fundamentally better system structure
for authentication. In addition to everything else, it appears to
eliminate a single point of failure (the password database).

Very nice!

> > 2. I'm not sure how something like 'su fred' would be implemented in
> > this style of system.
> 
> You mean as sysadmin without entering a password?  No way, unless the
> user grants access to the sysadmin without a password (provided there
> is a mechanism to do so).

Umm. No. I meant *with* the password. The part I am confused about is
how 'su', which is spawned by me (therefore my child) gains read access
to all of those password files (which is equivalent to read access on
the password database).

I suspect your answer may be that 'su' is not spawned by me, and that I
have consistently failed to see this. If this is the answer, could you
confirm?

> > 3. What happens when the user accidentally deletes their password file?
> 
> The user can not login anymore.  Which is a good reason for not making
> it a normal file in the first place (among other reasons not to make
> it a normal file), but to have a dedicated service (which can still
> run in the user's space).

It occurs to me that this may not be what will happen.

The password "file" is a standalone object with two bindings: one in the
user directory and the other held by the login agent. If the user simply
unbinds their capability, then the situation is that they can still log
in but they can no longer change their password -- this is true because
the login agent has not lost *it's* capability.

This may still be the right thing, but it is decidedly weird!


shap