For When You Can't Have The Real Thing
[ start | index | login ]
start > Linux > PAM

PAM

Created by dave. Last edited by dave, 19 years and 125 days ago. Viewed 4,867 times. #1
[edit] [rdf]
labels
attachments

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.
no comments | post comment
This is a collection of techical information, much of it learned the hard way. Consider it a lab book or a /info directory. I doubt much of it will be of use to anyone else.

Useful:


snipsnap.org | Copyright 2000-2002 Matthias L. Jugel and Stephan J. Schmidt