Welcome!

Linux Containers Authors: Liz McMillan, Elizabeth White, Zakia Bouachraoui, Pat Romanski, Stefana Muller

Related Topics: Linux Containers

Linux Containers: Article

Pam Up!

Dressing up for security success

Linux PAM (Pluggable Authentication Modules) is a wonderful authentication application library that's used by essential programs like 'login' and 'passwd', and, so, is included in virtually every Linux distribution. Still, for most beginning Linux users and even a few veterans, PAM is a big unknown, its powers left dormant awaiting a brave user to venture in and become empowered.

Seriously though, PAM, as configured by the distros and applications that support it, works well behind the scenes without the user ever needing to change its configurations. Unfortunately the default configurations aren't the most secure. Of course security also depends on how the system is used. Only by becoming familiar with PAM, can a user learn what features to adjust to accommodate their individual system.

This article is meant to give you an overview of what PAM is and what you can do with it. I'll discuss how to know if a particular application supports PAM, touch on a few services that support PAM and the configuration file structure, explain how to configure a PAM-enabled service and how the configuration file is processed, and go over several well-known PAM modules including a real-life example.

Let's begin with what PAM is.

PAM has been around for a while now. It was first implemented on Solaris and later adopted by the other Unix-like operating systems. Before PAM was introduced into Linux, applications took care of their own authentication needs and mechanisms. Take one of the most basic and essential Linux application, the 'login' program. In a nutshell, the way 'login' is programmed, is to ask for your user name, and then ask you for your password.

Before PAM, 'login' would look up your user name in /etc/passwd and compare the encrypted password found there with the encrypted version of the one you entered. If there was a match, you were granted access. Like 'login', other applications that required user authentication (such as rlogin, rsh, telnet, and so on) had to use a similar scheme separately. Usually, the application had to do other minor procedures like setting up environment variables. Authentication requirements like this were shared by the different services, but the code to do it wasn't shared.

As Linux and the other Unixes evolved, it became evident that coding your own authentication process was too cumbersome for application developers. If the way the user names and passwords were stored changed (and it did when the passwords moved to /etc/shadow), then developers would have to modify and recompile their applications to accommodate this, or they would stop working.

Since applications were doing a common thing, authentication, you could create a common library that would take care of this process for any application willing to use it. And you could make this library configurable by adding modules that could accept parameters for making speci-fic checks to fit the application. Obviously, these configurations would need to be specified on a per-application (also called a service) basis, while still having a default configuration. Changing these configurations could be done recompiling the service. This would effectively separate the authorization logic tied to the existing system from the services themselves, making things easier for developers and making the system more versatile.

Enter Linux PAM. The Linux Pluggable Authentication Modules, as adopted also by Linux, help you do all of this. It's a flexible system that lets you specify things like: which users can become the root with the su command, set additional environment variables on login or user switching, require stronger passwords, impose user limits like file sizes and maximum number of processes and lock out users after a set number of failed logins.

It's a powerful system too. You can change the user base against which a service authenticates into an ldap server or MySQL server for a centralized user base scenario, instead of the password file.

Now, the PAM-enabled login program doesn't look up a user in a file and compare passwords itself. In fact, it hands this procedure off to PAM sending it the user name and password that the user entered and PAM comes back with an 'aye' or 'nay' for the user's credentials. So it's PAM (actually, PAM modules) that goes into the password file, if it's configured that way, to check the user's credentials. Some kind of cyber-outsourcing, you say? You could say that.

There are a number of services besides the login service that hand off to PAM. Those services are said to support PAM by linking to the PAM library. There are a couple of ways to see if a certain service or application supports PAM. One is by checking in the /etc/pam.d directory. Usually, services linking to PAM will install a file named after the service (for example, /etc/pam.d/samba or /etc/pam.d/passwd) at that location. Another way to see if a program links to PAM is to use the ldd command:


