You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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:
The first part was easy. Placing the PAM config below in
/etc/pam.d/system-auth
prevents login on TTYs and evensudo
ing in open sessions: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 usualpam_unix
password module).I tried to set up their
pamusb-agent
systemd daemon to callxsecurelock
on USB disconnect as follows:Now, I know I've not completely misinterpreted how this config file works, as I was able to fix
$XAUTHORITY
issues: theenv
tags do indeed set environment variables, and thecmd
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 tokillall 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 withpamusb-agent
'squiet
option on, in case it was to do with the output it puts near the login prompt---no dice.The text was updated successfully, but these errors were encountered: