Pluggable authentication modules are
a common framework for authentication and security. Understanding and using PAM
can be very beneficial for planning and implementing a secure, efficient single
sign-on solution.
About PAM
Programs that grant users access to
a system use authentication to verify each other's identity (that is, to
establish that a user is who they say they are). In Red Hat Enterprise Linux, many programs are
configured to use a centralized authentication mechanism called Pluggable
Authentication Modules (PAM).
PAM uses a pluggable, modular
architecture, which affords the system administrator a great deal of
flexibility in setting authentication policies for the system. PAM is a useful
system for developers and administrators for several reasons:
- PAM provides a common authentication scheme that can be used with a wide variety of applications.
- PAM provides significant flexibility and control over authentication for both system administrators and application developers.
- PAM provides a single, fully-documented library which allows developers to write programs without having to create their own authentication schemes.
PAM Configuration Files
The
/etc/pam.d/
directory contains the PAM configuration files for each PAM-aware application. PAM Service Files
Each PAM-aware application or service
has a file in the
/etc/pam.d/
directory. Each file in this directory has the same name as the service to
which it controls access.
The PAM-aware program is responsible for defining its
service name and installing its own PAM configuration file in the
/etc/pam.d/
directory. For
example, the login
program defines its service name as login
and installs the /etc/pam.d/login
PAM
configuration file. PAM Configuration File Format
Each PAM configuration file contains a group of directives
that define the module and any controls or arguments with it.
The directives all have a simple syntax that identifies the
module purpose (interface) and the configuration settings for the module.
module_interface control_flag module_name module_arguments
PAM Module Interfaces
Four types of PAM module interface are available. Each of
these corresponds to a different aspect of the authorization process:
auth
— This module interface authenticates use. For example, it requests and verifies the validity of a password. Modules with this interface can also set credentials, such as group memberships or Kerberos tickets.account
— This module interface verifies that access is allowed. For example, it checks if a user account has expired or if a user is allowed to log in at a particular time of day.password
— This module interface is used for changing user passwords.session
— This module interface configures and manages user sessions. Modules with this interface can also perform additional tasks that are needed to allow access, like mounting a user's home directory and making the user's mailbox available.
NOTE
An individual module can provide any or all module
interfaces. For instance,
pam_unix.so
provides all four module interfaces.
In a PAM configuration file, the module interface is the
first field defined. For example:
auth required pam_unix.so
This instructs PAM to use the
pam_unix.so
module's auth
interface.
Module interface directives can be stacked, or placed upon one
another, so that multiple modules are used together for one purpose. If a
module's control flag uses the
sufficient
or requisite
value, then the order in which the modules are listed is important to the
authentication process.
Stacking makes it easy for an administrator to require
specific conditions to exist before allowing the user to authenticate. For
example, the
reboot
command normally uses several stacked modules, as seen in its PAM configuration
file: [root@LinuxHowtoServer ~]# cat /etc/pam.d/reboot
#%PAM-1.0
auth sufficient pam_rootok.so
auth required pam_console.so
#auth include system-auth
account required pam_permit.so
- The first line is a comment and is not processed.
auth sufficient pam_rootok.so
— This line uses thepam_rootok.so
module to check whether the current user is root, by verifying that their UID is 0. If this test succeeds, no other modules are consulted and the command is executed. If this test fails, the next module is consulted.auth required pam_console.so
— This line uses thepam_console.so
module to attempt to authenticate the user. If this user is already logged in at the console,pam_console.so
checks whether there is a file in the/etc/security/console.apps/
directory with the same name as the service name (reboot). If such a file exists, authentication succeeds and control is passed to the next module.#auth include system-auth
— This line is commented and is not processed.account required pam_permit.so
— This line uses thepam_permit.so
module to allow the root user or anyone logged in at the console to reboot the system.
PAM Control Flags
All PAM modules generate a success or failure result when
called. Control flags tell PAM what do with the result. Modules can be stacked
in a particular order, and the control flags determine how important the
success or failure of a particular module is to the overall goal of
authenticating the user to the service.
There are several simple flags, which use only a keyword to
set the configuration:
required
— The module result must be successful for authentication to continue. If the test fails at this point, the user is not notified until the results of all module tests that reference that interface are complete.requisite
— The module result must be successful for authentication to continue. However, if a test fails at this point, the user is notified immediately with a message reflecting the first failedrequired
orrequisite
module test.sufficient
— The module result is ignored if it fails. However, if the result of a module flaggedsufficient
is successful and no previous modules flaggedrequired
have failed, then no other results are required and the user is authenticated to the service.optional
— The module result is ignored. A module flagged asoptional
only becomes necessary for successful authentication when no other modules reference the interface.include
— Unlike the other controls, this does not relate to how the module result is handled. This flag pulls in all lines in the configuration file which match the given parameter and appends them as an argument to the module.
IMPORTANT
The order in which
required
modules are called is not critical. Only
the sufficient
and requisite
control flags cause order to become important.
There are many complex control flags that can be set. These
are set in attribute=value pairs; a complete
list of attributes is available in the
pam.d
manpage. PAM Module Names
The module name provides PAM with the name of the pluggable
module containing the specified module interface. The directory name is omitted
because the application is linked to the appropriate version of
libpam
, which can locate
the correct version of the module. PAM Module Arguments
PAM uses arguments to pass
information to a pluggable module during authentication for some modules.
For example, the
pam_userdb.so
module uses information stored in a
Berkeley DB file to authenticate the user. Berkeley DB is an open source
database system embedded in many applications. The module takes a db
argument so that
Berkeley DB knows which database to use for the requested service. For example:
auth required pam_userdb.so db=/path/to/BerkeleyDB_file
Invalid arguments are generally ignored and do not otherwise
affect the success or failure of the PAM module. Some modules, however, may
fail on invalid arguments. Most modules report errors to the
/var/log/secure
file. Default PAM Configuration
The following PAM modules are implemented in the PAM libraries on UnixWare:
Their functions and arguments are the same as documented in the PAM System
Administrator's Guide, except as noted below.
Name
|
Description
|
Notes
|
pam_console
|
Console Module
|
Implements the "CONSOLE" and "USERS"
defaults feature for login. See login(4). Not
implemented in Linux-PAM.
|
pam_deny
|
Locking Out Module
|
Returns an authentication failure.
|
pam_dialpass
|
Dialup Password Module
|
Implements /etc/dialups, /etc/d_passwd authentication.
|
pam_ftp
|
FTP Module
|
Implements Anonymoous FTP Authentication (i.e., prompts
for an email password.)
|
pam_lastlog
|
Last Login Module
|
Maintains the /var/log/lastlog file.
|
pam_listfile
|
List-File Module
|
Denies or allows services based on an arbitrary file.
|
pam_mail
|
Mail Module
|
This module looks at the user's mail directory and
indicates whether the user has any mail in it.
|
pam_nologin
|
No Login Module
|
If /etc/nologin exists but is empty, the message
Logins currently disabled is
returned and access is denied. |
pam_permit
|
Promiscuous Module
|
Returns authentication success.
|
pam_rhosts
|
rhosts Module
|
Provides authentication as described on rhosts(4), as
used by rlogin, rsh, and similar utilities.
|
pam_rootok
|
Root Access Module
|
Provides root access without requiring a password.
|
pam_shells
|
||
pam_unix
|
UNIX Password Module
|
The following options are always enabled:
If the nullok option is not set for the account management function, and the authenticating user has no password, the module returns PAM_NEW_AUTHTOK_REQD (same as if password was expired). This is needed to implement the login PASSREQ and MANDPASS features. |
pam_warn
|
Warning Logger Module
|
Logs information about a proposed authentication or
password update.
|
The following system utilities and applications are PAM-enabled:
- cups 1.1.19-02
- dtlogin
- dtsession
- ftpd
- login
- mail (pop and imap)
- passwd
- rlogind
- rshd
- rexecd
- samba 3.0.4
- sshd
- su
- telnetd
- xlock
Sample PAM Configuration Files
sample PAM application configuration file:
Simple PAM Configuration
#%PAM-1.0
auth required pam_securetty.so
auth required pam_unix.so nullok
auth required pam_nologin.so
account required pam_unix.so
password required pam_cracklib.so retry=3
password required pam_unix.so shadow nullok use_authtok
session required pam_unix.so
- The first
line is a comment, indicated by the hash mark (
#
) at the beginning of the line. - Lines two through four stack three modules for login authentication.
auth
required pam_securetty.so
— This module ensures that if the user is trying to log in as
root, the tty on which the user is logging in is listed in the /etc/securetty
file, if that file exists.
If the tty is not listed in the file, any attempt to log in
as root fails with a
Login
incorrect
message. auth
required pam_unix.so nullok
— This module prompts the user for a
password and then checks the password using the information stored in /etc/passwd
and, if it
exists, /etc/shadow
.
The argument
nullok
instructs the pam_unix.so
module to allow a blank password. auth required pam_nologin.so
— This is the final authentication step. It checks whether the/etc/nologin
file exists. If it exists and the user is not root, authentication fails.
NOTE
In this example, all three
auth
modules are checked, even if the first auth
module fails. This
prevents the user from knowing at what stage their authentication failed. Such
knowledge in the hands of an attacker could allow them to more easily deduce
how to crack the system. account required pam_unix.so
— This module performs any necessary account verification. For example, if shadow passwords have been enabled, the account interface of thepam_unix.so
module checks to see if the account has expired or if the user has not changed the password within the allowed grace period.password required pam_cracklib.so retry=3
— If a password has expired, the password component of thepam_cracklib.so
module prompts for a new password. It then tests the newly created password to see whether it can easily be determined by a dictionary-based password cracking program.
The argument
retry=3
specifies that if the test fails the first time, the user has two more chances
to create a strong password. password required pam_unix.so shadow nullok use_authtok
— This line specifies that if the program changes the user's password, using thepassword
interface of thepam_unix.so
module.- The
argument
shadow
instructs the module to create shadow passwords when updating a user's password. - The
argument
nullok
instructs the module to allow the user to change their password from a blank password, otherwise a null password is treated as an account lock. - The
final argument on this line,
use_authtok
, provides a good example of the importance of order when stacking PAM modules. This argument instructs the module not to prompt the user for a new password. Instead, it accepts any password that was recorded by a previous password module. In this way, all new passwords must pass thepam_cracklib.so
test for secure passwords before being accepted. session required pam_unix.so
— The final line instructs the session interface of thepam_unix.so
module to manage the session. This module logs the user name and the service type to/var/log/secure
at the beginning and end of each session. This module can be supplemented by stacking it with other session modules for additional functionality.
Use of pam_listfile.so module
This PAM module authenticates users based on the contents of a specified file. For example, if username exists in a file /etc/sshd/ssh.allow, sshd will grant login access.
How do I configure pam_listfile.so module to deny access?
You want to block a user, if user-name exists in a file /etc/sshd/sshd.deny file.
Open /etc/pam.d/ssh (or /etc/pam.d/sshd for RedHat and friends)
# vi /etc/pam.d/ssh
Append following line:
auth required pam_listfile.so item=user sense=deny file=/etc/sshd/sshd.deny onerr=succeed
Save and close the file
Now add all usernames to /etc/sshd/sshd.deny file. Now a user is denied to login via sshd if they are listed in this file:
# vi /etc/sshd/sshd.deny
Append username per line:
user1
user2
...
Restart sshd service:
# /etc/init.d/sshd restart
Understanding the config directives:
auth required pam_listfile.so : Name of module required while authenticating users.
item=user : Check the username
sense=deny : Deny user if existing in specified file
file=/etc/sshd/sshd.deny : Name of file which contains the list of user (one user per line)
onerr=succeed : If an error is encountered PAM will return status PAM_SUCCESS.
How do I configure pam_listfile.so module to allow access?
You want to ALLOW a user to use ssh, if user-name exists in a file /etc/sshd/sshd.allow file.
Open /etc/pam.d/ssh (or /etc/pam.d/sshd for RedHat and friends)
# vi /etc/pam.d/ssh
Append following line:
auth required pam_listfile.so item=user sense=allow file=/etc/sshd/sshd.allow onerr=fail
Save and close the file.
Now add all usernames to /etc/sshd/sshd.allow file. Now a user is allowed to login via sshd if they are listed in this file.
# vi /etc/sshd/sshd.allow
Append username per line:
tony
om
rocky
Restart sshd service (optional):
# /etc/init.d/sshd restart
Now if paul try to login using ssh he will get an error:
Permission denied (publickey,keyboard-interactive).
Following log entry recorded into my log file (/var/log/secure or /var/log/auth.log file)
tail -f /var/log/auth.log
Output:
Jul 30 23:07:40 p5www2 sshd[12611]: PAM-listfile: Refused user paul for service ssh
Jul 30 23:07:42 p5www2 sshd[12606]: error: PAM: Authentication failure for paul from 125.12.xx.xx
Understanding the config directives:
auth required pam_listfile.so : Name of module required while authenticating users.
item=user : Check or specify the username
sense=allow : Allow user if existing in specified file
file=/etc/sshd/sshd.allow : Name of file which contains the list of user (one user per line)
onerr=fail : If filename does not exists or username formatting is not coreect it will not allow to login.
No comments:
Post a Comment