Give Each PAM Login Its Own Kernel Session Keyring

A key created in one login showing up automatically in a completely different login by the same user is exactly the leak pam_keyinit exists to close. Adding it to a PAM session stack gives each login a session keyring separate from the user's default one. Allow about 15 minutes, plus time to arrange a recovery path if the target is a remote machine.

This guide covers Linux-PAM 1.5.3-5ubuntu5.7 from the installed libpam-modules:amd64 package. The module is built for login processes, not general-purpose key management: it does not create or inspect arbitrary keys on its own.

1. Check the installed module

Run these as your ordinary user first; they change nothing:

$ dpkg-query -W -f='${Package} ${Version}\n' libpam-modules:amd64
libpam-modules 1.5.3-5ubuntu5.7
$ test -f /usr/lib/x86_64-linux-gnu/security/pam_keyinit.so && echo module-present
module-present

Its normal name in a PAM rule is just pam_keyinit.so: PAM finds it in the default module directory, so do not paste the absolute path from this check into a configuration file unless your system's module layout is genuinely unusual.

If your package version differs from this guide's, read the local manual page before changing anything. The interface that matters is a session rule with the optional arguments debug, force and revoke.

2. Choose the PAM service

Pick the service that represents the login path you actually want isolated, such as login or a display manager's own service. List the available files without touching them:

$ ls /etc/pam.d/

Changing login will not automatically affect every graphical, SSH or application login: PAM reads only the file the calling service names, and included files can pull in more rules from elsewhere. Check the chosen file and whatever it includes:

$ sudo grep -nE '^[[:space:]]*(include|substack|session)' /etc/pam.d/login

Swap in the service you actually use. This needs elevated privileges only because your account cannot otherwise read the file. A shared session include showing up here means checking that include before deciding where the new rule belongs.

3. Back up the configuration before editing

Editing PAM can break authentication or session setup outright. Keep a root shell, console access or an out-of-band recovery channel open while you test, and do not start this during a maintenance window you cannot extend.

As root, make a dated backup of the exact service file:

$ sudo cp -p /etc/pam.d/login /etc/pam.d/login.before-pam-keyinit
$ sudo ls -l /etc/pam.d/login /etc/pam.d/login.before-pam-keyinit

Keep that backup until a fresh login and the keyring check have both succeeded. The name here is only an example: pick something that could never be mistaken for an active PAM service file.

4. Add the session rule early in the stack

Edit the selected service file as root and add this line near the beginning of its session rules:

session required pam_keyinit.so

The three fields say: this is a session rule, the module must succeed for the stack to succeed, and PAM should load pam_keyinit.so from its standard directory. Put it ahead of any session module that needs to attach tokens to the session keyring; the manual specifically recommends putting it as early as possible.

Do not add this rule to an su service just to make sessions look consistent: the manual warns that su commonly needs the existing key set to carry over into the new context.

5. Check the edit before starting a new session

Review the rule and its surrounding stack, using sudo if you need to:

$ sudo grep -n -A3 -B3 'pam_keyinit' /etc/pam.d/login
42:session required pam_keyinit.so

The line number will vary. Confirm the module name is spelled exactly, the type reads session, and there is no stray extra option. A syntactically correct line is not proof the application actually calls it, since the service might load a different file or included stack entirely.

To undo an incorrect edit before testing a new login, restore the backup:

$ sudo cp -p /etc/pam.d/login.before-pam-keyinit /etc/pam.d/login

Use the same service name you backed up, and never replace a whole PAM file with a guessed minimal version.

6. Open a fresh login and inspect the result

Keep the current session open and start a separate login through the changed service. A session that was already running before the edit tells you nothing about whether its PAM session stack ran the new rule.

pam_keyinit succeeds silently by design. For direct inspection, the optional keyctl program from the keyutils package can show the calling process's session keyring:

$ command -v keyctl
/usr/bin/keyctl
$ keyctl show

Exact key IDs and descriptions are host-specific, and a system without keyutils installed will print nothing from command -v. That absence is not evidence PAM failed. The manual describes the resulting keyring as inherited by child processes and linked to the user's keyring; it makes no promise about a fixed numeric ID or display format.

If the new login fails, stop opening more sessions and use the recovery path you kept open. Restore the backup, retry the affected service, and check the system log for the PAM error while confirming the module file still exists. Loosening a control flag to silence that error would hide it, not fix it, and leaves the isolation you wanted still absent.