- 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 the other Configuration File
So far we have discussed discrete PAM-aware applications and how to grant or limit access through PAM by those applications. It turns out that, if a PAM-aware application has no configuration file of its own, Linux-PAM will supply a special set of modules from the /etc/pam.d/other file. This file is normally used to reject all other requests and, by default, will likely appear as in Example 5-24. For example, if you download a PAM-aware application, such as ssh 1.2.27 (see Chapter 11), and fail to provide an ssh configuration file in /etc/ pam.d, then the other file is used, and, if it is as in Example 5-24, then ssh connections will always fail. Furthermore, pam_deny generates no messages whatsoever! Unfortunately this means that you may end up spending a lot of time trying to figure out why something doesn't work. All pam_deny does, as its name suggests, is deny all requests for any available module type.
Example 5-24 A Common /etc/pam.d/other File
Auth required /lib/security/pam_deny.so account required /lib/security/pam_deny.so password required /lib/security/pam_deny.so session required /lib/security/pam_deny.so
But there is good news! There is another module, the pam_warn module, that logs to syslog informational messages, including the service requested, the terminal name, the username, the remote username, and the remote host-name. The pam_warn module operates only for module type auth and password. So you may want to modify your /etc/pam.d/other file as in Example 5-25. In this way, all other services that make auth or password requests will have log entries generated. The pam_warn module is not limited to use with pam_deny. It may be used in any auth or password stack to generate additional log messages.
Example 5-25 Administrator Friendly /etc/pam.d/other File
auth required /lib/security/pam_warn.so auth required /lib/security/pam_deny.so account required /lib/security/pam_deny.so password required /lib/security/pam_warn.so password required /lib/security/pam_deny.so session required /lib/security/pam_deny.so
This additional logging capability of pam_warn has obvious debugging advantages, but it also has advantages from the security perspective. For example, if you have identified some suspicious activity, you may want to add pam_warn in the auth stacks surrounding the services in question. You may also want to use the debug argument on those modules that support it for more detailed auditing information. Pay close attention when you do this because your log files will get large quickly. And, if the bad-guys are already in, they're reading the log files, too!
There is one other module in this category. It is the antithesis of pam_deny. It is called pam_permit and—you guessed it—it categorically allows access. It operates for all module types and should be used with great caution, if ever.