# ldd /bin/su

 ...

 libpam.so.0 => /lib/libpam.so.0 (0xb7f9c000)

 libpam_misc.so.0 => /lib/libpam_misc.so.0 (0xb7f99000)

 ...

The ldd command will tell you the libraries an executable links to. As you can see from the output above, the 'su' command links to libpam and libpam_misc. So you can be certain that 'su' supports PAM.

Now, let's look at how to configure a PAM-enabled service.

Configuration files for each PAM-supporting service are stored in the /etc/pam.d directory. There is also another file in there called 'other' that serves as the default configuration for any PAM-enabled service that doesn't have its own file.

Another PAM directory worth mentioning is /lib/security. This is where PAM modules (files ending in .so since they are shared libraries) are installed by the distribution and most PAM-supporting applications.

Let's look at the configuration file for the sshd (SSH daemon) service to get to know the configuration file syntax:


#%PAM-1.0

auth       required     pam_stack.so service=system-auth

auth       required     pam_shells.so

auth       required     pam_nologin.so

account    required     pam_stack.so service=system-auth

password   required     pam_stack.so service=system-auth

session    required     pam_stack.so service=system-auth

Now, we go over how configuration files are processed.

PAM processes configuration files when the corresponding service in-vokes it to give a user authorization for a given service. The processing result will decide whether the requested ser-vice is granted or denied.

A line in the configuration file is divided into four parts. The first part is the module type, second is the control flag, third the PAM module file path, and fourth are the module's arguments, as shown in the following example:


module-type    control-flag    module-file-path    module-arguments

The module type can be one of four words: auth, account, password, or session. A module type can be thought of as an interface that a PAM module may or may not respond to. Usually PAM modules (those *.so files in /lib/security) respond to more than one interface, maybe even all four of them, but at the very least they will respond to one of them. The module type 'auth' authenticates by requesting an iden-tification (for instance, a user name) and credentials (such as a password) and checking them against the data base (such as /etc/passwd and /etc/shadow). The 'account' module type checks if a user is authorized to use the requested service even if the user can authenticate successfully on the 'auth' lines. Things that can restrict a user from the service are if the account has expired or if he's restricted to access at specific times during the day. The 'password' module type asks the user to set a new password, if the current one has expired or is otherwise invalid, and to set the password in the user base. The 'session' module type prepares and logs the user's session. It can set up an exclusive temporary directory for the user, do directory mounts to make data available, record the user's login time in the system log, or display an important message after the user has logged in.

Note from the example above that the configuration lines can be stacked by module type (also referred to as module type stack). In other words, there can be multiple lines with the same module type and they all contribute to the success or failure of processing that module type as a whole.

The second part of the configuration line, the control flag, can be one of four words: required, requisite, sufficient, or optional. This flag tells PAM, after processing the line, how to treat the results. The 'required' flag means that the line must give a successful result for the service to grant access. A failure won't stop the processing of the remaining lines in that module type stack according to their control flag. After the module type stack is processed, a failed result, it's communicated to the service and, consequently, to the user. The 'requisite' flag also means that the line must result in a success to grant the service. However, if there is a failure, processing will stop immediately and PAM communicates the failure of the first failed 'required' or 'requisite' line in the stack back to the service.

The 'sufficient' flag says that a successful result on that line means an automatic success on that module type stack's processing, as long as no other modules in the module type stack before it have failed. PAM can then continue on with the next module type stack. If the line returns a failure, the result is ignored and the next line is processed.

The 'optional' flag means that a success or failed result on that line won't contribute to the success or failure result of the module type stack, unless it's the only line in that stack or it's the only one in the stack that returns a success or a failure. This means that the result from a processed line can be something that is neither a success nor a failure. These kinds of non-definitive results are usually ignored.

The third part of the configuration line is the module's file path. PAM modules will be found in /lib/security. If the PAM module is in this directory, there's no need to specify the full path. Simply by saying 'pam_tally.so', for example, will tell PAM to look for it in /lib/security. In the rare case that the PAM module you're using is somewhere else (an application could install it in its own directory), then you can specify the full path.

