I wrote this sometime ago and never put it anywhere... excuse the formatting if it's off some, I had to paste it out of a PDF and blogger didnt like half of it.
Background:
If you have logged into a Linux box in the past five years or so you have implicitly used PAM (Pluggable Authentication Modules). PAM was originally created by Sun and licensed to a few other Unices (HPUX and AIX). Later, like many applications, PAM was brought to other Linux and BSD distributions where it gained most of its popularity. LinuxPAM star ted its own project that is distributed with most Linux flavors used today. DARPA funded another project OpenPAM, which joined XSSO (X/Single SignOn Service) and LinuxPAM (GNU version) along with the original Sun implementation. OpenPAM remains the default in most BSD distributions.
In a nut shell:
When applications are compiled with the PAM library support, authentication schemes on the backend can seamlessly change. More specifically, you can configure multiple sources to transparently authenticate accounts for one or more applications (stack), and conveniently map them to authentication domains. Outside of just authentication you can also manage password policies (complexity, number of characters, etc), manage device usage (quotas, cpu, memory, etc), and ease administration with initial account management (creation, removal,
setting environment variables). A variety of modules are available that inter face with PAM and offer the flexibility to enforce granular controls on accounts and applications. Below I will show some examples of PAM and its configuration files.
Technical Details:
There are two different methods for configuring PAM, both are pretty straight forward. Older Unix/Linux systems use the method of putting all configuration information in /etc/pam.conf file (shown in Figure 1a). Newer Unix/Linux systems use the /etc/pam.d/ directory which contain the module-name as a file and the configuration for each module contained within those files (shown in Figure 1b and Figure 1c). If no configurations exist for a specific PAM module it uses the /etc/pam.d/other file. The syntax across both older and newer systems
remains the same (listed below Figure 1a) with the only difference being the service_name.
Figure 1a.
--------
# /etc/pam.conf
#
# service_name module_type control_flag module_path options
ssh auth required pam_env.so
ssh account required pam_unix.so
ssh password required pam_unix.so nullok obscure min=4 max=8 md5
ssh session required pam_unix.so
ssh session optional pam_motd.so
ssh session optional pam_mail.so standard noenv
ssh session required pam_limits.so
other auth required pam_unix.so
other account required pam_unix.so
other password required pam_unix.so
other session required pam_unix.so
--------
Figure 1b.
--------
# /etc/pam.d/other
#
# module_type control_flag module_path options
auth required pam_unix.so
account required pam_unix.so
password required pam_unix.so
session required pam_unix.so
--------
Figure 1c.
--------
# /etc/pam.d/ssh
#
# module_type control_flag module_path options
auth required pam_env.so
account required pam_unix.so
password required pam_unix.so nullok obscure min=4 max=8 md5
session required pam_unix.so
session optional pam_motd.so
session optional pam_mail.so standard noenvsession required pam_limits.so
--------
Wrapping Up:
This article only briefly describes PAM and ways to configure it. With this brief overview you should be able to quickly run through the default configuration files distributed with your favorite flavor of Linux and understand it. Many howto's and examples of configurations with thirdparty authentication schemes exist, but go outside this brief overview. Check the pam-usb module for the cheapest/home-made two-factor authentication solution.
We had 13 (make that 14, according to Allen) people at IndySec 2 last night. Landon gave a great presentation on HoneyNets. A super sharp guy. I am glad he could be our first speaker at IndySec.
