We’re giving away 1,500 more DJI Tello drones. Enter to win ›
Vishal Srivastava | Published March 10, 2009
For Linux users, sharing files securely is a cumbersome
task. For example, needing to recall multiple passwords is taxing, and redesigning system access applications (like login, su, password, ftp, etc.) is time-consuming. Adding to the difficulty is the process of authentication, where a system identifies a user and provides deserved access control to that user.
PAM is an API that takes care of authenticating a user to a service. Before PAM, applications like login (and rlogin, telnet, rsh) looked for the username in /etc/passwd, then compared the two and authenticated the user-typed name. All applications used these shared services, although the implementation details and authority to configure them was not shared.
Next, application developers tried coding their own processes. With this came the need to separate the application and security module (a common security module can be shared by applications and can be configured as needed).
The PAM mechanism integrates multiple low-level authentication schemes into a high-level API that allows programs that rely on authentication to be written independently of the underlying authentication scheme. The principal feature of PAM is the dynamic configuration of authentication through either an /etc/pam.d or /etc/pam.conf file.
PAM can be configured to deny certain programs the right to authenticate users and to warn when certain programs attempt to authenticate. PAM programs make use of PAM modules (authentication modules): They are attached to applications at runtime in order to work.
Figure 1 shows the basic flow of the PAM model.
PAM was first developed by Sun Microsystems in 1995 and is supported by the following operating system versions (and higher):
PAM is also supported by recent versions of Solaris™, AIX®, HP-UX, and Mac OS® X. PAM was later standardized as a part of X/Open UNIX® standardization process (in the X/Open single sign-on service (XSSO) architecture).
Though they are not strictly classified, you could say there are three kinds of PAM:
Although these are different PAMs, their primary functionality remains the same.
Installing PAM is a step-by-step process. See Related topics for installation instructions.
PAM modules are classified into module type. Any given module should implement at least one of the four module type functions:
PAM provides different functional capabilities, such as single sign-on authentication, access control, and more. The implementation of each are handled by different modules. Here are some of the major modules:
There are many other modules (pam_userdb, pam_warn, pam_xauth), which take a set of values which they return. (Details of these modules can be found in the PAM administration guide in Related topics.)
PAM configuration is generally implemented in the configuration file residing in /etc/pam.d or /etc/pam.conf (for old versions).
For each service that uses PAM, there is a corresponding file in the directory, which contains the rules or instructions for how authentication and account information should be obtained for that service. There is usually one rule per line.
Fields in the PAM configuration files include:
The modules are invoked in the order in which they are listed in the configuration file, depending on what the Control_flag for each entry allows. Control_flag values include:
Table 1 shows some examples of PAM configuration files on various operating systems.
The default PAM configuration file /etc/pam.d is used for all other services that are not explicitly configured and is perhaps the simplest and most robust default file upon which PAM relies. The internals look something like this:
auth required pam_warn.so
auth required pam_deny.so
account required pam_warn.so
account required pam_deny.so
password required pam_warn.so
password required pam_deny.so
session required pam_warn.so
session required pam_deny.so
This file is very simple. For all module types, the Control_flag is the same: required. Two modules are called:
Therefore, any service that uses PAM must be explicitly configured to allow authentication; otherwise, attempts will fail.
These 10 steps can help you implement your own PAM application and help you understand the workings of a PAM session:
Relying on PAM to help wrangle low-level authentication efforts into a more manageable whole is a sound move to simplifying this security mechanism. In this article, you’ve learned:
Now you can move onto the more advanced topics in using PAM modules—starting with the resources on the right.
This article provides a way to implement a kernel module on Linux, compile it, and explore ways in which a…
IBM OpenPOWER servers support secure boot of system firmware to ensure the system boots only authorized firmware. When the system…
IBM Power SystemsLinux+
IBM OpenPOWER servers provide a firmware level security feature known as Trusted Boot. Trusted Boot helps defend against a boot…
Back to top