- 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
Access Control with pam_listfile
Any PAM-aware application may be given an access control list with pam_listfile. This is an authentication-only module that takes a number of arguments, as displayed in Table 5.10. In order to clarify Table 5.10, we'll look at two examples.
Suppose that we have a guest account on our system and we would like to disable chsh for guest. The chsh command allows a user to change his or her default shell in /etc/passwd to any shell listed in /etc/shells. Since chsh is a PAM-aware application, we can use pam_listfile to implement this restriction (no problem!). Add the pam_listfile entry to the existing /etc/pam.d/ chsh configuration file as shown in Example 5-16. By now, everything in this file should be familiar except the pam_rootok entry (and of course the pam_listfile entry, which we haven't finished talking about). Actually, the pam_rootok entry is quite simple. Notice that it uses the control flag sufficient meaning that, if this module is satisfied, none of the other auth module types needs to be executed. The pam_rootok module does what you'd expect. If it's root, it's OK! So, in this case, if root wants to change any user's shell, root will not be authenticated (not prompted for a password).
Example 5-16 The chsh Configuration File with a pam_listfile Entry
Auth sufficient /lib/security/pam_rootok.so
auth required /lib/security/pam_listfile.so onerr=fail\
item=user sense=deny file=/etc/security/nochsh
auth required /lib/security/pam_pwdb.so
account required /lib/security/pam_pwdb.so
password required /lib/security/pam_cracklib.so minlen=20 retry=3
password required /lib/security/pam_pwdb.so md5 use_authtok
session required /lib/security/pam_pwdb.so
Now back to pam_listfile. In Example 5-16, the argument onerr=fail is set. This means that, if there are any error conditions generated by the execution of this module, the module will fail. Since it is a required module, this further implies that authentication will fail and the user will not be allowed to change his or her shell. Errors will be logged to syslog, so you may view them in /var/log/messages. Unless you are debugging in a safe environment (i.e., not connected to a production environment), this is the recommended setting for this argument.
The remaining arguments deal with the access control file, which in this case is /etc/security/nochsh. The item=user argument tells pam_listfile that it should expect to find usernames—one per line—in /etc/security/ nochsh. The sense=deny argument tells pam_listfile that /etc/security/ nochsh is a deny list; that is, any user listed in that file will cause pam_listfile to fail and therefore (because of the required control flag) cause authentication to fail and disallow the user from changing the shell.
Table 5.10 Arguments to pam_listfile
|
Argument |
Description |
|
Onerr |
Takes either succeed or fail. If an error occurs, such as an unreadable configuration file, should this module return success or failure? |
|
sense |
Takes either allow or deny. This tells the module whether the list is an allow or deny list. |
|
file |
Requires the absolute pathname to the configuration file. |
|
item |
One of user, tty, rhost, ruser, group, or shell. It tells the module what to look for in the configuration file. |
|
apply |
Takes a username or a groupname preceded by @. It is only meaningful if item is set to tty, rhost, or shell. |
All that remains is to create /etc/security/nochsh and list the users to whom we wish to deny chsh capability. Here is an example file:
guest joe
The two users, guest and joe (we don't trust him anymore), will not be able to successfully execute chsh, as the user guest demonstrates in Example 5-17. Hopefully, the flow of events is becoming clear. When guest executes chsh, a PAM-aware application, Linux-PAM is invoked and the auth stack in /etc/ pam.d/chsh is executed. Referring back to Example 5-16 on page 100, the first auth module invoked is pam_rootok. Since guest is not root, that module fails and pam_pwdb is invoked and causes the password prompt. The user guest successfully enters the correct password (you'll have to trust me here) and execution is passed to pam_listfile, which checks its deny list and finds guest in it, causing authentication to fail (hence the generic Password error message).
Example 5-17 Failed chsh Attempt Due to pam_listfile
$ telnet livfreeordie Trying 10.1.1.1... Escape character is '^]'. This is a restricted system.All activity is logged. login:guest Password: livfreeordie$chsh -s /bin/bash Changing shell for guest. Password: Password error. livfreeordie$
Consider another example. Suppose that we want to limit the users to which others may su—we want to restrict su use generally (not just su to root) to a specific set of users. We add a pam_listfile entry to /etc/pam.d/su as displayed in Example 5-18. This time we are using an allow list. Just place each allowed username, one per line, in the /etc/security/suok file. For example, if our /etc/security/suok contains the users:
Root Mary Bill Jane efram
then these are the only users that will be accepted as a user argument to su. Anyone may execute su, but only to become one of the users in this list. Example 5-19 shows what happens when paul tries to su to guest and then to root. The su attempt to guest fails because guest is not in the /etc/security/suok file. The su to root, however, succeeds because root is in the /etc/security/ suok file and Paul knows the root password.
Example 5-18 The su Configuration File with pam_listfile
auth required /lib/security/pam_listfile.so onerr=fail \
item=user sense=allow file=/etc/security/suok
auth required /lib/security/pam_pwdb.so
account required /lib/security/pam_pwdb.so
password required /lib/security/pam_cracklib.so minlen=20 retry=3
password required /lib/security/pam_pwdb.so md5 use_authtok
session required /lib/security/pam_pwdb.so
Example 5-19 Failed su Attempts Due to
pam_listfile
$ whoami
joe
$ su - guest
Password:
su: incorrect password
$ su -
Password
#
Notice that the error message is not indicative of the actual failure. If
you review the previous failure messages from other PAM modules, you'll see
that this is a feature of PAM. The idea is to not reveal any information to the
user through error messages. As an administrator with root access, you may
always check out the log files. By default, you will find PAM-generated log
messages in /var/log/messages (these files and syslog, in general,
will be discussed in Chapter 8).
Note that when sense=allow changes to sense=deny in Example
5-18, the /etc/security/suok file becomes a deny list, meaning that a
user would not be able to su to any of the users in the list. This is
particularly useful if you wish to implement sudo (sudo is
discussed in Chapter 9) and completely disallow su to root.