Certification Objective 6.06-Pluggable Authentication Modules


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.

image from book
Exam Watch

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.

image from book

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.

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 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] 

image from book
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.

Table 6-6: PAM Control Flags

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.

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

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 

image from book
Figure 6-10: The /etc/pam.d/system-auth configuration file

image from book
Exam Watch

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.

image from book

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

image from book

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

  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. Review the messages in /var/log/secure. Do you see where you tried to log in as root in virtual console number 3?

  7. 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.

image from book

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, 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.

Table 6-7: 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.

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

image from book

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 

  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?

  3. 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.

  4. 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?

image from book

image from book
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 (PAM is that secure).

image from book



RHCE Red Hat Certified Engineer Linux Study Guide (Exam RH302)
Linux Patch Management: Keeping Linux Systems Up To Date
ISBN: 0132366754
EAN: 2147483647
Year: 2004
Pages: 227
Authors: Michael Jang

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net