Linux locked accounts and PAM

[Dan Yefimov]

On 10.10.2008 11:57, Max Bowsher wrote:
> Solar Designer wrote:
>> On Wed, Oct 08, 2008 at 09:12:23AM +0200, Tomas Mraz wrote:
>>> 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.
>> While the above will simplify locking accounts (no need to check for
>> authorized_keys* files) and/or result in better security (some
>> meant-to-be-locked accounts will actually become locked in terms of SSH
>> access and maybe more), it is problematic in several ways:
>>
>> 1. There are plenty of systems and accounts that _intentionally_ have
>> their password fields locked (the string starts with "!"), but SSH keys
>> set up.  I am using plenty of such accounts myself.
>
> Agreed, this is an unfortunate consequence of there being two "era"s of
> defaults: "linux before PAM", and "linux with PAM", with sysadmins
> accustomed to one or the other dependent on experience. So yes, if we
> enhance pam_unix to be capable of fully respecting the semantics of the
> systems it replaces, it must be optional, because to many systems have
> since grown to rely on PAM's unwittingly changed convention.
>
>> 2. Allowing access for accounts with "*" in the password hash field,
>> while disallowing it for those with "!" as the first character, might be
>> wrong.
>
> What's wrong about this? I am _not_ suggesting that PAM do anything more
> complex than support the traditional convention of "first character of
> password == ! indicates entire account (not just password) is locked".
> It's purely about supporting traditional behaviour fully, not adding new
> features.
>
>> It will limit the extent of this new security measure to newly created
>> and locked accounts, all of which could use SSH keys on purpose.  The
>> new security measure will not apply to system-reserved accounts,
>> although there's usually no need to permit logins to those.  (Well, in
>> some cases it may make sense to "su" to them, and "su" may use the PAM
>> "account" stack too...)
>>
>> Yes, a similar change that is already in OpenSSH portable has resulted
>> in some people using "*" in the password hash field as a workaround (I
>> am aware of specific occasions), and I am sure that if Linux-PAM does
>> the same, even more people (admins) will be "manually" changing password
>> hash fields to "*" (or to start with a "*") to allow access with SSH
>> public key authentication.  However, this results in "*" no longer
>> representing system-reserved accounts only, which may be unfortunate.
>
> I was not aware anyone considered "*" as representing a system-reserved
> account. Can you please elaborate on why you think it should/does
> represent that?
>
>> Also, one has to deal with the password hash string, even if via the
>> proper tools, to configure an account like that.  "usermod -L" and
>> "passwd -l" are "admin-friendly" approaches; there's no equivalent that
>> would be as friendly for "*-locking" (and "*-unlocking") an account.
>
> Well, there's "usermod -p\* ACCT" and that has always been satisfactory
> for me.
>
>> 3. Dealing with password authentication and SSH access might not be
>> sufficient to ensure that the account has no other "backdoors" on it.
>> Other ways to retain / re-gain access to an account include cron jobs,
>> at jobs, .forward and .procmailrc files (invoking programs).
>
> Yes, but why is this relevant to the discussion at hand? PAM just needs
> to ensure its stacks behave appropriately, it is the responsibility of
> other applications to actually call them.
>
>> Unfortunately, this does not address the problem of not having a
>> convenient way to set individual accounts to "non-password
>> authentication only", while allowing for use of this new functionality.
>
> What's wrong with "usermod -p\*"? (Would need to be documented, of course.)
>
>> Alternatively, the meaning of "!" can be changed to "password locked"
>> rather than "account locked" (in fact, this will mostly bring the
>> documentation in sync with today's reality, with no code changes other
>> than to OpenSSH portable)
>
> My impression (which may be wrong, please correct me if so) is that the
> change in today's reality is only because this check got missed out of
> pam_unix when it was first written. As such, I prefer rectifying that
> oversight.
>
Interpretation of password hash field characters is itself arbitrary and 
consequently error-prone. pam_unix, as a portable (I hope) implementation, 
shouldn't admit any dependence on any arbitrariness. There should be a separate 
shadow field designed for account locking, but that will disagree with current 
standards. The portable and reliable account locking can be currently achieved 
by setting the account expiration date in the past, for example, 'usermod -E 0'. 
Why do you dislike/ignore that? Why did you go in cycles on the password hash 
field interpretation that much?
-- 

Sincerely Your, Dan.