Certification Objective 10.03: The Pluggable Authentication Module (PAM) System

---

RHEL 3 uses the Pluggable Authentication Modules (PAM) system to check for authorized users. PAM includes a group of dynamically loadable library modules that govern how individual applications verify their users. You can modify PAM configuration files to suit your needs.

Exam Watch 

PAM modules are documented in the /usr/share/doc/pam-0.75/txts directory. For example, the functionality of the pam_securetty.so module is described in the README.pam_securetty file.

PAM was developed to standardize the user authentication process. For example, the login program uses PAM to require usernames and passwords at login. Open the /etc/pam.d/login file. Take a look at the first line:

auth  required    pam_securetty.so

This line means that root users can log in only from secure terminals as defined in the /etc/securetty file.

On The Job 

In older versions of Red Hat Linux, the full path to the PAM module was required. It is now understood that these modules are stored in the /lib/security directory.

The configuration files shown in the /etc/pam.d directory are named after applications. These applications are 'PAM aware.' In other words, you can change the way users are verified for applications such as the console login program. Just modify the appropriate configuration file in the /etc/pam.d directory.

Pluggable Authentication Modules (PAM) and Associated Files

The PAM system divides the process of verifying users into four separate tasks. These are the four different types of PAM modules:

• Authentication management (auth) Establishes the identity of a user. For example, a PAM auth command decides whether to prompt for a username and or a password.

• Account management (account) Allows or denies access according to the account policies. For example, a PAM account command may deny access according to time, password expiration, or a specific list of restricted users.

• Password management (password) Manages other password policies. For example, a PAM password command may limit the number of times a user can try to log in before a console is reset.

• Session management (session) Applies settings for an application. For example, the PAM session command may set default settings for a login console.

The code shown in Figure 10-3 is an example PAM configuration file, /etc/pam.d/login. Every line in all PAM configuration files is written in the following format:

module_type  control_flag  module_path  [arguments] 

Figure 10-3: The PAM /etc/pam.d/login module

The module_type, as described previously, can be auth, account, password, or session. The control_flag determines what PAM does if the module succeeds or fails. The module_path specifies the location of the actual PAM module file. Finally, as with regular shell commands, you can specify arguments for each module.

The control_flag field requires additional explanation. It determines how the configuration file reacts when a module flags success or failure. There are four different control flags, as described in Table 10-3.

Table 10-3: PAM Control Flags

control_flag	Description
required	If the module works, the command proceeds. If it fails, go to the next command in the configuration file-but the command will still fail.
requisite	Stop the process if the module fails.
sufficient	If the module works, the login or other authentication proceeds. No other commands need be processed.
optional	PAM ignores module success or failure.

To demonstrate how control flags work, take a look at the commands from the /etc/pam.d/reboot configuration file:

auth   sufficient    pam_rootok.so

The first auth command checks the pam_rootok.so module. If the root user runs the reboot command, the control_flag is sufficient, the other auth commands in this file are ignored. Linux runs the reboot command. This is explained in the README.pam_rootok file in the /usr/share/doc/pam-0.75/txts directory.

auth   required    pam_console.so

The second auth command is run only for nonroot users; it just governs the console parameters at the command line interface. As described in the README.pam_console file, you can find more information about this module with the man pam_console command.

#auth   required    pam_stack.so service=system-auth 

The third line is commented out by default. If you make this line active, it refers to the system-auth configuration file, which requires root user privileges. Remote users who know your root password are still allowed to reboot your computer.

account   required    pam_permit.so

The module associated with the account command (pam_permit.so) accepts all users, even those who've logged in remotely. In other words, this configuration file would allow any root user, local or remote, to reboot your Linux computer.

Alternatively, you might add the pam_securetty.so module, which would keep remote users from rebooting your system. This module is described in more detail earlier in this chapter.

On The Job 

While it's not normal to allow just any user to shut down a corporate server, you may want to do so on a Linux workstation. In this way, users can shut down their own laptop or desktop without having to know the root account.

PAM Configuration Example: /etc/pam.d/login

This section refers back to the /etc/pam.d/login configuration file shown in Figure 10-3. When a user opens a text console and logs in, Linux goes through this configuration file line by line. As previously noted, the first line in /etc/pam.d/login:

auth  required    pam_securetty.so

limits root user access to secure terminals as defined in the /etc/securetty file. The next line brings the login program through the following service, system-auth, which also happens to be a PAM configuration file.

auth  required    pam_stack.so service=system-auth

Essentially, this calls the auth commands in the /etc/pam.d/system-auth configuration file shown in Figure 10-4. This sets up environment variables and allows different users to log in.

auth  required    pam_nologin.so 

Figure 10-4: The /etc/pam.d/system-auth configuration file

The last auth line from /etc/pam.d/login checks the /etc/nologin file.

account   required    pam_stack.so service=system-auth password  required    pam_stack.so service=system-auth

