Pulling The Covers Off Linux PAM (Part 2)

In our second look at Linux PAM we teach you how to fine-tune your setup and where to look for differences between distributions.

 By Carla Schroder
Page 1 of 2
Print Article

In part 1of our look at Linux PAM, we learned how to remove the annoying failed-login delay, lock out users who have too many failed login attempts and how to set a restrictive fallback configuration. Today we'll look at Linux distribution differences, dig into the module types, what order to put things in, and what the different options mean. You should have part 1 handy so you can refer to the examples.

Red Hat v. The World
Red Hat is (in)famous for heavily customizing its Linux releases. This gets confusing when howto authors assume that Red Hat = Linux and don't bother to point out the Red Hat-specific bits, or when you're reading the program author's documentation and it makes no sense for Red Hat. When you're studying PAM there are two items in particular that you'll see a lot of that belong to Red Hat and its derivatives: the pam_stack.so module, and the system_auth file. They are always used together, like this example from Fedora's /etc/pam.d/loginshows:

auth    required   pam_stack.so    service=system-auth

pam_stack.so works a bit like the @include statements in Debian PAM configuration files (see part 1 for an example); it calls the stack defined for another service. Red Hat uses it with the system_auth file to create a system default, which makes it easy to add a new PAM service, and to make global changes. pam_stack.sofully supports recursion, so be very careful that you do not make it reference itself either directly or through referencing other configuration files, or it will get stuck in a loop.

Configuration Syntax
Your /etc.init.d/pam.dfiles all use this syntax:

module-type     control-flag     module-path    arguments

The first three are required; arguments are optional.

Four Module Types
This does the work of verifying a user's identity and credentials. PAM is so flexible it will recognize many types of authorizations: login/password, biometrics, medieval chants, or anything else you can think of and have the talent to code.

This performs non-authentication account management, like checking to see if the user is authorized to use the system, and it manages access restrictions, such as time of day and type of service.

Updates passwords, allows or denies null passwords, verifies password strength and encryption type, re-uses passwords to avoid forcing users to have multiple logins, can check databases, and set credentials like Kerberos tickets (define) or group memberships.

For all the little odds and ends that make life nicer, like mounting directories, stopping or starting services, creating files, and setting resource limits.

Control Flags
These can be a bit confusing, so let's take a closer look. These determine what PAM does next based upon the result of the check performed.

The user must pass this check to continue. If it fails the other modules are checked, then the user is denied. Some folks think this adds a bit of security by not revealing where the failure occurred.

The user must pass this check to continue. If it fails, no more checks are run and the user is notified immediately.

If this succeeds and no other checks fail you have a successful authentication. If one of these fails it is ignored as long as required or requisitechecks succeed.

optionalmodules can fail all over the place and authentication won't be denied, unless there are no other modules for that service.

Module Arguments
You'll find these in the documentation for the individual modules, like in Chapter 6 of the The Linux-PAM System Administrators Guide. Any modules that are not included in this, such as third-party and Red Hat modules, hopefully will come with their own documentation.

Now let's do some fun stuff with PAM.

Locking Out Everyone, Hahaha
Suppose you want only the root user to be able to log into a system, and no one else. Why? Maybe you want to perform some system maintenance. Maybe you're just feeling ornery. Let's assume the first scenario. First tell everyone to find a stopping point in their work:

# wall
Important Message From Your BOFH
**the system is going down for maintenance in FIVE MINUTES**
**you have been WARNED**

Hit CTRL+D to send the message. Then create a nologinfile:

# touch /etc/nologin

Then kick all the logged-in users off the system. Rebooting is the easy way. Now no one else can log in and you can get your work done in peace and quiet. This works because

auth    requisite    pam_nologin.so

is a standard line in /etc/pam.d/login on most Linux distributions. Note that this replaces the NOLOGINS_FILE option from /etc/login.defs.

Continued on page 2: Re-Using Passwords

This article was originally published on Jun 28, 2005
Get the Latest Scoop with Networking Update Newsletter