Nicolas,
I've taken the bug e-mail address out of the Cc list -- don't think this
discussion would be productive there.
I had a feeling you weren't going to be able to quote a source -- the
interpretation of the requirement is contradicting the clear intent of
another requirement. This means the interpretation is incorrect.
The purpose of the root password doesn't flow on an insecure line isn't to
prevent all possible root passwords from flowing on the line -- consider the
case where the user rot does exist, and root mistypes their password.
Your interpretation misses that case. Something is clearly wrong with the
interpretation, then.
The purpose is that the root user cannot sign in over a secure line,
regardless of whether or not the user knows the correct password. There are
two (equally valid) approaches --
1). The classic solution where root can enter the correct password, but the
login attempt still reports login incorrect because it has failed the
secure TTYs file test.
2). A more modern solution where before the password is prompted, the
attempt is intercepted with a message such as unauthorized user.
Depending on your CAPP profile, either may be appropriate -- when I was the
NSA Vendor Security Analyst for the first several IBM security evaluations
(I led four, as I recall), I used the more classical approach, and that was
approved both by the NSA and by whatever the German evaluation authority is
called (something like Government Agency for Security in Information
Technologies, only in German). We did TCSEC, ITSEC and CC evaluations, as
the different schemes all worked their way through the industry.
I wrote many of the secure interfaces in Shadow when I was working on the
B2/CMW evaluation of AIX 3.1S that never took place -- the secure TTYs
functionality in Shadow today meets all of the requirements up through at
least B2. Since CAPP is below the old TCSEC B2 requirements (MAPP is the
B-level requirements), there's no CAPP requirement for anything stronger
than secure TTYs.
Now, the risk from user enumeration attacks, which you are allowing because
of the login incorrect flow on an unknown user is fairly serious. So,
you've traded an attack that is successfully being prevented by the secure
TTYs mechanism (root can't login even if the attacker knows the root
password, unless the attacker has access to a secure line, and that violates
the Physical Protection / Controlled Access requirements in most CAPP
profiles), for one that can grant escalation of privilege -- attacker
performs User Enumeration attack, followed by Password Dictionary attack,
gains access, exploits local bug, escalates privilege.
-- Julie Haugh
creator, Linux Shadow Password Suite.
--
From: NicolasFrançois nicolas.franc...@centraliens.net
Sent: Monday, July 20, 2009 5:25 PM
To: tallg...@austin.rr.com
Cc: 531...@bugs.debian.org; debian-security@lists.debian.org
Subject: Re: Debian bug 531341
Hello,
On Mon, Jul 20, 2009 at 02:01:27PM -0500, tallg...@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
