This article is excerpted from the recently published book Hardening Linux, published by McGraw-Hill/Osborne, 2004, with permission from McGraw-Hill.
Use Pluggable Authentication Modules (PAM) to provide flexible authentication
Traditionally, Linux and other Unix-like systems simply authenticated users against an entry in the file /etc/passwd. Everyone had read-only access to the password file, and the encrypted passwords were available to anyone with access to the system. This simple design made password files vulnerable to “dictionary attacks,” an attack where the attacker would encrypt common words and compare his encrypted words with what was in the password file. If a match was found, the attacker then would know the password. As a countermeasure, Linux and other Unix-like systems changed from the standard password file to a “shadow” password file, where passwords were moved out of the traditional /etc/passwd file into a different file (typically /etc/shadow). Since the /etc/passwd file needs to be readable by any user on the system, moving sensitive password hashes out of the world-readable file limited the availability of the hashes to the root user only.
Many experts believe that having a single authentication mechanism for each service on the system (terminal logins, local logins, network logins, etc.) is too inflexible. Typically, each service needed its own authentication code or had to use the single mechanism available. PAM is the answer to inflexible single authentication mechanisms. PAM allows different modules to be added for authenticating new services and for adding new authentication mechanisms for old services. PAM can also be used to enable shadow file authentication for applications that don’t natively support it. PAM module information can be found in the following places on the Internet:
- The Linux PAM resource page at kernel.org
- The OpenWall PAM page, which is where pam_passwdqc and pam_mktemp live
- Freshmeat’s PAM section
Remember that PAM contains the keys to your system, so you should only run PAM modules that are from known sources and that you trust. Anything else may allow an attacker to access your system.
There are interesting modules for voice authentication, smart cards, tokens, and a host of other types. Make sure you either have a known good way to get in by experimenting on one service rather than a core function, or that you can boot to single user mode and recover the system if you decide to experiment.
Use PAM because …
PAM allows you to enable strong per-service authentication features, shadow passwords, stronger hashing functions, and change mechanisms due to changing system requirements. The flexibility comes with a small cost of increased complexity, outweighed by the benefits.
Enforce strict password requirements
You can use a PAM module to enforce strict password requirements. Many administrators don’t want their users’ passwords to be easy to guess, so they might require a strong password module to authenticate password changes.
Strong passwords are often difficult for users to remember. Their use should be weighed with the fact a user might write his password down and therefore accidentally make it available to a local attacker, balanced against remotely accessible services that may be open to common wordlist type “dictionary” attacks.
With PAM, you can require a user’s password to contain a certain number of non-alphabetic and non-numeric characters, and adhere to a specific length requirement. On a standard ASCII keyboard, there are 26 letters, 10 digits, 32 symbols, and the space character. While a two-character password is hardly strong enough for most purposes, if it were two alphabetic characters, an attacker would only have to go through 32 different combinations before exhausting the possibilities. If the password is any keyboard character, then the attacker has to go through 138 potential combinations. With longer passwords the difference is even more pronounced.
By requiring a password to not include dictionary words, an administrator can further reduce the amount of success an attacker can have either on a blind attack against a user’s account or even on “cracking” the password hash with a large dictionary program.
Enable wheel group access
BSD-style Unix systems use a special form of group access to decide which users can use the su command to gain root access. Users who are authorized to gain root access are added to a specific system group, and only those users can change to root to perform administrative functions. This group is typically named “wheel,” and Linux administrators can add a PAM module to enable wheel group access to their machines.
Limiting access to only people who need to be able to perform functions that require root permissions makes it more difficult for an attacker to gain escalated privilege through a non-privileged account, such as that of a web server’s process or a user who uses the same password on another compromised system.
Enable the use of a centralized authentication server
Some administrators like to enable a central authentication server, so that users can authenticate with one password to multiple systems, and that password only has to be maintained in a single place. The most common of these is the Windows domain account through a domain controller or Active Directory. Another popular choice is a RADIUS server. RADIUS is supported by many dial-up systems used by ISPs, and it is also supported by RSA’s SecureID ACE server protocol. An ACE server is a server that supports two-factor authentication using a hardware token that’s time synchronized to the server and a PIN that the user knows. Large corporations often use ACE/SecureID to authenticate to important systems where security is an issue. By changing which PAM module is used to authenticate, an administrator may use one of these centralized services without any application changes.
Correctly configure PAM to avoid compromise
It is very important to test all changes carefully when changing a service’s PAM configuration files.
Remove obsolete PAM configuration file
Originally, PAM used /etc/pam.conf as its configuration file. This is no longer the case unless the PAM default configuration directory does not exist. Therefore, you should either remove pam.conf if it exists on your system, or ensure that its directives match your security requirements. These days, PAM has all of its configuration information in a directory called /etc/pam.d.
Removing the file will ensure that a misconfigured system won’t allow unauthorized access. Simply changing the default file to match your security policy will ensure that if the /etc/pam.d directory is corrupted or accidentally removed, you’ll still be able to access the system without having to reboot into single user mode.
Also, if you administer lots of similar systems where older PAM configuration files are necessary, it may be easier to keep them all the same; however, upgrading to recent versions of PAM is strongly recommended.
Each service has its own configuration file in /etc/pam.d, named after the program or service. For example, the login application (/bin/login) is configured in /etc/pam.d /login. Application programmers define the service names of their applications?each service should install its own configuration file when you install that service. The operating system installers normally do this for you.
Configuration file format
Each non-comment line of a PAM configuration file consists of four possible arguments: a module interface, control flag, module path, and module arguments. Comments begin with a # symbol and continue to the end of the line.
So each line has the structure
interface control_flag module_path [module_arguments]
The module arguments field is optional and depends on the module and setup.
Here’s an example line that has only the first three fields:
auth required pam_unix.so
Module interface
Module interface is the PAM jargon for the type of authorization a module does. A PAM module may do just one or all four possible interfaces. Those interfaces are account, auth, password, and session. Each interface will be specified in the configuration file for a service if it’s appropriate for the module and the administrator wishes to use that interface.
- account The account interface checks to see if an account is authorized to use the system, which could mean checking to see if it exists, has expired, or is allowed access at a particular time or via a particular service.
- auth The auth interface authenticates a user. That can be by prompting for and then checking a password, a database, or another mechanism. auth modules are also allowed to set credentials such as group memberships or Kerberos tickets.
- password The password interface is for checking and setting password authentication.
- session The session interface configures and manages a user’s session. This may include housekeeping tasks like mounting directories, creating files, and so on.
Control flags
For each interface, the configuration file specifies a control flag, which determines what PAM does next based upon the result of the check performed. There are four control flags: optional, required, requisite, and sufficient.
- optional Optional modules do not affect the success or failure of the authentication unless there are no other modules for a particular interface.
- required A successful result must be returned for the user to continue. User notification doesn’t happen until all modules for an interface are satisfied.
- requisite A successful result must be returned for the user to continue. User notification happens immediately for failure of the first requisite or required module for an interface.
- sufficient A successful result combined with no failures of required or requisite modules allow for a good authentication, assuming no other modules follow. Failure of a sufficient module is ignored.
Module path
The module path tells PAM the location of the module. It is normally a full pathname, including the module name and extension, such as /lib/security/pam_unix.so. If no path is specified, PAM defaults to /lib/security to find the module. Please note that the module path may include the variable $ISA as shipped from the vendor. This variable is an artifact of Solaris PAM originally, where 32- and 64-bit modules would both be shipped, and it would be replaced at load time with the correct architecture value. Linux may use this value in the near future with the ia64 architecture machines, so if you remove it, document its removal. It is best to fully qualify the path to each module.
Module Arguments
If a module requires arguments, this is where they will go, such as db=/etc/login.db. Invalid arguments do not affect the login process and are simply logged to syslog.
This information is important for understanding PAM, but fortunately you don’t have to remember much of it once you’ve got things set up.
Backing up the configuration before making changes
If you have a pam.conf file, back it up by copying it to a new name. It’s easier to figure out who did the changes and when if you include initials and a date in the new filename.
cp -pr /etc/pam.conf /etc/pam.conf.040404.pdr
This will back up pam.conf to a file named pam.conf.040404.pdr. Copying the file back over the original will restore the original, which is accomplished like this:
cp ?pr /etc/pam.conf.040404.pdr /etc/pam.conf
The same technique works for backing up the /etc/pam.d directory:
cp ?pr /etc/pam.d /etc/pam.d.040404.pdr
For restoring the directory, if you’ve added additional service configuration files, you can copy individual files back to the original /etc/pam.d directory, copy all the files back over (which won’t overwrite any new files), or simply move the entire backup directory to restore to the original configuration. The last option would simply require the following command:
mv /etc/pam.d.040404.pdr /etc/pam.d
Recovering from catastrophic errors
If you accidentally delete your configuration files, you’ll find out that you can’t log on to your system anymore. If you don’t have backup files, don’t panic, simply boot into single user mode, and follow these steps:
cd /etc
mv pam.conf pam.conf.backup
mv pam.d pam.d.backup
mkdir pam.d
cd pam.d
vi other
Then type the following lines in insert mode (by pressing the I key):
auth required pam_unix.so
account required pam_unix.so
password required pam_unix.so
session required pam_unix.so
Then use the Esc key to get back to command mode, type :wq, and press the Return or Enter key.
This is the simplest PAM configuration. You can save the file other, then reboot the system and log on normally. At that point, you can restore your configuration from backups or reinstall the PAM collection from your distribution to regain the default configuration. It’s useful to back up the original settings prior to making changes, so that restoring a working configuration is easy.
In the second and final part of this article, we’ll do three things: check the framework, harden the basic services that we expect to authenticate to, and look at new PAM modules that might make our systems more secure.
Category:
- Security
