Gate PAM Logins on SELinux Enforcement with pam_sepermit

pam_sepermit lets chosen accounts authenticate only while SELinux is enforcing, a narrow safety gate rather than a password-module replacement. Users not listed in its configuration are left completely alone. Allow about fifteen minutes for a read-only inspection and a further ten for a carefully scheduled configuration change.

This guide covers the libpam-modules package version 1.5.3-5ubuntu5.7 installed on this machine. The local manual pages are dated 5 July 2023. Behaviour and package paths below are verified against this Linux-PAM installation; check the installed pages before copying the arrangement to another distribution.

1. Check the prerequisites and current state

You need root access for changes under /etc/security and the relevant file under /etc/pam.d, an existing PAM service to protect, and a recovery path such as an already-open root shell or console. Do not start by editing the only route into a remote machine. These commands are ordinary, read-only checks:

$ command -v getenforce
$ dpkg-query -W -f='${Package} ${Version}\n' libpam-modules
$ test -r /etc/security/sepermit.conf && sed -n '1,120p' /etc/security/sepermit.conf || echo 'no default sepermit.conf'
$ test -r /sys/fs/selinux/enforce && cat /sys/fs/selinux/enforce || echo 'SELinux enforcement interface unavailable'

• Enforcement interface reads 1. SELinux is enforcing.
• Reads 0. SELinux is permissive.
• Interface absent. SELinux is disabled or unavailable to this process; do not treat that as a successful access-control test.

This package provides the module, not necessarily an enabled SELinux policy or an existing sepermit.conf.

2. Choose the users the module should match

The default configuration file is /etc/security/sepermit.conf. Each non-comment line begins with one matching name:

• A plain name matches an account name.
• @group matches members of a group.
• %seuser matches an SELinux user name, not an account name.

For example, this policy gates the account deploy and everyone in the Unix group ops:

# Accounts in this file require SELinux enforcing mode.
deploy
@ops

Lines beginning with # are ignored. Keep the list deliberately small: a group entry can affect more accounts than you expect, and a %seuser entry can't match while SELinux is disabled because the assigned SELinux user can't then be determined.

The optional exclusive argument is a separate decision:

deploy:exclusive

3. Install the configuration with a recoverable change

$ sudo install -m 0644 -o root -g root /etc/security/sepermit.conf /etc/security/sepermit.conf.bak
$ sudo cp /etc/security/sepermit.conf /tmp/sepermit.conf.new
$ sudoedit /tmp/sepermit.conf.new
$ sudo install -m 0644 -o root -g root /tmp/sepermit.conf.new /etc/security/sepermit.conf

If the default file doesn't exist, create the temporary file with your chosen entries instead. Verify the resulting file before touching PAM:

$ sudo sed -n '1,120p' /etc/security/sepermit.conf
deploy
@ops

$ sudo install -m 0644 -o root -g root /etc/security/sepermit.conf.bak /etc/security/sepermit.conf

The module also accepts conf=/path/to/config/file in its PAM arguments, useful for a staged or service-specific file. That doesn't make an unsafe PAM stack safe: keep the path root-owned and not writable by the accounts whose access it controls.

4. Add pam_sepermit to the service stack

The module provides the auth and account module types. The manual's representative arrangement places it before pam_unix and maps a non-matching user to ignore:

auth     [success=done ignore=ignore default=bad] pam_sepermit.so
auth     required  pam_unix.so
account  required  pam_unix.so
session  required  pam_permit.so

In a file under /etc/pam.d, omit the service-name column, the filename already supplies it. Don't paste these four lines into an unrelated service without first reading its existing stack. The control actions are part of the policy:

• success=done stops the authentication stack for a matching user when SELinux is enforcing.
• ignore=ignore lets an unlisted user continue through the rest of the stack.
• default=bad fails a matching user when SELinux is disabled or permissive, and treats module errors as failures too.

For a service-specific configuration, make a backup and edit its PAM file as root. This changes live authentication behaviour, so do it in a maintenance window where the open recovery session stays usable:

$ sudo cp --preserve=all /etc/pam.d/SERVICE /etc/pam.d/SERVICE.bak
$ sudoedit /etc/pam.d/SERVICE

Replace SERVICE with the actual filename, never a guessed one, and don't add the module to password or session: those types aren't provided by pam_sepermit at all.

5. Test the match and the escape route

Test first with a listed account while watching the service's normal authentication logs. On a test host, use a harmless service that exercises the exact PAM file. A listed account should be accepted only while SELinux is enforcing; in permissive or disabled states the module returns an authentication error for that match. An unlisted account returns PAM_IGNORE, letting the rest of the stack handle it.

Enable module logging only for a controlled test:

auth [success=done ignore=ignore default=bad] pam_sepermit.so debug

debug sends diagnostics through syslog. Remove it after testing once you don't need the extra logging. Never paste passwords into a log or use a production account as an experiment.

Common traps

• Access fails unexpectedly. Restore /etc/pam.d/SERVICE.bak first, then /etc/security/sepermit.conf.bak if the policy file also changed. Re-test the service after each restoration so you know which change actually caused it.
• A group entry catches more people than intended. Recheck who's actually in that Unix group before trusting the gate's scope.
• %seuser entry never matches. Confirm SELinux is enabled; the SELinux user can't be determined while it's disabled.