206 Technique 30: Customizing Authentication with PAM

Dissecting a Configuration File

Modifying a PAM configuration file isn’t difficult, but the format appears pretty cryptic at first. In this section, we show you a typical configuration file and explain what each line does. After you can read a PAM configuration file, you can tailor your own files to more closely match your needs.

Each file in the /etc/pam.d directory controls PAM authentication for a single client. A client roughly equates to a program, and the filename is the same as the program name. The /etc/pam.d/login file contains all the authentication rules for the login program, the sshd file contains all the authentication rules for ssh, and so on.

The contents of your PAM configuration files may vary. The following is just an example of one possible configuration for a login file.

To peek into the login configuration file, open a terminal window and enter the following command:

$ kedit /etc/pamd.d/login

The PAM configuration file opens, displaying the authentication rules for the login command, as shown in Listing 30-1.

Here’s a line-by-line breakdown of the rules in this file:

Line 1: The first line in /etc/pam.d/login is a comment. You can ignore that line for now, but notice that you can include comments in a

LISTING 30-1: THE PAM LOGIN CONFIGURATION FILE

PAM configuration file by prefixing the comments with a #.

The next three rules are invoked, in order, during the authentication phase. (They all start with the word auth.)

Line 2: The first authentication rule invokes the pam_securetty.so module. If you track down the documentation for that module (see

/usr/share/doc/pam-0.77/txts/README. pam_securetty), you see that this module allows privileged (that is, root) logins only from specific workstations. The idea behind securetty is that you can physically secure certain workstations (by placing them behind a locked door) and then allow root logins from only those workstations. Because the rule is required (see the second column), pam_securetty.so must return a positive response before PAM will continue with authentication.

pam_securetty.so makes sure that privileged users (like root) cannot log in from remote computers. They have to be sitting at one of the workstations listed in /etc/securetty.

Line 3: The second auth rule requires that the pam_stack.so module return a positive response when passed the argument service=system-auth. pam_stack.so doesn’t really do any authentication checks by itself. Instead, it switches over to a common set of rules stored in another configuration file. Keeping commonly used rules in a single file makes it easier to manage PAM configuration. pam_stack.so returns a positive response if the rules in the other file (in this case, /etc/pam.d/ system-auth) are satisfied.

1	- #%PAM-1.0
2	- auth	required	pam_securetty.so
3	- auth	required	pam_stack.so service=system-auth
4	- auth	required	pam_nologin.so
5	- account	required	pam_stack.so service=system-auth
6	- session	required	pam_stack.so service=system-auth
7	- session	optional	pam_console.so
8	- password	required	pam_stack.so service=system-auth

Dissecting a Configuration File

207

Quite a few modules use the system-auth configuration file. The system-auth file holds common configuration information in one file. Each file that needs the common information just refers to the system-auth file instead of duplicating that information.

When the authentication rules found in the system-auth file are satisfied, PAM continues to the third authentication rule (also required).

Line 4: The third auth rule requires a positive result from the pam_nologin.so module. The pam_nologin.so module checks for the existence of the /etc/nologin file. If the /etc/nologin file exists, only root is allowed to log in.

Create the /etc/nologin file to block other users from logging in to the system while you’re performing system maintenance. Just be sure to delete the file again when you’re done because no other users (other than root) are allowed to log in while /etc/nologin exists.

When the authentication rules are met, and PAM is satisfied that the user is who he or she claims to be, PAM moves on to the account rules.

Authentication rules lay out the procedure users must follow in order to prove that they are who they claim to be. Account rules kick in after the authentication process is completed.

Line 5: This is the only account rule in this file. The rule simply defers to the account rules in

/etc/pam.d/system-auth. You can use account rules to enforce policies that aren’t related to authentication but are still important — password aging, disabled accounts, and so on.

The system-auth file holds the most commonly used system configuration rules. You can look inside the file with the following command:

$ kedit /etc/pam.d/system-auth

Looking in the system-auth file tells you that the pam_unix.so module is being invoked. The

pam_unix.so module is responsible for password aging and other account-related concerns.

When the account-related issues have been satisfied, the login program requests that PAM satisfy any session rules that are required. By looking in the configuration file (lines 6 and 7), you can see two session rules — one required and one optional.

Line 6: The required rule is applied first. The required rule defers to the system-auth configuration file rules, where the pam_limits.so module and the pam_unix.so module are required to satisfy requirements before the login program can continue. pam_limits.so enforces limits imposed by the /etc/security/limits.conf file (limits on disk usage, CPU usage, memory usage, and so on). The requirements of the pam_limits.so module must be met before login is allowed to continue.

