[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian bug 531341



Hello Julie,

On Mon, Jul 20, 2009 at 07:58:37PM -0500, tallgirl@austin.rr.com wrote:
> 
> I've taken the "bug" e-mail address out of the Cc list -- don't
> think this discussion would be productive there.

Then I will try to remember this thread when I look again at this bug.
Hopefully soon.

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

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.

> 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

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

This looks similar to a pam_securetty.so configured with:
[success=ok new_authtok_reqd=ok user_unknown=ok ignore=ignore default=die]

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

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

This will cause the password to be asked for, but the login to be rejected
at the end.

> -- Julie Haugh
> creator, Linux Shadow Password Suite.

Thanks a lot for this!

Best Regards,
-- 
Nekral


Reply to: