Custom PAM modules and security considerations

Question

I am writing my own PAM module that will be part of an application that I am developing, but I'm not sure exactly where to put it. My module basically does network-level authentication (with other mojo of course) similar to LDAP.

There are a lot of config files in my /etc/pam.d/ directory, and I know what most of the services do (except a couple, like atd, polkit, ppp). I assume that authentication with PAM stack goes something like this:

1. Runs stack based on service name (if a config file exists)
2. If not authenticated, fall back on common-*, where * is the module-type (auth, account, etc)
3. Return success or fail to calling application (and any other data of course)

Am I correct in this assumption? Do all platforms have common-auth, common-account, common-password, and common-session?

If so, I was thinking about just putting it at the top of common-* as a sufficient module so that on failure the regular PAM stack would be left unaffected. This is particularly advantageous because I can programmatically do this on software install.

Am I missing any potential security vulnerabilities?

I couldn't find very good documentation on where to integrate custom PAM modules or security issues surrounding where to put modules.

Answer 1

When you call into Linux-PAM for some authentication procedure, there is always one and only one stack that is run.

The stack definition is looked up in these places; the first successful attempt determines which file is read:

1. the file in /etc/pam.d named after the application "service name" (e.g., sshd or gdm), or

2. the file /etc/pam.d/other if no service-specific file exists, or

3. the file /etc/pam.conf if directory /etc/pam.d does not exist.

See the documentation for function pam_start for details.

The common-* files are a convention followed by many Linux distributions but are not mandated by the PAM software itself. They are usually included by other PAM files by means of @include statements; for instance the /etc/pam.d/other file on Debian has the following content:

# We fall back to the system default in /etc/pam.d/common-*
@include common-auth
@include common-account
@include common-password
@include common-session

The same @include statements may be used by service-specific file as well, and -indeed- they are in the default configuration on Debian. Note that this is a matter of configuration: a sysadmin is free to change the file in /etc/pam.d not to include any common-* files at all!

Therefore: if your PAM module is specific to your application, create an application-specific service file and call the module from there. Do not automatically add a module to other services' PAM file nor to the fall-back others file, as this may break other applications installed on the system. Management of the PAM software stack is a task for the system administrator, not for the application developers.