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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