Line 7: Optional rules don’t need to be satisfied to continue — they’re optional. This rule specifies that the pam_console.so module may or may not be satisfied before the login program continues.

The pam_console module changes the file permissions when you log in at the console, and changes them back when you log out.

The theory behind pam_console is that if you have physical access to the machine, you should have physical access to the peripherals. This is a fairly volatile module, and not one we recommend playing with.

Line 8: The password rule is invoked only when the login program requests that a password be changed. Then PAM looks in the configuration file, sees that the password rule requires that the system-auth password rules be satisfied before the user is allowed to change the password. In our system-auth file, the password rule requires that the pam_cracklib module be satisfied before the new password is accepted. Notice that password rules aren’t actually part of the authentication sequence — they’re only used to change the password (or retina scan, or fingerprint, or whatever you have configured).

208 Technique 30: Customizing Authentication with PAM

The pam_cracklib module works only with the password rule type. It checks the password against a dictionary to see if the new password entered is guessable. If you set pam_cracklib to required, only complex, difficult-to-crack passwords will be accepted.

Skipping a Password with PAM

You can tighten security fast with PAM, but you can also relax security standards to save time in certain cases. On a system that’s not holding data that is life- and-death important, and that’s not an integral link in a network, you can make PAM skip the request for a root password when you need superuser privileges at the command line.

The pam_wheel.so module returns a positive result whenever members of the wheel group try to authenticate themselves. That means that if you’re a member of the group named wheel, PAM assumes that you’ve already authenticated yourself and lets you continue without a password. What’s the significance of the name wheel? We can’t figure it out either.

Think twice before disabling root passwords. Never having to slow down to enter a password is a definite timesaver, but it’s about the loosest security you can have.

The following example works for Fedora or Mandrake. The same technique will work for SuSE, but because SuSE doesn’t use a common configuration file (like system-auth), you need to decide for yourself which files you want to modify.

To change the PAM configuration files to allow superuser access without a password, follow these steps:

1. Open your terminal window and give yourself superuser privileges.

2. Enter the following command:

# kedit /etc/group file

The kedit window opens, displaying the contents of /etc/group.

3. Find the line in the file that starts with wheel.

4. Add a comma, followed by your username, to the line.

wheel:x:10:root,username

5. Save the file and exit.

6. Enter the following command:

$ kedit /etc/pam.d/system-auth

7.If you’re using Fedora, find the lines that look like this:

# Uncomment the following line to \ implicitly trust users in the \ “wheel” group.

#auth sufficient \ /lib/security/$ISA/pam_wheel.so \ trust use_uid

If you’re using Mandrake, you won’t have the last line included in your system-auth file.

You’ll need to add the following line as the second rule in your system-auth file:

auth sufficient \ /lib/security/$ISA/pam_wheel.so \ trust use_uid

8.If you’re using Fedora, remove the # from the beginning of the auth rule.

The result should look like this:

# Uncomment the following line to \ implicitly trust users in the \ “wheel” group.

auth sufficient \ /lib/security/$ISA/pam_wheel.so \ trust use_uid

Now, when you use the su command, PAM recognizes that you are a member of the wheel group and doesn’t ask for the root password.

If you decide to allow PAM to skip password prompts and you leave your desktop logged in and unattended, you may be asking for trouble.

31 Gaining Privileges

Technique

Save Time By

Knowing the power of the superuser

Gaining extra privileges with the su command

Limiting privileges with

sudo

Every Linux system has a user who thinks he’s better than everyone else; a user who wants more privileges than anybody else has; a user who can do things others can’t do. We call him the superuser,

but his real name is root.

This technique shows you how to gain and use superuser privileges safely from the comfort of your desk — no phone booths or funny tights required. Limiting the power of the superuser is important if you want to keep your system safe and secure. You’ll save a lot of time if you don’t have to recover from disasters caused by (accidentally) flexing too many superuser muscles. Sometimes you need superuser privileges to do system administrator work like configuration, user management, and privilege management. But we show how to limit your exposure by gaining only the privileges that you need and only when you need them.

Feeling the Power

In most systems, a single user, named root, holds superuser privileges. (You can think of user root as synonymous with superuser.) The superuser can do anything he wants on your system, such as the following operations:

Modify (or delete) any file.

Change any password.

Use any device.

Create new user accounts.

Delete old user accounts.

Lock you out of your system.

Sounds like someone you want to keep out of your system, doesn’t it?