Linux PAM

News	Commercial Linuxes	Recommended Books	Recommended Links	Red Hat security	Suse Security	Hardening
PAM	wheel group	Authentication and Accounts Security	Selected PAM Modules	SecurID	Humor	Etc

PAM (the Pluggable Authentication Module) is a unified authentication scheme introduced by Sun in Solaris 2.3 and later reimplemented in most open source versions of Unix (e.g. Linux and FreeBSD). It allows the system administrator to customize the authentication services that should be used for various applications. It is rather primitive mechanism that uses yet another (very simple) PAM language to connect several security checks (each check or group of checks is performed by a separate authentication module) before deciding if you can authenticate the user or not.

PAM permits per service configuration of authentication. Initially it was a single large pam.conf file. Now in Linux each service can have its own PAM configuration file in /etc/pam.d. The presence of this directory will cause Linux-PAM to ignore /etc/pam.conf. (SuSE ships by default with the /etc/pam.d directory and files).

The syntax of files contained in the /etc/pam.d directory, are identical to format in pam.conf except for the absence of service field: the service is the name of the file in the /etc/pam.d/ directory. The /etc/pam.d/other file is used to check authentication for any service where a specific pam file has not been set up.

The format of the /etc/pam.d/ files contains four fields:

type valid entries are: account; auth; password; and session.
control what to do if authentiation fails/succeed. Common variants are
- required - The success of the module is required for the module-type facility to succeed. Failure of this module will not be apparent to the user until all of the remaining modules (of the same module-type) have been executed.
- requisite - If the module returns a failure, control is directly returned to the application. The return value is that associated with the first required or requisite module to fail. This flag can be used to protect against the possibility of a user getting the opportunity to enter a password over an unsafe medium.
- sufficient - If this module succeeds and no previous required module has failed, no more `stacked' modules of this type are invoked. This means subsequent required modules are not invoked. A failure of this module is not deemed as fatal to satisfying the application that this module-type has succeeded.
- optional - This module is not critical to the success or failure of the user's application for service. In the absence of any definite successes or failures of previous or subsequent stacked modules this module will determine the nature of the response to the application.
- The newer syntax for control flags is is delimited with square brackets and consists of a series of value=action tokens with the value being set to one of the following return values The format of the syntax is: [value1=action1 value2=action2 ...]
module-path /path/to/the/program (defaults to /lib/security)
module-args args

Historical note: in /etc/pam.conf the first field initially was service -- the name of the daemon or program, for example ssh, login or su

Additional PAM /etc/security files

Some of the modules have additional configuration files in /etc/security.

The /etc/security/access.conf can be used to greatly restrict who can login from where. You can limit console logins to only specific UIDs, or combinations of specific UIDs and ttys. However, in addition to configuring this file, you must set up the PAM login rules to read this file. The pam_access.so library is the program that enforces the rules. Edit /etc/pam.d/login and add this line to activate the /etc/security/access.conf file in PAM:

# add login restrictions (access.conf)
account required pam_access.so

It goes after the other account required line that handles normal logins (this is called stacking).

Then, edit the /etc/security/access.conf file to set up access controls. Here is an example entry so that no users except the user libadmin can login on tty1. Add this line:

-:ALL EXCEPT libadmin:tty1
Note: root can still access the machine through su or sshd.

The /etc/security/limits.conf can be used to restrict system resource usage by UID. The pam_limits.so library is the program that enforces the limits. It must be set up in the /etc/pam.d/login file as a session rule, usually at the end of the file:

session required pam_limits.so
The /etc/login.defs file, which is part of the shadow suite, is also honored by PAM if you include the pam_pwcheck.so library in your PAM configuration. It must be set up in the /etc/pam.d/login file as a password rule:

password required pam_pwcheck.so nullok
With /etc/login.defs, you can control the minimum password length, expiration time, and many other things.

In modern Linux distributions, most programs are PAM enabled. For a program to use PAM, it must have the PAM functions included in it for authentication and authorization. To check to see if a program is pam enabled, do an ldd on it and look for PAM libraries linked to it:

libpam_misc.so.0 => /lib/libpam_misc.so.0 (0x4002b000)
libpam.so.0 => /lib/libpam.so.0 (0x4002e000)

Notes:

Those pages are written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected.
This is a Spartan WHYFF (We Help You For Free) site. It cannot replace the best teachers and the best books.
The site contain some obsolete pages as it develops like a living tree... Some links on older pages are broken. Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link.

Search Amazon by keywords:
Open directory	Research Index

Old News ;-)

SSH Root Access Login Control

After read “OpenSSH Root user account restriction - revisited” article, I did a test on my testing server.

The pam_access PAM module is mainly for access management. It provides logdaemon style login access control based on login names, host or domain names, internet addresses or network numbers, or on terminal line names in case of non-networked logins. By default rules for access management are taken from config file /etc/security/access.conf if you don’t specify another file.

Example: Grant root access for IP Address: 192.168.1.10 ONLY
1. vi /etc/pam.d/sshd and append
account    required     pam_access.so 
2. vi /etc/security/access.conf and add as shown below
#Denied ALL
- : root : ALL  
# ONLY allow IP 192.168.1.10
+ : root : 192.168.1.10.
Save both file and it’s worked! I can ssh root@planetmy.com from 192.168.1.10 but not other machine.

Note: as soon as you save changes to /etc/security/access.conf, they are applied by PAM configuration. So be careful when writing rules and please backup before do any changes on your file.

Check here for more understand about pam_access.

Darwish Unix Thoughts ... June 2007

Unix Administration (II): Security (B)
Here's the second step of securing our college server as mentioned in the first article (II - A). I try to construct a suitable security policy using the lovely and completely flexible PAM configuration files. I assume that the reader have previous experiences with PAM, if not, please look at this very well-written and official PAM guide.

--> First step is to modify the common-{auth, account, password, session} files since they are included in all specific programs PAM files.

01- Don't accept NULL passwords in any program by removing the nullok option:
In /etc/pamd.d/common-auth file:
auth required pam_unix.so

02- Disallow root logins from anywhere (pam.d/su will be modified not to include common-auth):
emptying the /etc/securetty:
$ : > /etc/securetty
In /etc/pam.d/common-auth:
auth requisite pam_securetty.so
Note: Emptying the securetty file without adding the above line will have no effect.

03- Let only users set on /etc/security/access.conf be able to login (assuming they already passed the above stacked rules).
In /etc/security/access.conf:
# Accept `root' and `ahmed' logins only (till the system go mainstream)
+:root:ALL
+:ahmed:ALL
-:ALL:ALL
In /etc/pam.d/common-account:
account required pam_access.so

