Another MFA PAM Configuration Ignored or Incorrectly Loaded

[Antigravityd]

Hi, I believe I'm having a similar issue to this person, who unfortunately disappeared with any secret knowledge of its fix. In some ways, I think my configuration may be simpler, and the problem more severe (namely: fail-deadly behavior rather than fail-safe).

I've set up pam_usb, a one-time-pad-based hardware authentication solution, on an Arch box I'm configuring. The desired behavior:

• no user logins without USB OTP authorization
• when the USB is removed, have your wonderful project simulate "logging back out" from an attacker's perspective but without loss of the X session.

The first part was easy. Placing the PAM config below in /etc/pam.d/system-auth prevents login on TTYs and even sudoing in open sessions:

#%PAM-1.0

auth       required                    pam_faillock.so      preauth
# Optionally use requisite above if you do not want to prompt for the password
# on locked accounts.
-auth      [success=2 default=ignore]  pam_systemd_home.so
auth       required                pam_usb.so
auth       [success=1 default=bad]     pam_unix.so          try_first_pass nullok
auth       [default=die]               pam_faillock.so      authfail
auth       optional                    pam_permit.so
auth       required                    pam_env.so
auth       required                    pam_faillock.so      authsucc
# If you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures.

-account   [success=1 default=ignore]  pam_systemd_home.so
account    required                    pam_unix.so
account    optional                    pam_permit.so
account    required                    pam_time.so

-password  [success=1 default=ignore]  pam_systemd_home.so
password   required                    pam_unix.so          try_first_pass nullok shadow sha512
password   optional                    pam_permit.so

-session   optional                    pam_systemd_home.so
session    required                    pam_limits.so
session    required                    pam_unix.so
session    optional                    pam_permit.so

The change from Arch's default is merely to add the fourth significant line, so that success of the pam_usb module is required (prior/in addition to the usual pam_unix password module).

I tried to set up their pamusb-agent systemd daemon to call xsecurelock on USB disconnect as follows:

...
<agent event="lock">
  <env>XSECURELOCK_AUTHPROTO=authproto_pam</env>
  <env>XSECURELOCK_PAM_SERVICE=system-auth</env>
  <env>XSECURE_LOCK_PASSWORD_PROMPT=time-hex</env>
  <env>DISPLAY=:0.0</env>
  <env>XAUTHORITY=/home/me/.Xauthority</env>
  <cmd>xsecurelock</cmd>
</agent>
...

Now, I know I've not completely misinterpreted how this config file works, as I was able to fix $XAUTHORITY issues: the env tags do indeed set environment variables, and the cmd tags run commands in that environment. This works to lock the session. But, if I remove the USB, I can simply...log in again, password-only. The behavior I'd expect is an authentication failure, just as on the TTYs.

Security and systems programming aren't quite my forté (read a grand total of 2 man pages about PAM, and nothing else), so I might not be too useful, but I'll do my best to help in seeing this fixed.

Thank y'all!

EDIT: I should note that I get varying behavior depending on whether I run the pamusb-agent as a systemd service (using the service file they provide), or as root with --daemon: in the former case, it's fail-safe, i.e. doesn't unlock at all and I have to killall xsecurelock from a TTY; in the latter, I get the behavior described above. In both cases, all other authentication happens as-expected. I also tested with pamusb-agent's quiet option on, in case it was to do with the output it puts near the login prompt---no dice.