Chapter 27

Chapter 27

Pluggable Authentication Modules (PAM)

Programs that give privileges to users must properly authenticate (verify the identity of) each user. When you log in to a system, you provide your username and password, and the login process uses the username and password to authenticate the login — to verify that you are who you say you are. Forms of authentication other than passwords are possible, and the passwords can be stored in different ways.

Pluggable Authentication Modules (PAM) is a way of allowing the system administrator to set an authentication policy without having to recompile authentication programs. With PAM, you control how particular authentication modules are plugged into a program by editing that program's PAM configuration file in /etc/pam.d.

Most Red Hat Linux users will never need to alter PAM configuration files for any of their programs. When you use RPM to install programs that require authentication, they automatically make the changes necessary to do normal password authentication using PAM. However, if you need to customize your configuration, you must understand the structure of a PAM configuration file. More information can be found in the section called PAM modules.

Advantages of PAM When used correctly, PAM provides many advantages for a system administrator, such as the following: A common authentication scheme that can be used with a wide variety of applications. PAM can be implemented with various applications without having to recompile the applications to specifically support PAM. Great flexibility and control over authentication for the administrator and application developer. Application developers do not need to develop their program to use a particular authentication scheme. Instead, they can focus purely on the details of their program.

PAM Configuration Files The directory /etc/pam.d contains the PAM configuration files. In earlier versions of PAM, /etc/pam.conf was used. The pam.conf file is still read if no /etc/pam.d/ entry is found, but its use is deprecated. Each application (or service, as applications designed to be used by many users are commonly known) has its own file. Each line in the file has five elements: service name, module type, control flag, module path, and arguments

PAM Service Names The service name of every PAM-enabled application is the name of its configuration file in /etc/pam.d. Each program which uses PAM defines its own service name. For example, the login program defines the service name login, ftpd defines the service name ftp, and so on. In general, the service name is the name of the program used to access the service, not the program used to provide the service.

PAM Modules

PAM includes four different types of modules for controlling access to a particular service: An auth module provides the actual authentication (perhaps asking for and checking a password) and sets credentials, such as group membership or Kerberos tickets. An account module checks to make sure that access is allowed for the user (the account has not expired, the user is allowed to log in at this time of day, and so on). A password module is used to set passwords.

A session module is used after a user has been authenticated. A session module performs additional tasks which are needed to allow access. These modules may be stacked, or placed upon one another, so that multiple modules are used. The order of a module stack is very important in the authentication process, because it makes it very easy for an administrator to require that several conditions exist before allowing user authentication to occur.

Before someone is allowed to rlogin, PAM verifies that the /etc/nologin file does not exist, that they are not trying to log in remotely as root over an unencrypted network connection, and that any environmental variables can be loaded. Then, a successful rhosts authentication is performed before the connection is allowed. If rhosts authentication fails, then standard password authentication is done.

New PAM modules can be added at any time, and PAM-aware applications can then be made to use them. For example, if you create a one-timepassword creation method and write a PAM module to support it, PAM-aware programs can immediately use the new module and password method without being recompiled or otherwise modified in any way. As you can imagine, this is very beneficial, because it lets you mix-and-match, as well as test, authentication methods very quickly with different programs without having to recompile the programs. Documentation on writing modules is included with the system in /usr/share/doc/pam—.

PAM Control Flags All PAM modules generate a success or failure result when checked. Control flags tell PAM what do with the result. Since modules can be stacked in a particular order, control flags give you the ability to set the importance of a module in respect to the modules that follow it. auth required /lib/security/pam_nologin.soauth required /lib/security/pam_securetty.soauth required /lib/security/pam_env.soauth sufficient /lib/security/pam_rhosts_auth.soauth required /lib/security/pam_stack.so service=system-authaccount required /lib/security/pam_stack.so service=system-authpassword required /lib/security/pam_stack.so service=system-authsession required /lib/security/pam_stack.so service=system-auth

PAM Module Paths Module paths tell PAM where to find the pluggable module to be used with the module type specified. Usually, it is provided as the full path to the module, such as /lib/security/pam_stack.so. However, if the full path is not given (in other words, the path does not start with a /), then the module indicated is assumed to be in /lib/security, the default location for PAM modules.

PAM Arguments PAM uses arguments to pass information to a pluggable module during authentication for a particular module type. These arguments allow the PAM configuration files for particular programs to use a common PAM module but in different ways. The module takes a db argument, specifying the Berkeley DB filename to use, which can be different for different services. So, the pam_userdb.so line in a PAM configuration file look like this: auth required /lib/security/pam_userdb.so db=path/to/file

PAM Configuration File Samples

A sample PAM application configuration file looks like this: #%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_unix.so shadow ullok auth required /lib/security/pam_nologin.so account required /lib/security/pam_unix.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_unix.so shadow nullok use_authtok session required /lib/security/pam_unix.so

The first line is a comment (any line starting with a # character is a comment). Lines two through four stack three modules to use for login authentication. auth required /lib/security/pam_securetty.so Line two makes sure that if the user is trying to log in as root, the tty on which they are logging in is listed in the /etc/securetty file, if that file exists. auth

required /lib/security/pam_unix.so nullok Line three causes the user to be asked for a password and the password to be checked, using the information store in /etc/passwd, and if it exists, /etc/shadow. auth required /lib/security/pam_nologin.so

If any requisite module returns failure, PAM fails immediately without calling any other modules. 1.account required /lib/security/pam_unix.so 2.password required /lib/security/pam_cracklib.so 3.password required /lib/security/pam_unix.so 4.shadow nullok use_authtok 5.session required /lib/security/pam_unix.so 6.auth required /lib/security/pam_securetty.so 7.auth required /lib/security/pam_env.soauth sufficient 8./lib/security/pam_rhosts_auth.so 9. auth required /lib/security/pam_stack.so service=system-auth

Shadow Passwords If you are using shadow passwords, pam_unix.so will automatically detect that they are in use and will use them to authenticate users

Using rlogin, rsh, and rexec with PAM For security reasons, rexec, rsh, and rlogin are not enabled by default in Red Hat Linux 7.2. You should use the OpenSSH suite of tools instead. If you must use rexec, rsh, and rlogin, and if you need to use them as root, you will need to make a few modifications to the /etc/securetty file. All three of these tools have PAM configuration files that require the pam_securetty.so PAM module, so you must edit /etc/securetty to allow root access.