General security

PAM Authentication Service Administrator, Part I

December 7, 2012 by Adrian Stolarski

The idea for this series of articles came to my mind when the first series of articles about the honeypot and SELinux appeared. Sometimes we want to demonstrate knowledge, so once again I want to show that I can write about more than Agile. In fact, this article is directed to the administrators of Unix-based systems, who in the future will want to make their own changes to security systems. Despite the fact that this is their mission, surely they will find something interesting in this series. It should interest anyone who wants to learn something new about the possible solutions to authentication infrastructure.

Introduction to methods of authentication

To be able to perform any work on Linux, you need to have something that indicates a user’s identity. For example, it can be the user’s name. Confirmation of their identity is usually referred to as authentication and typically involves entering a password or digital key show. If we really want to ensure the safety of our system, we need to create and control the identity of users with great precision. Of course, you can create authentication systems in UNIX, Linux, or Windows in a number of ways, but I mention only those methods that apply to systems based on UNIX. They are:

  • Pluggable Authentication Module, or PAM for short, is really a dynamically configurable authentication mechanism that always operates at the application level. This mechanism is consistent, which means that there is no need to implement any application in any proprietary authentication procedure, but instead it is safe to use common interfaces and programming libraries. What does this consistency mean? First of all, many applications may actually refer to the same module PAM and thus use the same authentication procedure. This mechanism also has another very important advantage: the application does not have to be recompiled to change anything in the way of authentication. Only some small changes in the PAM configuration file libraries are necessary. Therefore this mechanism is completely transparent to any application.
  • Secure Socket Layer, or SSL, described by me in articles: and -to-electronic-certificates-part-ii /. Let’s quickly recall what it is. SSL is a network protocol that enables us to create reliable, bidirectional connections and to send streams of bytes. Use cryptography and encryption to guarantee privacy, integrity, and optional client authentication, and make server authentication mandatory. Everything is done using X.509 certificates. These are the facilities where the private key of the object is assigned to its name. These links are always certified by another certifying object with an electronic signature. The authority, which in practice has the public key, is called the certificate subject. The issuing authority is the issuer of the certificate. Usually the exhibitor is certified as the subject, so, as you can see, there is a chain of entities and exhibitors. In order to establish the correctness of the certificate, the software follows the chain of certificates, almost until the end of the hierarchy, or to any of the same signing the certificates. Only then will the transmission be certified as reliable.
  • Kerberos is another system that can be used to authenticate users. This is a really strong and powerful user authentication system. In practice, it uses a central database of credentials. This database is usually implemented on one or more hosts with increased security, which act as key distributors. Each of the users who want to take advantage of certain services must have either ID cards or tickets in order to use Kerberos services. Each host and anyone who works in the domain must be added to Kerberos personally.
  • Secure Shell, or SSH, is the last option. SSH provides a really strong cryptographic authentication of users who want to access remote computers.

Introduction to PAM

The ability to write PAM modules is sometimes really useful. This is particularly necessary when creating an unusual or non-standard process. In addition, sometimes it does not even know how to word miracle called PAM configure. So in this series, you will surely find more information than on most other pages. Through this article you will learn to analyze the source code of the PAM modules, and the analysis of the code can very often explain a thousand or more apparent irregularities. This series is designed for the intermediate user, both in the administration of Linux systems and programming in C. Knowledge of system administration is always something useful. When it comes to knowledge of C, I mean knowledge that will enable understanding of all written pieces of code and the ability to write your own. Let’s be honest, PAM is not always easy or pleasant, but the satisfaction that comes from mastering the skill of writing modules is simply indescribable.

So what is PAM, really? As I mentioned, this is the abbreviation for “pluggable modules authentication.” It is a set of software libraries and some interfaces for UNIX and Linux. It allows the system administrator to choose how to limit access to services. This mechanism is an integral part of many systems. PAM was developed at Sun Microsystems, which is now part of Oracle. The idea of this type of authentication caught on quickly and today there is no administrator who has not heard of it. The first system in which the PAM appeared was Solaris software and it was classified, which means that there was not a configuration file or stack of modules. But now the behavior of PAM can safely controlled by entries in the /etc pam.conf file.

What are the main assumptions of PAM?

