Give Each PAM Login Its Own Kernel Session Keyring

You will add pam_keyinit to a PAM session stack so each login starts with a session keyring separate from the user's default session keyring. This keeps keys created during one login from being automatically available through another login by the same user. Allow about 15 minutes, plus time to arrange a recovery path if you are editing the PAM configuration of a remote machine.

This guide covers Linux-PAM 1.5.3-5ubuntu5.7 from the installed libpam-modules:amd64 package. The module is intended for login processes. It is not a general-purpose key management command, and it does not create or inspect arbitrary keys by itself.

1. Check the installed module

Run the checks as your ordinary user first. They do not change configuration:

$ 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

The module's normal relative name in a PAM rule is pam_keyinit.so. PAM searches its default module directory for that name, so do not paste the absolute path from the check into a configuration unless your system has an unusual module layout.

Read the local manual page before changing anything if your package version differs. The relevant interface 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 want to isolate, such as login or a display manager's service. List the available service files without changing them:

$ ls /etc/pam.d/

Do not assume that changing login affects every graphical, SSH or application login. PAM reads the file named by the calling service, and included files can add more rules. Inspect the chosen file and the files it includes:

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

Replace login with the service you actually use. This command needs elevated privileges only to read files that your account cannot read. If it reveals a shared session include, check that include before deciding where the new rule belongs.

3. Back up the configuration before editing

Editing PAM can prevent authentication or session setup. Keep an existing root shell, console access or out-of-band recovery channel open while testing. Do not make this change during a maintenance window you cannot extend.

As root, make a dated backup of the exact service file. This changes the filesystem, so it requires elevated privileges:

$ 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 the backup until a fresh login and the keyring check have succeeded. The backup name is only an example; use a name that cannot 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 mean that this is a session rule, the module must succeed for the stack to succeed, and PAM should load pam_keyinit.so from its standard module directory. Put it before session modules that need to attach tokens to the session keyring. The manual specifically recommends including it as early as possible.

Do not add force casually. Without it, the module replaces the process session keyring when it is still the user's default session keyring. With force, it replaces the session keyring unconditionally, which can discard access to keys already present in the old keyring. The revoke option revokes a keyring created for this process when the process exits. Use either option only after checking the effect on the software using your keyrings.

Do not add this rule to an su service merely to make sessions look consistent. The manual warns that su commonly needs the existing key set to percolate into the alternate context.

5. Check the edit before starting a new session

Review the rule and its surrounding stack as your ordinary user, or use sudo if necessary:

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

The line number will vary. Confirm that the module name is spelled exactly, the type is session, and the file has no accidental extra option. A syntax-looking line is not proof that the application will call it, because the service might use another file or an included stack.

Undo an incorrect edit before testing a new login by restoring the backup:

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

Use the same service name you backed up. Do not remove a whole PAM file or replace it with a guessed minimal example.

6. Open a fresh login and inspect the result

Keep the current session open and start a separate login through the service you changed. A session that was already open does not retroactively prove that its PAM session stack ran the new rule.

The installed pam_keyinit module normally returns success without visible output. 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

The exact key IDs and descriptions are host-specific, and an installation without keyutils will print no path from command -v. Do not treat an absent inspection tool as evidence that PAM failed. The manual describes the resulting keyring as inherited by child processes and linked to the user's keyring; it does not promise a fixed numeric ID or display format.

If the new login fails, stop opening new sessions and use the still-open recovery path. Restore the backup, then retry the affected service. Check the system log for the PAM error and confirm that the module file still exists. A module load or system error can produce a PAM session error; changing the control flag to hide that error can leave the intended isolation absent.