Osbaldestin

Information on Using PAM


What is PAM?


Pluggable Authentication Modules (PAM) allows the system administrator to set authentication policies for PAM-aware applications without having to recompile authentication programs. PAM does this by utilizing a pluggable, modular architecture. Which modules PAM calls for a particular application is determined by looking at that application's PAM configuration file in the /etc/pam.d/ directory.

In most situations, you will never need to alter the default PAM configuration files for a PAM-aware application. Whenever you use RPM to install programs that require authentication, they automatically make the changes necessary to do normal password authentication using PAM. However, if you need to customize the PAM configuration file, you must understand the structure of this file
Information about PAM, what different modules are available, and a quick guide on how to use them.


Note: This page is still being compiled. If you have any information email me =>

 
 

Using Pam in pam-aware applications


/etc/pam.d/ files:

The syntax of files contained in the /etc/pam.d/ directory, are identical to pam.conf, except for the absence of any service field. In this case, the service is the name of the file in the /etc/pam.d/ directory. This filename must be in lower case. The lines in the files are broken down into the following:

type valid entries are: account; auth; password; and session.
control what happens when auth fails, usually required, requisite, sufficient, optional (can also be [valueN=action valueN=action] where valueN is return code)
module-path /path/to/the/program (defaults to /lib/security)
module-args args


Type


auth modules provide the actual authentication, perhaps asking for and checking a password, and they set "credentials" such as group membership or kerberos "tickets."
account modules check to make sure that the authentication is allowed (the account has not expired, the user is allowed to log in at this time of day, and so on).
password modules are used to set passwords.
session modules are used once a user has been authenticated to allow them to use their account, perhaps mounting the user's home directory or making their mailbox available.


Control


required the module must be successfully checked in order to allow authentication. If a required module check fails, the user is not notified until all other modules of the same module type have been checked.
requisite the module must be successfully checked in order for the authentication to be successful. However, if a requisite module check fails, the user is notified immediately with a message reflecting the first failed required or requisite module.
sufficient the module checks are ignored if it fails. But, if a sufficient flagged module is successfully checked and no required flagged modules above it have failed, then no other modules of this module type are checked and the user is authenticated.
optional the module checks are ignored if it fails. If the module check is successful, it does not play a role in the overall success or failure for that module type. The only time a module flagged as optional is necessary for successful authentication is when no other modules of that type have succeeded or failed. In this case, an optional module determines the overall PAM authentication for that module type.


So you end up with a file looking like this (this is my vsftpd file):


#%PAM-1.0
auth required pam_listfile.so item=user sense=deny file=/etc/vsftpd/ftpusers onerr=succeed
auth required pam_stack.so service=system-auth
auth required pam_shells.so
account required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth

 


Modules Discussed


So for I have found the following modules:

pam_access pam_chroot (http://sourceforge.net/projects/pam-chroot/)
pam_console pam_console_apply_devfsd
pam_cracklib pam_debug
pam_deny pam_env
pam_filter pam_ftp
pam_group pam_issue
pam_lastlog pam_ldap
pam_limits pam_listfile
pam_localuser pam_mail
pam_mkhomedir pam_motd
pam_nologin pam_permit
pam_postgresok pam_rhosts_auth
pam_rootok pam_rps
pam_securetty pam_shells
pam_smbpass pam_stack
pam_stress pam_succeed_if
pam_tally pam_time
pam_timestamp pam_unix
pam_unix_acct -> pam_unix pam_unix_auth -> pam_unix
pam_unix_passwd -> pam_unix pam_unix_session -> pam_unix
pam_userdb pam_warn
pam_wheel pam_xauth
pam_mysql (http://pam-mysql.sourceforge.net/)

Though I admit I have not been looking hard.

Implementation Examples


pam_mysql


Please see this article here: http://www.osbaldestin.net/article.php?article=119

Example



account required pam_mysql.so user=root passwd= db=my_user_db
table=user usercolumn=username passwdcolumn=passwd crypt=0 sqllog=0

 


pam_group


The group service module for PAM accepts or rejects users based on their membership in a particular file group.

Options


deny Reverse the meaning of the test, i.e., reject the applicant if and only if he or she is a member of the specified group. This can be useful to exclude certain groups of users from certain services.
fail_safe If the specified group does not exist, or has no members, act as if it does exist and the applicant is a member.
group=groupname Specify the name of the group to check. The default is ``wheel''.
root_only Skip this module entirely if the target account is not the superuser account.
authenticate The user is asked to authenticate using his own password.


pam_chroot


Have a look at this article:
http://www.osbaldestin.net/article.php?article=120

pam_console


Have a look at this article:
http://www.osbaldestin.net/article.php?article=121

pam_mail


Example


When you place the following in /etc/pam.d/sshd, you will get the new mail prompt, when you login via ssh:


You have new mail in /var/mail/geoff.

 
 


session optional pam_mail.so

 


pam_stack


In a nutshell, pam_stack lets you "call", from inside of the stack for a particular service, the stack defined for any another service. The intention is to allow multiple services to "include" a system-wide setup, so that when that setup needs to be changed, it need only be changed in one place.

Have a look at this article:
http://www.osbaldestin.net/article.php?article=122

Example



auth required pam_stack.so service=system-auth

 

This examples calls the system-auth file.

pam_wheel


This allows the checking of a users group membership. If no group name is passed it defaults to wheel.

Example



auth required /lib/security/pam_wheel.so use_uid

 

Options



Argument Description
debug Generates additional output to syslog.
use_id Uses the current process UID and not that returned by getlogin.
This may result in the use of an effective UID and is not recommended for
production use.
trust Causes this module to succeed if the user is a member of the wheel group. This option may cause members of wheel to become root without a
password. Be very careful when using this argument.
deny Reverse the logic of this module.
group=groupname Instead of allowing users in the group wheel, allow the users in
groupname


pam_lastlog


This module provides the capability of displaying the last time-logged-in
message and the You have new mail message as module type auth and session, respectively. The former is of greater concern than the latter, as it gives away information about the computing environment. Fortunately, pam_lastlog gives you control over what is displayed.

Example



Auth optional pam_lastlog.so nohost

 

Options


Argument Description
Debug Provides verbose output to syslog.
Nodate Suppresses the display of the date of last login by this user.
Noterm Suppresses the display of the terminal name used in the last login of this user.
Nohost Suppresses the display of the host from which this user last logged in. By utilizing this argument, hostnames in your environment are not disclosed.
Silent Suppresses the entire lastlog message.
Never If the user has never logged in before, this will cause a welcome message to be displayed.


pam_access


This module provides logdaemon style login access control based on login names and on host (or domain) names, internet addresses (or network numbers), or on terminal line names in case of non-networked logins. Diagnostics are reported through syslog(3). Wietse Venema's login_access.c from logdaemon-5.6 is used with several changes by A. Nogin.

Example



account required /lib/security/pam_access.so

 

Options


The behavior of this module can be modified with the following arguments:
accessfile =/path/to/file.conf
indicate an alternative access configuration file to override the default. This can be useful when different services need different access lists.
fieldsep =separators
this option modifies the field separator character that pam_access will recognize when parsing the access configuration file. For example: fieldsep=| will cause the default `:'character to be treated as part of a field value and `|' becomes the field separator. Doing this is useful in conjuction with a system that wants to use pam_access with X based applications, since thePAM_TTY item is likely to be of the form "hostname:0" which includes a `:' character in its value.


pam_console_apply_devfsd



pam_cracklib


Supports only password module type. Used for checking password choices against the cracklib and disallows any choices found there.
Have a look at this article: http://www.osbaldestin.net/article.php?article=123

Example



password required pam_cracklib.so retry=3 minlen=6 diffok=3
password required pam_unix.so md5 use_authtok

 

pam_debug



Not so sure about this bit of information. I need to test this. If you know the answer, please let me know => Geoff Osbaldestin

 
 
1. Create an empty file at /etc/pam_debug. The PAM library checks for existence of the /etc/pam_debug file and if found, enables syslog output.
2. Edit the /etc/syslog.conf file to contain the appropriate entries for the desired levels of messages.
3. Restart the syslogd daemon so that configuration changes are recognized.
4. When the PAM application is restarted, debug messages will be collected in the output file defined in the /etc/syslog.conf configuration file.

pam_deny


This module can be used to deny access. It always indicates a failure to the application through the PAM framework. This module might be suitable for using for default (the OTHER) entries.

Example


Add this line to your other login entries to disable all accounts


login account required pam_deny.so

 

pam_env


Supports auth module type only. Uses the /etc/security/pam_env.conf file to set shell environment variables.

This module allows you to (un)set arbitrary environment variables using fixed strings, the value of previously set environment variables and/or PAM_ITEMs. All is controlled via a configuration file (by default, /etc/security/pam_env.conf but can be overriden with conffile argument). Each line starts with the variable name, there are then two possible options for each variable DEFAULT and OVERRIDE. DEFAULT allows an administrator to set the value of the variable to some default value, if none is supplied then the empty string is assumed. The OVERRIDE option tells pam_env that it should enter in its value (overriding the default value) if there is one to use. OVERRIDE is not used, "" is assumed and no override will be done.
VARIABLE [DEFAULT=[value]] [OVERRIDE=[value]]

(Possibly non-existent) environment variables may be used in values using the ${string} syntax and (possibly non-existent) PAM_ITEMs may be used in values using the

@{string} syntax. Both the $ and @ characters can be backslash-escaped to be used as literal values (as in $. Double quotes may be used in values (but not environment variable names) when white space is needed the full value must be delimited by the quotes and embedded or escaped quotes are not supported.

This module can also parse a file with simple KEY=VAL pairs on seperate lines (/etc/environment by default). You can change the default file to parse, with the envfile flag and turn it on or off by setting the readenv flag to 1 or 0 respectively.

Example


An example to see how to configure login to transpose upper and lower case letters once the user has logged in(!)


login session required pam_filter.so run1 /usr/sbin/pam_filter/upperLOWER

 


Options


The behavior of this module can be modified with one of the following flags:
debug - write more information to syslog(3).
conffile=filename - by default the file /etc/security/pam_env.conf is used as the configuration file. This option overrides the default. You must supply a complete path + file name.
envfile=filename - by default the file /etc/environment is used to load KEY=VAL pairs directly into the env. This option overrides the default. You must supply a complete path + file name.
readenv=0|1 - turns on or off the reading of the file specified by envfile (0 is off, 1 is on). By default this option is on.



Bibliography


http://scott.exti.net/susefaq/howto/pam.html
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-6.html
http://www.informit.com/articles/article.asp?p=165226&seqNum=13


This article was taken from here:
https://app.osbaldestin.net/functions/article.edit.php?article_id

Login



Search

Articles :
Advanced Search
Advertisements
Your IP : 38.107.191.92 | CSS = 3 | Version : 0.019 | Page produced in 0.1015 Seconds
Copyright © 2003-2010 osbaldestin.net <=
Layout by 404 Creative Studios. http://www.404creative.com