The fourth part of the configuration line is the module's arguments. Arguments are separated by spaces. Sometimes an argument can be one word (for instance, use_first_pass) or a name/value pair like 'service=system-auth'. To find out more about the module's arguments for a specific module, look into /usr/doc/pam-*/modules (accor-ding to the version of your PAM installation.

On an rpm-based system, you can find your PAM's version with the following syntax:


rpm -q pam

This will display the contents of the pam_tally module documentation on my system, as shown in this example:


# zless /usr/doc/pam-0.77-r1/modules/README.pam_tally.gz

In the case of a module that didn't come with PAM, like pam_smbpass for example, your best bet is to look in the documentation of the application that installed it. If I wanted to know which application installed pam_smbpass in an rpm-based system, I can enter the following command:


rpm -qf /lib/security/pam_smbpass.so

Finally, comments in the configura-tion file are preceded with a '#' symbol.

Going through the configuration file for sshd as shown above, you will see that the first line invokes the module pam_stack with the argument of service=system-auth. The pam_stack module is a special module. You can think of it as an include directive (for those of you who are developers). What PAM will do on seeing this module is to look for the configuration file speci-fied in the service argument, system-auth in this case, and process the lines in that file that correspond to the module type line where pam_stack was encountered.

So, to go through sshd's configura-tion file you need to go into the system-auth configuration file. You will see that this is the case for many of the other services too. This file, system-auth, is actually the master configuration file for PAM since most other configuration files point to it through the pam_stack module. The following are its contents:


#%PAM-1.0

auth       required     /lib/security/pam_env.so
auth       sufficient   /lib/security/pam_unix.so likeauth nullok

auth       required     /lib/security/pam_deny.so

account    required     /lib/security/pam_unix.so

password   required     /lib/security/pam_cracklib.so retry=3

password   sufficient   /lib/security/pam_unix.so nullok md5 shadow use_authtok

password   required     /lib/security/pam_deny.so

session    required     /lib/security/pam_limits.so

session    required     /lib/security/pam_unix.so

The first line sets environment variables according to /etc/security/pam_env.conf. The second line checks the user's credentials against the system's user database. The 'nullok' parameter means that a NULL or empty password is acceptable. The 'likeauth' is used internally to ensure that the module returns the same result (or return code) that the internal func-tion that does the authentication returns. If this line passes, then the module stack has executed successfully since it was marked as sufficient. If it fails, then the next line is evaluated, which invokes pam_deny. This module always returns a failure, so if you get to this point the auth module stack fails, and the user isn't authenticated.

At this point, processing is returned to the sshd configuration file since the modules referenced by the pam_stack module have been processed. So the next line in that file calls pam_shells and it's required. pam_shells looks into /etc/passwd to figure out which shell the user is set to use. If this shell isn't in /etc/shells, the line returns a failure, otherwise, it returns a success. Continuing with the next line, you still are in the auth module stack and the pam_nologin module is called. If an /etc/nologin file exists, the line fails unless the root user is requesting the service. The next lines for the account, password, and session module types also call the pam_stack module, so you continue to follow the system-auth configuration file starting with the account module stack. The first line in that stack checks if the user's password has expired. If so, the 'password' stack is evaluated and the user is prompted to enter a new password. pam_cracklib checks the new password against dictionary words. If it finds a match, the password is too weak and the user is prompted to try again.

The 'retry=3' parameter means the number of chances the user gets to enter a password that's strong enough according to pam_cracklib. The next line in the password stack stores the newly created password in the system's user database. The use_authtok parameter tells PAM to store the password entered in the previous line in the user database. The md5 and shadow parameters tells PAM what encryption algorithm to use when storing the password and how to save it, respectively. Since this line is marked as sufficient, processing will stop if the password is set successfully. If this line fails in setting the new password, the next line will be processed, pam_deny, which automatically returns a failure for that stack. The next line, starting the session module stack, establishes resource limits for the user according to the /etc/security/limits.conf file. The next and last line logs the user's login time in the system log. Finally, PAM has finished processing the sshd configuration file and control is passed back to the ssh service which, based on the results, grants or denies access.

Let's go over some PAM modules.

Now that you know how the PAM configuration files are processed, all you need to do is become acquainted with the modules in /lib/security. PAM comes with several modules; others can be found on the Web. For example, you can use the pam_chroot module included with PAM in a session line, and based on a list of users and directories specified in /etc/security/chroot.conf, control which users login to a chrooted environment where they can't get to the rest of your system. Another useful one is pam_listfile. It can be used on an auth module type to specify a list of groups or users who are either allowed or not allowed to authenticate as seen in this example:


...

auth required pam_listfile.so item=user sense=allow onerr=fail

file=/etc/allowusers

...

Those arguments above configure pam_listfile to let (sense) users (item) listed in /etc/allowusers (file) access the service. If the check generates an error, as it would if the list didn't exist, the onerr argument decides if this causes the line to succeed or fail. The pam_rootok module can be used in auth module type lines. It returns success if the user requesting the service is the root user, otherwise it returns a failure. Convenient for using it with the sufficient control flag when you want to give the root unchallenged access to a service.

If you wanted to lock out users who failed at entering their passwords correctly after eight attempts, you could use the pam_tally module in the system-auth configuration file by adding two lines like this:


auth         required     /lib/security/pam_tally.so no_magic_root

...

account    required     /lib/security/pam_tally.so deny=8 no_magic_root

...

Then you need to create /var/log/faillog and set it to read/write only by root:


# touch /var/log/faillog

# chmod 600 /var/log/faillog

The deny argument caps the number of failed login attempts after which access will be denied even if the correct password is entered. The no_magic_root option is necessary. The pam_tally auth line increments the number of attempted logins by one and stores this information per-user in /var/log/faillog. The account line resets the count to zero, if the user was authenticated and the number of failed logins are less than whatever is specified in the deny argument. If the count isn't reset, the count will keep incrementing until it reaches the deny total. From this point on, the account line will return a failure every time until the tally is reset and locks out the user. pam_tally comes with an executable by the same name. Type 'pam_tally --help' as root to learn about its usage. To reset the tally for a user and unlock his account, type 'pam_tally --user myuser --reset'.

Now, let's show a simple real lifeexample.

I like to use Samba in my home LAN for file sharing, since there's an occasional mix of Windows and Linux computers there. My Linux box always acts as the file server and everyone has an account there. In this simple setup, I found it annoying to have to add all the users in the Linux box to the Samba password file or else Samba wouldn't recognize them. Since there's a PAM configuration file for Samba, I decided to modify it so it won't check its own password file (in /etc/samba/private/smbpasswd on my Gentoo system) and use the /etc/passwd file where everyone was already. Samba uses the pam_smbpass module which looks up users in smbpasswd.


#auth       required     pam_smbpass.so nodelay

auth       required   /lib/security/pam_unix.so likeauth



account    required     /lib/security/pam_stack.so service=system-auth



session    required     /lib/security/pam_stack.so service=system-auth



#password   required     pam_smbpass.so nodelay smbconf=/etc/samba/smb.conf

password   required     /lib/security/pam_stack.so service=system-auth

By commenting the calls to pam_smbpass in the /etc/pam.d/samba configuration file and replacing them with a call to pam_unix (which uses the current system's user base, /etc/passwd), I'm almost done with the setup. One more thing to do is to make sure that your Samba configuration file (/etc/samba/smb.conf) has the following options:


encrypt passwords = no

obey pam restrictions = yes

Turning on 'obey pam restrictions' tells Samba to invoke PAM for performing the authentication. The 'encrypt passwords' option must be turned off since Samba's password encryption will conflict with the pam modules. This means that passwords will be sent in clear text over the Samba connection. It's a minor concern for my small home LAN.

Always remember to be careful when playing around with the PAM configuration since you can find yourself locked out of your system. Get in the habit of making backup copies before you change something and use the pam_rootok modules when testing different configurations to make sure that the root user can get through in case you bump into problems. As a last resort, you can always login in single-user mode and reverse your changes as root without being authenticated. You can also use a live cd distro like knoppix, to boot your machine, mount your hard disk, and reverse your PAM changes from the outside.

There are other nifty PAM modules out there that offer better password encryption, authentication via Bluetooth, and a MySQL system database. You can visit the references below and experiment.

Now that you're familiarized with the inner workings of PAM, have fun with it, and use your new found powers responsibly!

Resources

  • www.kernel.org/pub/linux/libs/pam/
  • http://pubwww.tudelft.nl/swat/help/PAM-Authentication-And-Samba.html
  • http://freshmeat.net/search/?q=pam§ion=projects&x=0&y=0
  • http://sourceforge.net/projects/pam-mysql/
  • More Stories By Renier Morales

    Renier Morales has been a Linux user since college but only really started to delve in about four years ago while he was working at IBM. He has been working at the IBM Linux Technology Center on the OpenHPI project (http://openhpi.sourceforge.net) for the past two. He lives in Poughkeepsie, NY where he is pursuing his Master's in Computer Science.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    IoT & Smart Cities Stories
    At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
    Druva is the global leader in Cloud Data Protection and Management, delivering the industry's first data management-as-a-service solution that aggregates data from endpoints, servers and cloud applications and leverages the public cloud to offer a single pane of glass to enable data protection, governance and intelligence-dramatically increasing the availability and visibility of business critical information, while reducing the risk, cost and complexity of managing and protecting it. Druva's...
    BMC has unmatched experience in IT management, supporting 92 of the Forbes Global 100, and earning recognition as an ITSM Gartner Magic Quadrant Leader for five years running. Our solutions offer speed, agility, and efficiency to tackle business challenges in the areas of service management, automation, operations, and the mainframe.
    The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
    With 10 simultaneous tracks, keynotes, general sessions and targeted breakout classes, @CloudEXPO and DXWorldEXPO are two of the most important technology events of the year. Since its launch over eight years ago, @CloudEXPO and DXWorldEXPO have presented a rock star faculty as well as showcased hundreds of sponsors and exhibitors! In this blog post, we provide 7 tips on how, as part of our world-class faculty, you can deliver one of the most popular sessions at our events. But before reading...
    DSR is a supplier of project management, consultancy services and IT solutions that increase effectiveness of a company's operations in the production sector. The company combines in-depth knowledge of international companies with expert knowledge utilising IT tools that support manufacturing and distribution processes. DSR ensures optimization and integration of internal processes which is necessary for companies to grow rapidly. The rapid growth is possible thanks, to specialized services an...
    At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
    There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering consumer-like user experience for support and operations. We have built the world’s first AI-driven IT / HR / Cloud / Customer Support and Operations solution.
    Codete accelerates their clients growth through technological expertise and experience. Codite team works with organizations to meet the challenges that digitalization presents. Their clients include digital start-ups as well as established enterprises in the IT industry. To stay competitive in a highly innovative IT industry, strong R&D departments and bold spin-off initiatives is a must. Codete Data Science and Software Architects teams help corporate clients to stay up to date with the mod...
    Scala Hosting is trusted by 50 000 customers from 120 countries and hosting 700 000+ websites. The company has local presence in the United States and Europe and runs an internal R&D department which focuses on changing the status quo in the web hosting industry. Imagine every website owner running their online business on a fully managed cloud VPS platform at an affordable price that's very close to the price of shared hosting. The efforts of the R&D department in the last 3 years made that pos...