Solaris builds upon basic UNIX authentication by allowing systems administrators to configure password policy and expiration, the methods by which an account may be accessed, and the search order for authentication credentials.This section will discuss some of these features, including their strengths and weaknesses.
Password policies that can be configured include minimum password length, whether a change is required at first login, whether the password expires and how much prior warning is given before a change is forced, and whether an account may be accessed by login or only by su.The circumstances under which certain policies are appropriate are varied and site-specific.This section seeks to illustrate the configuration options available, as well as explaining how to set them.
Admintool allows easy configuration of these options for each user. However, managing a large number of accounts with Admintool would be cumbersome and time-consuming. It is better to understand how Solaris determines account and authentication policy, in order to ease configuration for large domains.
Three key files determine how Solaris user authentication and policy operate. The first, /etc/default/login, controls a variety of security settings at login.Table 4.2 explains the purpose and security implications of each of these settings.
Table 4.2Login Policy Variables
Variable Purpose
CONSOLE If set to YES, this restricts root logins to the system console. Root cannot log in over rlogin, rsh, or Telnet. This does not prevent a user login followed by su. This feature is useful to prevent mistakes by novice systems administrators or to prevent the use of an .rhosts file created to automate a task.
SYSLOG If set, root logins are logged at LOG_AUTH and multiple failed login attempts are logged at LOG_CRIT.
UMASK Initial shell umask. By default, 022. More restrictive sites may want to set this to 027 or 077.
SLEEPTIME The time to wait, in seconds, before a login failure is returned and another login may be attempted. The default is four seconds; the maximum is five. Setting this value to zero can simplify brute-forcing of accounts or denial of service by exhausting processes or ptys.
TIMEOUT Sets the length of time, in seconds, before an incomplete login attempt is rejected.
ALLOW_AGED_PASSWORD If set, and a password has expired, the user will still be permitted to log in. If set to NO, an expired password that has not been changed will reject a login attempt.
PASSREQ If set, a login account will require a password. This feature forces certain accounts to be accessed only by su, which provides a useful audit trail.
PATH Sets the initial path for a login process. This can provide security or convenience. The default value errs on the side of security by providing a limited search path to regular commands. The second file, /etc/default/su, controls the behavior of the su command in a manner similar to that of /etc/default/login.Table 4.3 shows the options available for this file.
Table 4.3 Policy Variables for the su Command Variable Purpose
SULOG If present, this variable specifies the file to which all su attempts are logged. It is valuable to periodically gen- erate reports from this file.
CONSOLE If YES, all attempts to su root are logged to the system console.
SYSLOG and PATH Same as shown in Table 4.2, for /etc/default/login. The last file, /etc/default/passwd, controls password policy. Its options are simple: the minimum and maximum length of time, in weeks, that a password is valid, and the minimum number of characters acceptable for a new password. Sites that make large use of password expiration policy may want to adjust the WARNWEEKS value, which isn’t shown in the file, to give users ample oppor- tunity to change their passwords.
During a login, Solaris checks /etc/pam.conf for a service name (see the PAM section). If one is found, the PAM modules specified for that service are loaded. In the case of pam_unix, which handles traditional UNIX authentication, the PAM solicits a username and password through the appropriate interface (tty or dtlogin, for example). Solaris must then recover the user’s credentials in order to validate that the user exists and has presented the correct password.This begins a search process through files, NIS, or NIS+, which is controlled by /etc/nsswitch.conf. A typical entry for password hash searches (as returned to the getpwnam [3C] and getspnam [3C] calls) in /etc/nsswitch.conf is:
passwd: files nis
Table 4.2Continued
This search order implies that /etc/passwd and /etc/shadow are searched first for the user’s credentials. If no entries are found, NIS is searched next. If no entries are found there, the system call fails and the user is rejected as unknown. Otherwise, the password presented at login time is hashed and that hash is com- pared with that returned by the search. If they match, the user is authenticated and login proceeds.
There are other valid entries in nsswitch.conf. Entering nisplus causes a search of the NIS+ password database.The keyword compat may be used, with no other options, to cause the system to operate in a mode compatible with BSD password file syntax for netgroup inheritance (see sidebar).
Other PAM modules may operate differently, but the majority of user authentication schemes in use involve gathering a username and password from the user, providing that to an authentication service for validation, and then accepting or denying the login as appropriate.There are other feasible methods, but the overwhelming majority of e-mail clients, secure shell clients, FTP clients and the like are designed with username/password pairs in mind. Kerberos is dif- ferent in that it uses cryptographic credentials for authentication; that will be dis- cussed later in the chapter.
As is the case with any form of authentication that uses reusable credentials, services that are subject to network eavesdropping pose a serious security risk. Secure alternatives exist for shell access, X-windows connection forwarding, POP and IMAP access, and file transfers.These alternatives, usually a Secure Shell client or an SSL-capable mail client, protect passwords from network spies by cryptographically covering the entire channel. Any clear text service that operates with reusable passwords is at risk for snooping. (One-time password systems like OPIE, S/key, or secured are the exception.)