Gate PAM logins on SELinux enforcement with pam_sepermit

You will configure a PAM service so selected users can authenticate only while SELinux is enforcing. The module leaves users not listed in its configuration alone, so it acts as a narrow safety gate rather than replacing your normal password module. Allow about fifteen minutes for a read-only inspection and a further ten minutes 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. You also need 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'

This package provides the module, not necessarily an enabled SELinux policy or an existing sepermit.conf. A value of 1 in the enforcement interface means enforcing and 0 means permissive. If the interface is absent, SELinux is disabled or unavailable to this process; do not treat that state as a successful access-control test.

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, and %seuser matches an SELinux user name rather than an account name.

For example, this policy would gate 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 the person making the change expects, and a %seuser entry cannot match while SELinux is disabled because the assigned SELinux user cannot then be determined.

The optional exclusive argument is a separate decision:

deploy:exclusive

It allows only one login session for that user and kills the user's processes on logout. That is disruptive process-management behaviour, not a harmless variation of the enforcement check. Do not add it unless you have tested the effect and have a clear operational reason.

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 does not 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

To undo this particular change, restore the backup from the still-open recovery session:

$ 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. That is useful for a staged or service-specific file, but it does not 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 authentication 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 because the filename supplies it. Do not paste these four lines into an unrelated service without first reading that service's existing stack. PAM 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, and default=bad makes a matching user fail when SELinux is disabled or permissive, while also treating module errors as failures.

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 remains 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. Do not use a guessed service name, and do not add the module to password or session: those module types are not provided by pam_sepermit.

5. Test the match and the escape route

First test 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 by pam_sepermit only when SELinux is enforcing; in permissive or disabled states the module returns an authentication error for that match. An unlisted account returns PAM_IGNORE, so the rest of the stack can handle it.

Enable module logging only while diagnosing a controlled test:

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

The debug option sends diagnostics through syslog. Remove it after testing if the extra authentication logging is no longer needed. Never paste passwords into a log or use a production account as an experiment.

After the test, confirm the file contents and enforcement state again. If access fails unexpectedly, restore /etc/pam.d/SERVICE.bak first, then restore /etc/security/sepermit.conf.bak if the policy file was also changed. Re-test the service after each restoration so you know which change caused the failure.