Pluggable Authentication Mechanism
Using PAM and root logins on linux
For each service you are interested in (rsh, rlogin, sshd, rexec) you
need a PAM file (/etc/pam.d/$service) like this:
auth required /lib/security/pam_nologin.so
#auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_env.so
auth sufficient /lib/security/pam_rhosts_auth.so
auth required /lib/security/pam_stack.so service=system-auth
account required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth
Note that pam_securetty is commented out.
PAM auth in a nutshell
(Check the existing PAM file for details about the 'account',
'password', and 'session' type modules since they may apply limits
beyond logins that the individual services need. This note only
applies to 'auth' modules.)
Each module must be described in one of these ways:
- required means that the module must not fail when evaulated. Failure means that access is denied, but other modules will be evaluated anyways.
- requisite means that the module must not fail when evaluated. Failure results in an immediate return of control to the application (ie immediate denial of access).
- sufficient means that if the module succeeds, no further modules need be evaluated (assuming that none of the previous 'required' modules have failed) and access can be immediately granted.
- optional is described in the documentation as: "in general, PAM ignores such a module when determining if the module stack will succeed or fail." Refer to your module documentation.
For login access, PAM auth modules are evaluated from
top to bottom, until one of the following conditions are met:
- a module expressly DENIES access
- a module passes and is deemed 'sufficient', and no previous modules have failed
- all auth class modules are passed and no modules have failed
So for this case:
- pam_nologin checks for the existance of /etc/nologin. If it is there, and you are not attempting to login as root, it displays the content of /etc/nologin to you and denies access. Otherwise, the module passes.
- pam_securetty is commented out. If it wasn't, it would follow the /etc/securetty rules (ie only permit a root login on a tty specified in that file). Since we want the system to ignore /etc/securetty, we comment it out or remove it.
- pam_env gives us the ability to setup environment variables. This module will generally never fail, but should never be described as sufficent. Refer to the module documentation for details about how this module works.
- pam_rhosts_auth checks for a .rhosts file and follows the rules one would expect. Since we have described this as 'sufficient', success here would mean the user is permitted access. A lack of an rhosts means the module does not fail.
- finally, pam_stack uses the system authentication (username and/or password challenges, sourced from whatever nsswitch.conf is aimed at) to determine user identity.
There's some (possibly old, but reasonably complete) documentation on
the web at
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html
which makes for simply fascinating reading.