Determining if a Linux Application is PAM-Aware

Pluggable Authentication Modules (PAM) enable administrators to integrate flexible, modular authentication schemes across Linux applications and services. This provides granular account and access control custom-fit to an app‘s security needs. But to leverage PAM, applications must link against the libpam library. This article explains how to verify if a Linux app is PAM-aware, along with an in-depth look at configuring modules to enforce access policies in practice.

How PAM Authentication Works

Before diving into detection methods, let‘s recap how PAM fits into Linux authentication architecture:

• PAM uses stackable server modules that each perform an authentication, account verification or credential management task
• Common modules include password checks, 2FA, LDAP binds, and more
• The Linux-PAM library provides the API used by PAM-aware apps to trigger this stacked module workflow
• Individual modules implement the back-end logic
• PAM configuration files control module stacking order, success/failure policies and arguments

So in summary:

• Apps leverage the Linux-PAM library to invoke authentication workflows
• The library triggers PAM modules stacked and configured via pam config files
• Modules use whatever back-end sources necessary (passwords, LDAP etc) to complete the task

With that architecture in mind, let‘s look at how to check whether an app utilizes PAM or not.

Detecting PAM Awareness

There are two simple methods to determine if a Linux application is PAM-aware:

1. Check for libpam Dependency

The first test is to check whether the app links against the libpam shared library. This can be done with the ldd command:

$ ldd /path/to/app

For example, to validate su utilizes PAM:

    linux-vdso.so.1 =>  (0x00007ffea13fe000)
    libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007fa364047000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa363c5d000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa364494000)   

We can see su depends on libpam.so, confirming it leverages PAM for authentication.

2. Check for PAM Config File

Additionally, we can verify that a PAM configuration file exists for the application. These files reside in /etc/pam.d.

For example, su should have a configuration file called /etc/pam.d/su. We can validate it as follows:

$ ls /etc/pam.d/su
/etc/pam.d/su

If no configuration file is present, then the application cannot be making use of PAM-based authentication.

So in summary, an application must:

1. Link against libpam
2. Have a configuration file under /etc/pam.d

To leverage PAM functionality.

Implementing PAM Authentication in Practice

Once we‘ve verified PAM capabilities, we can proceed to building out custom authentication flows using stacked PAM modules. Let‘s walk through some common use case implementations.

Stacked Modules Architecture

First, a quick dive into PAM stacked modules architecture:

• Each application has a configuration file consisting of rows for modules
• These rows specify:
  • Module interface (account, auth, password etc)
  • Control flag determining that row‘s importance
  • Path to the module shared library
  • Extra arguments and options
• At runtime, the app asks Linux-PAM library to authenticate
• The library reads the config rows in sequence, calling each module
• Control flags determine if overall success/failure depends on that module
• Creates a stackable, configurable flow

For example, a simplified SSH daemon config stack:

auth required pam_unix.so   
auth required pam_2fa.so
account required pam_access.so
password required pam_mkhomedir.so

This architecture allows intricate, customizable workflows tuned per-app.

Use Case 1: Enforce 2-Factor Authentication

Many applications are starting to require multi-factor authentication (MFA) for enhanced security, particularly admins accessing servers.

PAM modules make adding 2FA simple and clean. For example, to require RADIUS-based 2FA for sshd logins:

# Standard UNIX authentication
auth required pam_unix.so
# Append 2FA requirement 
auth required pam_radius.so server=1.2.3.4 timeout=10

Now, after providing their password, the user must also append a 6-digit token from a 2FA app or hardware key. The RADIUS server verifies the one-time code.

We can also stack modules for multiple factors – like UNIX password + SMS code + U2F key. Flows get intricate!

Benefits:

• Simple to graft multi-factor onto app login flow
• RADIUS integration allows leveraging enterprise authentication infrastructure
• Adds significant security against stolen credentials

Use Case 2: Centralized LDAP Authentication

Another frequent requirement is tying Linux authentication into existing LDAP or Active Directory environments. Say we want all sudo users validated against AD:

auth required pam_ldap.so server=ad.company.com ...
account required pam_ldap.so
password required pam_ldap.so
session required pam_mkhomedir.so

Here Active Directory handles the actual user credentials and account state. Home directories get auto-created as needed.

Benefits:

• Centralizes account management under corporate AD/LDAP
• Avoids duplicate user maintenance between Linux and LDAP servers
• AD group membership controls precise sudo authorization

Use Case 3: Allow Users via Whitelist File

For high-security apps, sometimes only specific allow-listed users should have access.

PAM makes this easy by integrating with flat files. For example, to only allow users listed in /allowed/ssh:

account required pam_listfile.so item=user sense=allow \
  file=/allowed/ssh onerr=fail

The pam_listfile module checks that the user matches an entry in the file. Simple but effective!

This method can also be used with hostnames, groups, IPs etc. External files keep allow/deny lists easy to manage.

Benefits:

• Simple text files manage allow/deny lists
• No need to hardcode rules in config files
• Fine-grained access control for sensitive apps

Conclusion

PAM gives Linux administrators incredible power to craft flexible, custom authentication flows on a per-application level.

Required apps must specifically leverage the PAM library, and have configuration files present under /etc/pam.d.

Once PAM capabilities verified, intricate stacks of modules can be built to check passwords, 2FA tokens, LDAP credentials – whatever an app needs for air-tight account security.

As more enterprises adopt Linux platforms with strict access requirements, understanding PAM will become an essential skill for engineers seeking fine-grained account control. This article should provide a solid starting point for getting hands-on with building secured authentication in Linux.