04- Enable large passwords (> 8) by using MD5. Also let user chosen passwords be tested by cracklib which checks user desired passwords against dictionaries and other common password patterns.
$ # Several dictionaries to be used by cracklib
$ apt-get install wbritish wamerican wfrench wdutch
$ # cracklib installation. If PAM rules are set without it, no passwords could be changed!
$ apt-get install cracklib2
$ # Install the pam_cracklib module
$ apt-get install libpam-cracklib
Add the PAM rules to satisfy the following conditions in desired passwords:
a- Minimum difference between a new and old password = 4
b- Minimum length = 12
c- Prompt user at most 4 times before running with error
d- At least 2 digits, 2 upper case letters, 2 lower case ones and 2 other (!#$...) letters
In /etc/pam.d/common-password:
password required pam_cracklib.so retry=4 minlen=12 difok=4 \ dcredit=-2 ucredit=-2 lcredit=-2 ocredit=-2
password required pam_unix.so use_authtok md5
Note: The use_authtok directive is necessary to hand over the password from the previous module

05- Many programs use $TMPDIR for storing temporary files. Not all of them are good at securing the permissions of those files. PAM tmpdir module sets $TMPDIR and $TMP for PAM sessions to /tmp/user/[uid]. Permissions are tight since /tmp/user is only read/write by root. /tmp/user/[uid] is only {read, write, execut}able by that user.This leads to an extra layer of security, making symlink attacks and other /tmp based attacks harder or impossible.
$ apt-get install libpam-tmpdir
in /etc/pam.d/common-session:
session optional pam_tmpdir.so

06- UMASK usage in login.conf is discouraged cause it catches only entries made through login, while setting umask in shell rc files will catch also logins through su, cron, ssh but not other shells. At the same time, using shell rc to set umask won't catch entries which user uses non-shell executables in place of login shell, like the ppp daemon. To solve all of this ambiguity and redundancy problems, it's best to use the pam_umask PAM module.
$ apt-get install libpam-umask
In /etc/pam.d/common-session:
session optional pam_umask.so umask=007
--> Second step is to modify the pam.d/others file. if a PAM-aware service exists with no specific PAM file, the `other' file will be used. This file will deny all services but issue a warning in the logs to the sleeping admin! ( not my type, right ? ;) )

$ : > /etc/pamd.d/other
In /etc/pam.d/other:
auth required pam_deny.so
auth required pam_warn.so
account required pam_deny.so
account required pam_warn.so
password required pam_deny.so
password required pam_warn.so
session required pam_deny.so
session required pam_warn.so

--> Third step is to modify the PAM files related to each PAM-aware app as follows:

1- Login, ssh:
01- Remove System details from login/ssh screens
In /etc/pam.d/login:
session optional pam_motd.so motd=/etc/motd
$ cat > /etc/motd.tail
If any problem is found, contact Ahmed S. Darwish - the server admin - at darwish.07 gmail com
Thanks
^D
$ # /etc/motd is a symbolic link for /var/run/motd
$ sed -i 's#uname -snrvm > /var/run/motd#: > /var/run/motd/#' /etc/init.d/bootmisc.sh
$ cat > /etc/issue
Faculity of Computer Science and Information Unix Lab
^D
In /etc/pam.d/login:
auth required pam_issue.so issue=/etc/issue

02- Passwd:
Above customized defaults in common-password are enough.

03- su:
01- Let root be able to do "su" to anything
auth sufficient pam_rootok.so

02- Let the group "wheel" (gid = 0) be the only group allowd to invoke a `su' to root.
$ groupadd wheel && usermod -G wheel ahmed
In /etc/pam.d/su:
auth required pam_wheel.so use_uid

03- Don't use the customized defaults found in common-auth since it does not allow root logins. If it's included, as in the out of the box configuration, you won't be able to access root by any means (except by using init=/bin/sh as a kernel parameter).
$ sed -i 's/@include common-auth/#@include common-auth/' /etc/pam.d/su
$ echo "auth required pam_unix.so" >> /etc/pamd.d/su

I hope you found this article interesting.

To Be Continued ...

HOW TO SUSE Linux Enterprise Desktop SLED10 LDAP - Kerberos Authentication to Active Directory