Linux PAM

"Any sufficiently complicated C or Fortran program contains an ad−hoc, informally−specified bug−ridden slow implementation of half of Common. Lisp"

Without loss of generality instead of Lisp you can actually substitute "scripting language".

We can state that PAM is a classic case of Greenspun's Tenth Rule  It contains an ad−hoc, informally−specified, bug−ridden and slow implementation of half of any common scripting language such as AWK, TCL, Perl or Python.

It is a testament of "David Korn law": many programmers working on Unix does not really understand Unix: they are unable to see bigger picture and try to work around the limitations of C reinvent the bicycle by implementing features which are already implemented is more expressive languages.

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:

1. type valid entries are: account; auth; password; and session.
2. control what to do if authentication 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 ...]

3. module-path /path/to/the/program (defaults to /lib/security)
4. 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)

service type control module-path module-arguments
      

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

NEWS CONTENTS

• 191005 : SSH Root Access Login Control ( SSH Root Access Login Control, )
• 191005 : Darwish Unix Thoughts ... June 2007 ( Darwish Unix Thoughts ... June 2007, )
• 191005 : HOW TO SUSE Linux Enterprise Desktop SLED10 LDAP - Kerberos Authentication to Active Directory ( HOW TO SUSE Linux Enterprise Desktop SLED10 LDAP - Kerberos Authentication to Active Directory , )

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 [email protected] 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

#
# /etc/pam.d/common-account - authorization settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authorization modules that define
# the central access policy for use on the system. The default is to
# only deny service to users whose accounts are expired.
#
account sufficient pam_krb5.so
account required pam_unix2.so

#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
auth required pam_env.so
auth sufficient pam_krb5.so
auth required pam_unix2.so

#
# /etc/pam.d/common-password - password-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define the services to be
# used to change user passwords. The default is pam_unix2 in combination
# with pam_pwcheck.

# The "nullok" option allows users to change an empty password, else
# empty passwords are treated as locked accounts.
#
#
password required pam_pwcheck.so nullok
password required pam_unix2.so nullok use_first_pass use_authtok
#password required pam_make.so /var/yp

#
# /etc/pam.d/common-session - session-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define tasks to be performed
# at the start and end of sessions of *any* kind (both interactive and
# non-interactive). The default is pam_unix2.
#
session required pam_limits.so
session required pam_unix2.so
session required pam_mkhomedir.so umask=0077 skel=/etc/skel

#%PAM-1.0
###########line above is part of this file#################
#/etc/pam.d/su config file
###########################################################
#auth sufficient pam_rootok.so
auth include common-auth
account include common-account
password include common-password
session include common-session
session optional pam_xauth.so

Recommended Links

Softpanorama Recommended

Top articles

Sites

• The Linux-PAM Administration and Developer Guides
  • The System Administrators' Guide
  • The Module Writers' Guide
  • The Application Developers' Guide
• Security and PAM
• Linux.com Limiting Linux logins
• Windows Server 2003 R2 - LinuxQuestions.org
• Linux-PAM modules etc. page
• Centralized Authentication on Linux [Filer Wiki]
• Roles and Capabilities
• Understanding PAM Authentication and Security

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019