- Pluggable Authentication Modules
- PAM OVERVIEW
- PAM Configuration
- PAM ADMINISTRATION
- PAM and Passwords
- PAM and Passwords Summary
- PAM and login
- Time and Resource Limits
- Access Control with pam_listfile
- PAM and su
- Using pam_access
- Using pam_lastlog
- Using pam_rhosts_auth
- One-Time Password Support
- PAM and the other Configuration File
- Additional PAM Options
- PAM LOGS
- AVAILABLE PAM MODULES
- PAM-AWARE APPLICATIONS
- IMPORTANT NOTES ABOUT CONFIGURING PAM
- THE FUTURE OF PAM
- SUMMARY
- FOR FURTHER READING
- On-Line Documentation
PAM and login
The /etc/pam.d/login configuration file is read by Linux-PAM whenever the login (/bin/login) program is executed. Example 5-8 is a sample of this file. From the previous section, we have a good idea of what is going on here. Let's examine the details of the action of each module type.
Example 5-8 Sample /etc/pam.d/login File
Auth required /lib/security/pam_securetty.so
Auth required /lib/security/pam_pwdb.so
Auth required /lib/security/pam_nologin.so
Account required /lib/security/pam_pwdb.so
Password required /lib/security/pam_cracklib.so minlen=20
retry=3 type=SECRET
password required /lib/security/pam_pwdb.so md5 use_authtok
session required /lib/security/pam_pwdb.so
Module Type auth There are three modules stacked for type auth. The first is pam_securetty. This is an auth module type only. It accepts no arguments. Its sole purpose is to check /etc/securetty against the device of the login attempt, if the user logging in is root. It will fail only if someone is trying to log in as root from a device not in /etc/securetty. Since this module is required, a failure here would cause the login to fail. Recall, however, that the control flag, required, will still allow subsequent modules to be executed, and therefore the user will not be refused access until after all three modules in this stack are executed.
The second module is pam_pwdb. As discussed in PAM and Passwords on page 86, its role here is to authenticate the user.
The third module in the stack is pam_nologin. This is also an auth-only module type that accepts no arguments. Its purpose is to check for the existence of /etc/nologin. If /etc/nologin exists, then no users, except root, are allowed to log in; if /etc/nologin contains a message, it is displayed. For example, if the /etc/nologin is then Example 5-9 exhibits the system's behavior when the user joe attempts to telnet to the system.
Example 5-9 Attempted Login with the Presence of /etc/nologin
$telnet livfreeordie Trying 10.1.1.1... Connected to livfreeordie. Escape character is '^]'. Red Hat Linux release 5.2 (Apollo) Kernel 2.0.36 on an i686 login:joe Password: System down for maintenance until 2/28/99 at 4pm Login incorrect login:
OH, BY THE WAY...
Did you ever wonder about how to get rid of the message that appears when you connect to a system? In Example 5-9, it is the two-line message beginning with "Red Hat Linux." This message gives away information about your system, which does not reflect good security practice. On Red Hat 5.2/6.0, the message displayed reflects the contents of /etc/issue.net for remote connections and /etc/issue for local connections. At this point, you may be tempted to rush off and modify these files to suit your needs. Don't. The files are rewritten at every reboot! In order to modify these files, you must modify /etc/rc.d/rc.local. /etc/rc.d/rc2.d/S99local is a symbolic link to /etc/rc.d/rc.local, which is executed upon entering run level 2. Be sure to replace this message with something appropriate, maybe something like "This is a restricted system. All activities are logged." But whatever you do, don't reveal the operating system, hardware, or other information that may be used against you. And don't use words like "Welcome"! There are many other ways to replace this message, some of which will be discussed at various points in this text.
By default, Joe will actually be able to attempt to log in three more times, but of course the result will be the same. Existing login sessions are not affected by the /etc/nologin file.
This file is normally used for purposes of system maintenance, but it also is beneficial in case of a system breach. This topic is discussed in Chapter 3.
Normally, the /etc/nologin file does not exist and the user, once authenticated, will be granted access. The subsequent modules in /etc/pam.d/login are then invoked.
Module Types account, password, and session The pam_pwdb entry for the account module type, as previously described, performs the task of checking the user's account. If the user's password has expired, for example, the entries with module type password will be invoked and the events described in PAM and Passwords on page 86 will occur. The session entry is for the exclusive purpose of logging connection information to syslog.
Many other PAM configuration files besides /etc/pam.d/login incorporate the use of these modules and module types. Since each configuration file represents an application, it follows that any application that requires authentication by password will incorporate some or all of the modules and module types in /etc/pam.d/login. Included among these are rsh, rlogin, su, ppp, chfn, chsh, and ftp. Bear this in mind whenever you decide to make changes to one of these configuration files. For continuity, and for security, you will ordinarily make changes across the board. Think carefully if you decide not to change a particular configuration file whenever you change others.
Next let's take a look at some additional restrictions that may be imposed through PAM.