Today a lot of applications and services exploit the PAM. Applications of this type are called pamware applications. Using PAM makes management really very easy. I do not need to recompile PAM to change the mode of access. PAM is based on a few simple assumptions.

According to the philosophy of the PAM, each administrator must be able to choose the default authentication mechanism for the operating system being used. It follows, therefore, that configuring authentication must always be associated with a specific service. This should be understood to mean that every service should have its own set of rules, which should always specify how authentication gives users the appropriate rights on the system. The advantage of PAM is that it makes it possible to configure more than one authentication method for a given service or application. PAM modules are usually arranged in a stack, so you do not always have to be given the same password. But it is always possible to enter multiple passwords when accessing one and the same service. And now it’s time to point out the great strength of PAM. PAM applications, i.e., pamware, are independent of changes in the PAM. This means that you never need to recompile to change the way you access them.

How does PAM work

PAM has several properties related to authentication. The most important of them are: authentication management, account management, session management, and password management. So how does it work in practice? Well, when you authenticate, usually the first step is to obtain the password, and the second is to verify that it is correct. This is followed by giving the user the appropriate permissions. PAM must always consider whether the user is really who he or she claims to be. If the identity is verified, PAM checks on whether the user has access to the account in the system. That’s when cases in which the user is not permitted to log on are reported. Problems occur if the password has expired or the number of permissible system logins has been exhausted. Then it goes to the management application user session. PAM is always present in the opening session and at its close. In practice, usually all the modules that are included in the user session management group are required to carry out all actions that are necessary to correct the user’s login. It is these elements that manage user devices and prepare all the services. The last group of PAM modules manages the user’s password and takes charge when a user tries to change their password or permission.

In my system, the configuration of the PAM library is located in only two places in the system, namely the file /etc/pam.conf and files in the /etc pam.d. All files in the /etc /pam.d always contain the names of services and programs, and in each of these files there is always a set of rules for authentication in your application. The contents of /etc/pam.d can vary greatly, even between two very similar systems, so there is no point in discussing them here. If you want, look at them in this directory. And here lies a problem with the PAM software. Because of this, there is never really any guarantee that the configuration of a single module or stack of modules that are copied from one distribution to another will ever work. The funny thing is that, when trying to make this type of operation we can expect problems. It may be that nothing that we wrote earlier will work.

Oh, and since we actually use PAM, we need to know about one little thing; namely, if we run the operating system, we can provide as a parameter the line: init = /bin/sh.static, or specify a different static coating. By using this solution, we can always run the entire system, completely bypassing the PAM infrastructure. This option is useful whenever the PAM configuration is broken for some reason. We should also remember one more thing: the moment you introduce some very important and very complicated modifications, you should always make a backup of all configuration files.


Today we started on the authentication of users in UNIX and Linux environments. This topic is really very interesting and requires a great deal of attention. A series of articles on UNIX authentication and Linux is probably the longest of all. It is planned to contain more than 20 articles. Why so much?

PAM will take another five articles. I’m going to explain in full how the modules look that create and manage applications using PAM infrastructure. You will learn the structure of the module and most of the features of this library and write some very interesting modules. This is especially important because it will come into play when we come to Kerberos, and we will find out very quickly what’s going on.

Then we will look at Kerberos and its authentication processes. Kerberos requires a series of articles about generating digital certificates and user authentication. Then we will look at Secure Shell and try to analyze it from the point of view of the administrator and the intruder. The culmination of the series will be about the user authentication management infrastructure, which will connect all the four elements. And here is a very important issue to you, as the readers. You have to tell me if you are interested in this type of series, just as users and administrators must say what they really expect. Articles can be written about anything, but I think it’s gratifying for everyone to see article in which all are interested. Okay, that’s the end of this article. Thank you for reading it.

Posted: December 7, 2012
Adrian Stolarski
View Profile

Adrian Stolarski is a freelance security tech blogger, specializing in Java, PHP, and JQuery. In his own words, he does the hard work of training the unemployed. Currently, he handles Evaluation Visualization for real-time systems with XWT and Eclipse RAP. If he sees that something works, he asks how it works and why it works, then sets out to make it work better. A researcher for InfoSec Institute, he currently lives in Poland, but plans to move to London.