RHEL 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.
PAM modules are documented in the /usr/share/doc/pam-versionnumber/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 [user_unknown=ignore success=ok ignore=ignore default=bad] \ pam_securetty.so
This line means that root users can log in only from secure terminals as defined in the /etc/securetty file, and unknown users are ignored.
On the Job | A backslash in a command line "escapes" the meaning of the next character; in the preceding command, pam_securetty.so is added 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. |
On the Job | In older Red Hat distributions, 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.
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 6-9 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 6-9: 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. The five different control flags are described in Table 6-6.
control_flag | Description |
---|---|
required | If the module works, the command proceeds. If it fails, PAM proceeds to the next command in the configuration file-but the command controlled by PAM will still fail. |
requisite | Stops 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. |
include | Includes all module_type directives from the noted configuration file; for example, if the directive is password include system-auth, this includes all password directives from the PAM system-auth file. |
To see 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. In other words, if the root user runs the reboot command, the control_flag is sufficient, and 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-versionnumber/txts directory.
auth required pam_console.so
The second auth command is run only for nonroot users; it just governs permissions within the console. As described in the README.pam_console file, you can find more information about this module with the man pam_console command.
#auth include system-auth
The third line is commented out by default. If you make this line active, it includes the commands from 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 laptops or desktops without having access to the root account. |
This section refers back to the /etc/pam.d/login configuration file shown in Figure 6-9. 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 limits root user access to secure terminals as defined in the /etc/securetty file:
auth [user_unknown=ignore success=ok ignore=ignore default=bad] \ pam_securetty.so
The next line includes the commands from the system-auth PAM configuration file:
auth include system-auth
The system-auth configuration file shown in Figure 6-10 sets up environment variables and allows different users to log in. The next auth line from /etc/pam.d/login checks for accounts not allowed to log in as listed in the /etc/nologin file:
account required pam_nologin.so
Figure 6-10: The /etc/pam.d/system-auth configuration file
If the /etc/nologin file exists, regular users are not allowed to log into the local console. Any regular user that tries to log in gets to read the contents of /etc/nologin as a message.
The account and password commands in /etc/pam.d/login also refer to the /etc/ pam.d/system-auth configuration file:
account include system-auth password include system-auth
For more information, refer to the following account directives in /etc/pam.d/ system-auth:
account required pam_unix.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_permit.so
This refers to the pam_unix.so module in the /lib/security directory, which brings up the normal username and password prompts. Service users (with user IDs less than 500) are automatically logged in, without messages (which is why they have the /sbin/ nologin shell in /etc/passwd). The pam_permit.so module always returns success.
For more information on the /etc/pam.d/login password directives, you'll need to refer to the three password commands in /etc/pam.d/system-auth:
password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass \ use_authok password required pam_deny.so
The first command from this list allows the use of a previously successful password (try_first_pass) and then sets a maximum of three retries. The next command encrypts passwords using the MD5 algorithm, supports the Shadow Password Suite described in Chapter 1, allows the use of null (zero-length) passwords, allows the use of a previously successful password (try_first_pass), and prompts the user for a password (use_authok). If you've configured NIS, you'll see nis in this list as well. The password required pam_deny.so directive is trivial; as noted in README .pam_deny in the /usr/share/doc/pam-versionlevel/txt directory, that module always fails, so PAM moves on to the next directive.
Finally, there are six session commands in the /etc/pam.d/login file:
session required pam_selinux.so close session include system-auth session required pam_loginuid.so session optional pam_console.so session required pam_selinux.so open session optional pam_keyinit.so force revoke
The first and fifth commands deactivate and reactivate SELinux, just for this part of the login process. The second command includes session directives from system-auth, which can allow you to set limits on individual users through /etc/security/ limits.conf. The third command logs the user ID for audits. The fourth command manages file permissions while users are logged onto your Linux computer. The final command forces a unique session keyring, and revokes it when the session is closed (to close one more potential security hole).
Exercise 6-5: Configuring PAM
In this exercise, you can experiment with some of the PAM security features of Red Hat Enterprise Linux 5.
Make a backup copy of /etc/securetty with the following command:
# cp /etc/securetty /etc/securetty.sav
Edit /etc/securetty and remove the lines for tty3 through tty11. Save the changes and exit.
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?
Repeat step 3 as a regular user. What happens? Do you know why?
Use ALT-F2 to switch to virtual console number 2 and try to log in as root.
Review the messages in /var/log/secure. Do you see where you tried to log in as root in virtual console number 3?
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 (nonroot) users.
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, four settings are available for each PAM configuration command. To make sure that the command respects what you do with this module, you should use this directive first:
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
To understand how this works, 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 6-7.
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. |
On the Job | Based on the topic matter for the exam, this information in Table 6-7 is limited; for full details, see README.pam_listfile in the /usr/share/doc/ pam-versionnumber/txts directory. |
Thus, for the specified command (onerr=succeed), an error, strangely enough, 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 Exercise 6-6.
Exercise 6-6: Using PAM to Limit Access
You can also use the PAM 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:
account required pam_nologin.so
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
Access another terminal with a command such as CTRL-ALT-F2. Try logging in as a regular user. What do you see?
If the message flashes by too quickly for you, log in as the root user. You'll see the same message; but as the root user, you're allowed access.
Inspect the /var/log/secure file. Did your system reject the attempted login from the regular user? What were the associated messages for the root user?
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 (PAM is that secure).