With the introduction of Solaris 2.6, Sun embraced one of the most powerful authentication concepts to come along in recent years. Pluggable Authentication Modules (PAM), originally a Linux concept, abstract the authentication process
certain compromises must be made. Very few IMAP or POP servers or clients can handle pure, traditional Kerberos authentication by creden- tials. Most simply take a username and password and send them over the network in the clear for authentication to the KDC. This is no better than conventional password systems. There are few credentials man- agement systems for Windows or Macintosh, but most of the ones that are available were developed at major universities such as MIT, Stanford, Carnegie-Mellon, or the University of Michigan, and are tailored for their environments.
The lack of correctly Kerberized clients makes widespread use of pure Kerberos difficult. SEAM addresses a great many of these problems in a homogenous Solaris environment. As with all security elements, Kerberos illustrates the importance of risk assessment and risk manage- ment. Understand your weaknesses and your needs. Carefully evaluate whether a new security system will reduce your vulnerabilities or merely relocate them. This isn’t meant to discourage the use of Kerberos, but to encourage a cold, hard evaluation of your risks and the technologies used to minimize them. There is no doubt that some sites will find Kerberos to be the answer to their authentication needs.
away from programs like su, login, ftpd, and sshd. Instead, authentication is per- formed by a separate, modular process. At their most basic, PAM modules are responsible for answering the simple question, “Is this user allowed here?”
The PAM framework makes it possible to identify and restrict access to users by many unconventional methods. PAM exists to support one-time password sys- tems like S/key and SecurID as well as alternate authentication systems like Kerberos, LDAP, or Radius. PAM also enforces access by time of day, quota, incoming host, netgroup membership, or just about anything else.The PAM system creates a level of security flexibility that did not exist prior to its inven- tion. By modularizing the authentication system, software authors can simply interface with PAM and allow systems administrators to select the authentication method best suited for their environment.
There are PAM-aware services of every type. Most common FTP, POP, and IMAP servers support PAM.The native rlogin, rsh,Telnet, FTP, su, and even the dtlogin programs for Solaris are PAM-aware. OpenSSH and recent commercial SSH servers support PAM.This makes it easy to deploy a new authentication or authorization system across a wide range of machines.
We’ll start by looking at the default PAM configuration file, /etc/pam.conf. We’ll talk about the options in that file and how to tailor them for specific pur- poses, and use three examples to illustrate the functions of PAM. In the first example, we’ll use Casper Dik’s su_group0 PAM to prevent su attempts from users who are not members of group root. In the second example, we’ll disable .rhosts and hosts.equiv files, thus preventing your users from inadvertently com- promising your network. In the final example, we’ll see how to install and con- figure the PAM system to support a new IMAP server.
The PAM configuration file, seen in Figure 4.1, is divided up into a series of columns.
The login service, in the form of the /bin/login program, is PAM-aware under Solaris.When the login program begins, it contacts the PAM system, which loads the shared object pam_unix.so.1.This object is responsible for most authentication, authorization, and account maintenance under Solaris. It handles authentication through a rather conventional interface to the flat-file password maps, NIS, or NIS+. It can also handle password management, enabling the pass- word-changing process to proceed by verifying an old password, soliciting a new one, and updating the system accordingly.
Let’s look more closely at the following line from Figure 4.1: login auth required /usr/lib/security/pam_unix.so.1
The service column generally consists of the name of the service being pro- vided. Obvious cases include FTP,Telnet, rlogin, rsh, dtlogin, and su. In general, the name as PAM understands it corresponds to the common name of the service. One additional service is defined in the pluggable authentication system: other. Other is a wildcard service name intended to substitute for any PAM-aware program on the system that is not already defined in the pam.conf. It is there to ensure that newly installed pieces of software operate with reasonable measures of protection.
The next column after the service column is called the module type. In the previous example, auth describes the mission PAM is to perform. In this case, the login process will use pam_unix for authentication.Valid options and their mean- ings are shown in Table 4.4.
Table 4.4Module Type Values Module Type Description
Auth This module is used to perform authentication.
Password The module changes or resets authentication credentials. Account Account modules perform account management, including
expiration and locking.
Session Session management modules.
The third column is the control flag, required.This allows PAM to be stacked to perform different functions.The valid options are shown in the Table 4.5.
Table 4.5Control Flag Values Control Flag Description
Optional PAM modules flagged as optional need only succeed under certain conditions.
Sufficient This module is all that’s required to perform the task specified in the module type field.
Requisite The conditions imposed by requisite modules must be met before authentication can proceed. “Requisite” is some- thing of a misnomer. ”Prerequisite” would be a better term.
Required These modules must complete successfully. Some excep- tions are noted in the following bullet list.
Options stack according to the following rules:
■ The module stack is processed from the top down, in the order given in
the pam.conf.
■ If all requisite and required modules succeed, any errors generated by
sufficient or optional modules are ignored and authentication proceeds.
■ If any requisite or required module fails, the authentication process termi-
nates and returns the nature of the failure to the system. Failure codes can indicate to the system that an account is locked, nonexistent, inac- tive, or that a bad password or a password that need to be changed has been entered.
■ If no requisite or required modules are specified, at least one sufficient or
optional module must be passed successfully to proceed.
■ The requisite flag may cause a failure in special cases. In these instances, if
a requisite module fails, even when a prior required module succeeds, the authentication fails.
■ The sufficient flag may cause a success in special cases. If a sufficient
module succeeds, the PAM stack terminates successfully at that point and access to the service is allowed. Use of this control flag can be exceptionally dangerous, as it can allow access to a system without any form of user identification.The accidental substitution of sufficient for
requisite could, for example, allow any user in group root to su without
presenting a password.Therefore, systems administrators should be espe- cially wary of this flag.
In our first example, we’ll restrict su attempts to those administrators who are part of group root.This feature originally appeared in BSD-style UNIX systems like SunOS 4 and IRIX. Many sites want to prevent casual users from making su attempts, both because it reduces brute attacks against the root account and because it makes the authlog easier to read. (Solaris 2.6 reintroduced the su command, which has long failure delays and will not respond to control-C). Casper Dik wrote a simple PAM to emulate this feature. It can be found at www.science.uva.nl/pub/solaris/.
First, you’ll need to compile the PAM:
cc su_group0.c -o su_group0.so.1 -Kpic -G -lpam
This will generate a shared object file. Copy it to the default PAM location and set the appropriate permissions as shown in the following code example. As a security feature, the PAM system will ignore any module with loose permissions or unprivileged ownership.
# cp su_group0.so.1 /usr/lib/security
# chown root:other /usr/lib/security/su_group0.so.1 # chmod 755 /usr/lib/security/su_group0.so.1
Edit the /etc/group file and change the root line as shown in Figure 4.2. Open the pam.conf, and find the following line:
su auth required /usr/lib/security/pam_unix.so.1 Your new PAM will check the group membership of the person who launched the su command. If the intent is to su to root, the PAM determines whether that user is a member of group root. If so, the authentication process drops through to the next PAM in the stack. If not, an error is returned, indi- cating “You have no permission to su root.” In order for this to occur, the PAM must be a prerequisite of the authentication provided by pam_unix. It must be passed successfully before the user will even be prompted for root’s password. Therefore, you will need to add the following line immediately before the line shown above. Be sure to keep the original su entry as well.
Your pam.conf should now look like Figure 4.3.
Figure 4.2Adding a User to Group Root
This is an excellent example of a case where misuse or accidental use of the sufficient control flag could cause serious problems. Simply changing “requisite” to “sufficient” would allow any user in group root to su without requiring a pass-
word at all.
The next example will show how to disable hosts.equiv and .rhosts files entirely.These mechanisms were originally seen as a convenience, but they are now recognized as posing an unnecessary risk to the network. Additionally, in the event of an intrusion, they greatly increase the risk of spread (the ability of the attacker to jump from host to host). A better choice for single-sign-on or no- password access between systems is something that performs strong host and user authentication, like Kerberos or SSH.
Solaris includes a PAM whose sole purpose is to parse and interpret hosts.equiv and .rhosts files.This module, pam_rhosts_auth, can be safely commented out wherever it appears in the pam.conf.
For the final example, let’s suppose that you installed the latest IMAP server from the University of Washington. It is PAM-aware, supports SSL-encrypted connections, and handles a variety of mailbox formats. If compiled to support PAM, it is easy to substitute authentication methods. Suppose your users don’t have access to SSL-capable mail clients, so you’ve issued them SecurID tokens for all such remote, cleartext accesses to the network.You don’t want them to use their UNIX passwords for IMAP. Further, only those users with valid shells should be allowed access.
An entry at the top of the pam.conf will cause IMAP to check /etc/shells and require SecurID tokencodes instead of UNIX passwords:
imap auth requisite /usr/lib/security/pam_shells.so.1 imap auth required
/usr/lib/security/pam_securid.so.1
Anyone who has an invalid shell or is unable to present a valid SecurID PIN and tokencode will be rejected by the IMAP server.
Summary
Reliable user authentication methods and policies are at the heart of any secure system. Solaris provides many tools for improving authentication security and flex- ibility. It allows for a wide range of configurations to support su-only accounts, password expiration, and password strength restrictions. Role based access control (RBAC) allows systems administrators to define specific tasks and to delegate them in a secure manner, without the need to provide full-blown root access. NIS and NIS+ allow systems to participate as clients or servers in heterogeneous UNIX networks, while providing a secure authentication framework.With the development of the Sun Enterprise Authentication Mechanism, simple, reliable Kerberos deployments become possible.With Kerberos, services like rlogin and Telnet—normally among the larger security holes in any network—can be strongly authenticated and reliably secured. Finally, Pluggable Authentication Modules (PAM) allow systems administrators to select the authentication and authorization framework that best suits their environment. No longer slaved to username/password pairs stored locally on the system, PAM allows for easy migra- tion to Kerberos, one-time password systems, or simple integration with alternate authentication frameworks like SMB.
Solutions Fast Track
Creating Secure Group Memberships
; Solaris provides several groups at installation time. Most are reserved for system utilities and daemon processes.The sysadmin group allows access to Admintool. Generally, GIDs less than 100 are reserved for system default groups, as are GIDs over 60,000. Be aware that Admintool assigns a default group of 0, which is a serious security risk.
; Each user can be a member of one primary group and no more than 16 secondary groups.
; Roles-based Access Control (RBAC) is a new addition to Solaris 8. It allows systems administrators to delegate certain tasks to individuals or groups that were formerly reserved for the root user. RBAC attempts to address the all-or-nothing privilege set normally found on UNIX systems by providing a means to define new roles, delegate these roles to users or groups, and easily revoke such permissions.
Understanding Solaris User Authentication
; The three files in /etc/default, passwd, su, and login, control account and login policies.There, systems administrators can set default umasks, paths, password length restrictions, and password expiration periods.
; Solaris uses the /etc/nsswitch.conf file to determine the order in which information services such as flat files, NIS, or NIS+ are searched for authentication data.
Authenticating Users with NIS and NIS+
; Distributed authentication systems demand a best practices form of security, rather than a point-by-point review of weaknesses and solutions.
; The ideal network for distributed network databases is controlled
entirely by a single group of administrators. Users are not allowed to run their own machines on the secure network, nor are NIS or NIS+ services provided to such machines.
; Consider using SecureRPC to authenticate and encrypt RPC transactions.
; If SecureRPC is unavailable or unmanageable, consider using ipfilter or a portmapper replacement to prevent unauthorized access to RPC services.
; Keep UID 0 accounts local and rigidly protected. Root and root-like accounts should never be in NIS.
Authenticating Users with Kerberos
; Kerberos is an authentication system that relies on mutual trust of a secure third party, called the Key Distribution Center (KDC).The basic tenet of Kerberos is that the Kerberos principal, or password, never travels on the network, even in encrypted form.
; Kerberos Ticket Granting Tickets (TGTs) are held by the workstation in a file called the credentials cache.These tickets have configurable validity periods. As long as a TGT is valid, the user will not have to enter a password to connect to Kerberized services.This feature is called single- sign-on.
; By allowing for the secure exchange of a secret key between the KDC, a service, and the user, Kerberos makes encrypted versions of common applications like rlogin, rsh, and Telnet possible.
; The lack of Kerberized clients for the PC and Macintosh platforms, particularly among e-mail software, hinders its effective deployment at most sites.
; A PAM-authenticated login, or /usr/krb5/bin/kinit, creates a credentials cache. From then on, for the validity period of the cache, the Kerberized rlogin, rsh, rcp, and Telnet commands will not require a password.The use of the -x option can force these commands to create an encrypted channel.
; At logout, /usr/krb5/bin/kdestroy should be used to remove existing credentials caches.This prevents an attacker from potentially using a still valid ticket to masquerade as another user.