[Pkg-shadow-devel] Bug#531341: Debian bug 531341

[Nicolas François]

Hello,

On Mon, Jul 20, 2009 at 02:01:27PM -0500, tallgirl at austin.rr.com wrote:
> 
> I think that you're confusing the requirement that unknown user names
> not be logged, because they might be a user's password with the
> non-existent requirement that all unknown user names be treated like
> "root" and not prompted for a password.

No, I was not mentioning the case where an user types her password instead
of her username.

> If you still think you're right, I'd like to see the source for the
> requirement.  I've been through a number of formal evaluations as the
> vendor lead (IBM) and we never had that requirement under any evaluation
> scheme.

I cannot point you to any source of requirements, except mine:
 1. root's password should not be transmitted on insecure lines
    => The password should not be prompted if login is on an insecure line
       and login thinks the user might be root.
 2. root can mistype her username
    => Any invalid user might be a mistyped "root"
 3. login should not leak information about the valid usernames on the
    system.
    => The user should be prompted a password whether the username is valid
       or not.

I do not think those requirements can be satisfied at the same time.


The current /etc/pam.d/login contains:
auth       requisite  pam_securetty.so

The intent is that if root logs on a non secure line, the PAM stack is
interrupted immediately (changing requisite to required would just make
the login fail, but other modules in the PAM stack would be triggered),
hence the user will not be prompted for a password, hence (hopefully) the
root password will not pass through this insecure line.

Now if root mis-type her username (let say rot instead of root),
pam_securetty.so will just notice that this is an unknown username, and
will still return with an error. The stack will also be interrupted
immediately to stop root from typing her password.

The right configuration depends on the risks defined by the admin.
If the admin knows that login might be used on insecure lines, then she
might prefer to use requisite. If she knows that there are no insecure
lines, required would be sufficient (and the line could even be commented
out).

If somebody eavesdrops on an insecure line and get the root password,
she can log in immediately.
If somebody manage to find what are the valid users on the system, the
accounts should still be protected by passwords.
This was the reason why I tent to favor the requisite rather than the
required.

I asked for pam_securetty not to reject unknown users on secure ttys, but
this request was rejected (sorry, no pointers).

So, I don't think there are any sane default that will work for any
configuration (from the login point of view, it is not just a matter of
code/configuration; it is just not possible to satisfy those three
requirements; one of them need to be removed/loosened)

 1. requisite is changed to required / pam_securetty is removed
 2. Use the following instead of requisite:
 [success=ok new_authtok_reqd=ok user_unknown=ok ignore=ignore default=die]
 3. The current solution, use requisite

(A 4th solution, which would be not to return PAM_USER_UNKNOWN when the
line is secure could be better, but I do not remember why it was rejected)

Since there are no good solutions, what would be the best for Debian?


Now let's see if debian-security has some ideas on what the default should
be...

Best Regards,
-- 
Nekral