Re: Debian bug 531341
Nicolas,
Then I will try to remember this thread when I look again at this bug.
Hopefully soon.
We can summarize the conclusions and post that to the bug. How does that
sound?
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 --
pam_securetty.so was recently changed to include rejection of invalid
users. So it does not seems to my mis-interpretation but a different
interpretation of what pam_securetty.so is used for.
The PROPER behavior of pam_securetty is supposed to be that it returns
"failure" only when the user is "root" and the TTY is not "secure".
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.
This looks like a "required" pam_securetty.so
If I understand the current pam_securetty, yes.
2). A more modern solution where before the password is prompted,
the attempt is intercepted with a message such as "unauthorized
user".
I do not really understand solution 2.
You receive an "unauthorized user" only if the user is root.
Valid (but not root) and invalid users are prompted for a password.
Valid (but not root) users with a correct password are allowed to login.
Correct. Or any other user who requires a secure TTY.
This looks similar to a pam_securetty.so configured with:
[success=ok new_authtok_reqd=ok user_unknown=ok ignore=ignore default=die]
That's Greek to me. Despite repeated requests for funding, I was unable to
get AIX to use PAM while I was the AIX security architect. I understand
that the money was finally budgeted and PAM was doing more properly since I
left that department.
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
^^^^
"that" is either of solution 1) or 2), or only one of them?
Well, if either is acceptable, then so are "both", unless the actual profile
specified one or the other. Both are capable of working, one just works ...
differently. The primary difference is that UNIX systems always prompted
for the password. When the user didn't exist, the encryption spin was still
performed to prevent Timing Attacks as a means of performing an Enumerated
User attack. Since secure TTYs is now a standard feature, nothing is gained
or lost either way.
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.
From what I understand, you would recommend to change the default
/etc/pam.d/login to use a "required" pam_securetty.so.
Is that correct?
As I understand the current pam_securetty, that's correct.
This will cause the password to be asked for, but the login to be rejected
at the end.
The objective, in the long run, is to ALWAYS reject "root" on an insecure
TTY. How you achieve that objective has to fit in with the rest of the CAPP
profile, including the prevention of User Enumeration attacks.
Thanks a lot for this!
Not a problem! I wasn't able to kibitz with Shadow for 14 years while I
worked for IBM. But now that they've let me go, I plan to get involved
again. I like to think of the period as Shadow's "teenage years". It's now
22 years old and I figure it's time to be reunited with its mother ;)
-- Julie.
Reply to: