Linux locked accounts and PAM

[Max Bowsher]

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.

Max.

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