The account and password commands in /etc/pam.d/login also refer to the /etc/pam.d/system-auth configuration file. For more information, refer to the account command in /etc/pam.d/system-auth:

account  required    /lib/security/$ISA/pam_unix.so

Exam Watch 

If the /etc/nologin file exists, regular users are not allowed to log into your console. Any regular user that tries to log in gets to read the contents of /etc/nologin as a message.

\This refers to the pam_unix.so module in the /lib/security directory. The value of $ISA is normally null (empty), so you can ignore this variable. The pam_unix.so module sets up the normal username and password prompts.

For more information on the /etc/pam.d/login password command, you'll need to refer to the three password commands in /etc/pam.d/system-auth:

password required   /lib/security/$ISA/pam_cracklib.so retry=3 type=  password sufficient /lib/security/$ISA/pam_unix.so nullok use_authok md5 shadow nis password required   /lib/security/$ISA/pam_unix.so 

The first command from this list sets a maximum of three retries. The next command allows the use of null (zero-length) passwords, prompts the user for a password (use_authok), encrypts passwords using the MD5 algorithm, supports the shadow password suite described in Chapter 1, and allows the use of NIS passwords.

Finally, there are two session commands in the /etc/pam.d/login file:

session   required    pam_stack.so service=system-auth session   optional    pam_console.so

The first command refers to the /etc/pam.d/system-auth configuration file, which can allow you to set limits on individual users through /etc/security/limits.conf. The second command manages file permissions while users are logged onto your Linux computer.

Exercise 10-1: Configuring PAM

In this exercise, you can experiment with some of the PAM security features of Red Hat Enterprise Linux 3.

1. Make a backup copy of /etc/securetty with the following command:

   # cp /etc/securetty /etc/securetty.sav

2. Edit /etc/securetty and remove the lines for tty3 through tty11. Save the changes and exit.

3. Use ALT-F3 (CTRL-ALT-F3 if you're running X Window) to switch to virtual console number 3. Try to log in as root. What happens?

4. Repeat step 3 as a regular user. What happens? Do you know why?

5. Use ALT-F2 to switch to virtual console number 2 and try to log in as root.

6. Restore your original /etc/securetty file with the following command:

   # mv /etc/securetty.sav /etc/securetty

One thing to remember is that the /etc/securetty file governs the consoles from where you can log into Linux as the root user. Therefore, the changes that were made do not affect regular (non-root) users.

Securing PAM by User

In this section, you'll learn how to configure PAM to limit access to specific users. The key to this security feature is the pam_listfile.so module in the /lib/security directory. As described earlier, there are four settings in each PAM configuration command. To make sure that command respects what you do with this module, the first parts of the command should be:

auth required pam_listfile.so

The way PAM limits user access is in the last part of the command-in the details. For example, if you added the following line to a PAM configuration file, access to the associated tool would be limited to any users listed in /etc/special:

auth required pam_listfile.so onerr=succeed item=user \ sense=allow file=/etc/special

On The Job 

A backslash in a command line 'escapes' the meaning of the next character; in the previous command, file=/etc/special is appended to the end of the command line. Due to limits in the format of this series, I've had to change the spacing of some lines and add backslashes to others.

To understand how this works, it's time to break this command into its component parts. You already know the first three parts of the command from the previous section. The switches that are shown are associated with the pam_listfile.so module, as described in Table 10-4. Based on the topic matter for the exam, this table is limited; for full details, see README.pam_listfile in the /usr/share/doc/pam-0.75/txts directory.

Table 10-4: Switches for the pam_listfile.so Module

pam_listfile Switch	Description
onerr	If there is a problem, tell the module what to do. The options are onerr=succeed or onerr=fail.
item	You can use this switch to limit access to a terminal (tty), users in a specific file (user), groups (group), or more.
sense	If the item is found in the specified file, take the noted action. For example, if the user is in /etc/special, and sense=allow, then this command allows use of the specified tool.
file	Configures a file with a list, such as file = /etc/special.

Thus, for the specified command, (onerr=succeed) an error returns success, (item=user) based on a specific list of users. If the user is in the specified list (file=/etc/special), allow that user (sense=allow) to access the specified tool. To see how this works, run through the steps in the following exercise.

Exam Watch\ 

Make sure you understand how Red Hat Enterprise Linux handles user authorization through the /etc/pam.d configuration files. When you test these files, make sure you create a backup of everything in PAM before making any changes, because any errors that you make to a PAM configuration file can disable your system completely (it is that secure).

Exercise 10-2: Using PAM to Limit Access

You can also use the Pluggable Authentication Module system to limit access to regular users. In this exercise, you'll limit access by adding one or more users to the /etc/nologin file. It should work hand-in-hand with the default /etc/pam.d/login security configuration file, specifically the following line:

auth  required  pam_nologin.so

1. Look for an /etc/nologin file. If it doesn't already exist, create one with a message such as:

   I'm sorry, access is limited to the root user

2. Access another terminal with a command such as CTRL-ALT-F2. Try logging in as a regular user. What do you see?

---