Linux locked accounts and PAM

[Max Bowsher]

Dan Yefimov wrote:
> On Wed, 8 Oct 2008, Tomas Mraz wrote:
> 
>> On Wed, 2008-10-08 at 01:25 +0400, Dan Yefimov wrote:
>>> On 07.10.2008 2:40, Max Bowsher wrote:
>>>> I know about the special behaviour of "!" in a password field when SSH
>>>> is managing authentication itself. My point is that this special
>>>> behavior does NOT exist any more when SSH is authenticating via PAM -
>>>> but I want it to!
>>>>
>>> If SSH authentication does be performed via PAM (so called keyboard-interactive 
>>> authentication), you do have that behaviour. But, IIRC, you perform 
>>> authentication with SSH public key, which completely bypasses PAM infrastructure 
>>> at the authentication stage regardless of 'UsePAM yes' setting, thus the result 
>>> you observe. PAM has nothing to do with that. Please carefully read sshd_config 
>>> manual.
>> Not really - sshd will call pam_acct_mgmt() even in case of public key
>> authentication. The problem is pam_unix checks just the expiration dates
>> of the shadow entry, not the password hash field contents.
>>
> Password hash entry is implicitly checked at pam_authenicate() time, not at 
> pam_acct_mgmt() time. But pam_authenticate() is not called during public key 
> authentication. That's exactly what I said.

No, you're missing something: A password hash that begins with a !
character, by mostly undocumented but fairly widespread convention, has
a meaning beyond mere authentication - it denotes a completely locked
account. This semantic is expected by traditional Linux tools such as
those built from the 'shadow' source package of most Linux distros, and
extended tools such as Debian's 'adduser', which makes a distinction
between a disabled *account* and a disabled *password* and maps this to
 the "!" vs. "*" convention.

>> I think we should do the same as sshd on Linux without PAM enabled - it
>> will reject just the accounts with password hash that starts with the
>> '!'. We would not reject the accounts with '*' in the password hash in
>> the shadow entry.
>>
> SSHD rejects such accounts while performing password verification. If the 
> password hash for password provided by user isn't equal to what is contained in 
> shadow, access is denied. That's simple. I think there is no reason to 
> duplicate the job of auth stack compulsorily, but if somebody wants such 
> duplication, let him specify special pam_unix command line option in account 
> stack.

This isn't about password verification, or duplication of anything. It
is about implementing the semantics for the password hash field that I
describe above, which whilst admittedly mostly undocumented other than
in the behaviour of various common tools, are widespread in Linux
software other than PAM.

It might make sense for this behaviour to configurable via a pam_unix
command line option, because otherwise it may be too incompatible to
make in a 1.0.x release of PAM - I am not familiar with the PAM
project's compatibility policy. Were it not for compatibility concerns,
I would suggest that it should be unconditional, as it is a standard
facet of "traditional unix" security as applied to Linux, which is
exactly what pam_unix is all about.

Max.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/pam-list/attachments/20081008/904b964b/attachment.sig>