I'm sponsoring this fast-track for Joep Vesseur, Pravas Kumar and myself.
It supersedes PSARC/2002/765, Enforcement of PASSREQ=YES, which was never
started.
It reflects the SAC PAM Policy and the long standing Solaris Security
Group's interpretation of PASSREQ=YES (the long shipping default defined
in /etc/default/login).
While GDM has always correctly enforced PASSREQ=YES, dtlogin and other
login paths may not have. The evaluation in 4619260, "S9 and S10 ; Unable to
login as root after installing core cluster of s9_53", points out that this
enforcement changes the long standing Solaris de facto behavior, thus
motivating of this fast-track is to have a record of the change rather
than just fixing a bug. The issue in 4619260 was that various Sun internal
setups assumed that there was no root password and therefore automatic
access as root could be assumed. The installer at S9 time didn't provide
for root password entry. Since S10, it does provide for root password
entry.
There are no interface taxonomy changes (in fact there are no new
or changed interfaces).
There is an open customer escalation against S10 for this change
(6494527 PASSREQ not always enforced), so a Patch release binding is requested.
The timer is set for 9 Jan 2008.
Happy Holidays,
Gary..
++++++++++++++++++++++++++++++++++
Details:
=======
Solaris has a flag "PASSREQ" (/etc/default/login), that determines whether
users that have an NULL password (i.e., no password has been set for the
user) are allowed to access the system. If PASSREQ is NO, passwords are
not required and password-less users can login to the system (even if only
to set a new password). If PASSREQ is YES, one would expect the system to
deny access to password-less users, at least for the services that honor
PASSREQ (login (telnet/rlogin), ssh and su). Solaris currently does not
enforce this, but instead requires the user to enter a new password.
Numerous bugs have commented on this issue, among those of interest and
still present in the database are:
Bugs filed when a similar change was integrated late in S9 because
installer didn't provide a root password entry:
4531426 (pam) broken login passwd feature breaks test
automation for new OSs
4615293 (pam) fix for 4533378 reintroduces 4531426
4619260 (utility) S9 and S10 ; Unable to login as root after
installing core cluster of s9_53
Bugs to be fixed by this case:
4621692 (utility) /bin/login does not honor PASSREQ value in
/etc/default/login
4652487 (pam) pam_unix_account does not honor
PAM_DISALLOW_NULL_AUTHTOK for root
4762262 (kerberosv5_bundled) login/rsh fail to login a system
which doesn't set passwd
5070350 pam_unix account allows users with blank passwords if
aging prevents change
6494527 PASSREQ not always enforced
Both the SAC PAM Policy and the long held Solaris Security Group's
interpretation of PASSREQ=YES is to pass the PAM_DISALLOW_NULL_AUTHTOK
flag to pam_authenticate(3PAM) and pam_acct_mgmt(3PAM) calls. In the
Solaris pam_unix_auth(5) and pam_unix_account(5) service modules,
PAM_DISALLOW_NULL_AUTHTOK means that the password string in the shadow(4)
database may not be empty (i.e., username::... is not allowed). The impact
of this proposal is that no existing account with an empty password,
including root, will be allowed to login.
This case proposes to fix this PASSREQ hiatus for all types of logins
that read PASSREQ from /etc/default/login (currently this is sshd,
login (thus also rlogin/telnet), su and dtlogin). GDM is the one exception
that currently implements PASSREQ correctly.
NOTE: the single-user login (sulogin(1M)) has a separate configuration
file not shipped in Solaris (/etc/default/sulogin) with an entirely
different meaning of the PASSREQ variable:
PASSREQ=NO access is granted without prompting for a password
PASSREQ=YES (default) prompt for a password. If there is no
password set for root, always allow access.
This project does *not* alter the functionality of sulogin.
Solaris has never inform users why their login fails, this project will
not change that behavior relative to PASSREQ=YES enforcement.
Risks:
======
A previous change that enforced PASSREQ for login(1M) in Solaris 9 met
much resistance, in particular from automated-install-and-test groups that
installed just the core cluster. The core-cluster installation did not ask
for a root password (hence the installed root password was NULL) and the
testers were faced with a system on which root could not login anymore, see
4619260 S9 and S10 ; Unable to login as root after installing core cluster
of s9_53
Since then, the landscape has changed. The integration of PSARC 2004/043,
Sysid changes for root password, all meta-clusters now ask for a
root-password. The only way to end up with an root account without a
password is to deliberately ignore the sysid-question (F2-out of it) or
to neglect setting the root password when jumpstart-installing (the
jumpstart install should either set the root password using sysidcfg,
or a finish-script).
There's still a risk of locking-out root users on existing systems that
are upgraded. The work-around is to boot single-user and set a root
password (or change PASSREQ to NO).
There's a risk that an administrator using passwd(1) -d (which removes
the contents of the password field) would expect the user to be able to
enter the system to change a password.
Mitigation:
==========
This project will warn during an interactive install if the user
does not set a root password.
This project will update the passwd(1) man page -d option.
The patch for the escalation and any update will include the updated
man page and a "What's New" noting the enforcement.
A full diff marked passwd(1) is in the case directory.
For reference, a login(1) man page is included in the case directory.
passwd(1):
SYNOPSIS
passwd [-r files] [-d | -l | -u | -N] [-f] [-n min]
[-w warn] [-x max] name
Privileged User Options
Only a privileged user can use the following options:
-d Deletes password for name and unlocks the
account. The login name is not prompted for pass-
word. It is only applicable to the files reposi-
tory.
+ If the login(1) option PASSREQ=YES is configured,
+ the account will not be able to login.
+ PASSREQ=YES is the delivered default.
-f Forces the user to change password at the next
login by expiring the password for name.
NOTES
+ An account with no password, status code NP, may not be able
+ to login. See login(1) PASSREQ option.
