View previous topic :: View next topic |
Author |
Message |
nagmat84 Apprentice
Joined: 27 Mar 2007 Posts: 296
|
Posted: Tue May 14, 2024 5:51 pm Post subject: [SOLVED]Which PAM file should invoke pam_u2f for FIDO2 auth? |
|
|
I want to enable FIDO2 authentication with a Yubikey for my PC. I found the following two guides:- Gentoo Wiki: PAM/U2F, Sec. 2.3 "Configuring PAM"
- Gentoo Wiki: YubiKey/PAM, Sec. 3.3. "PAM U2F"
Both guides add pam_u2f to different PAM services:- Guide #1 adds pam_u2f to system-local-login
- Guide #2 adds u2f to system-auth
- After some thought (explanation below), I consider system-login to be a third option
My PCs run Plasma/KDE 5 as the desktop environment with SDDM as the display manager and graphical login. I want to use the Yubikey when I login locally, either via SDDM or CLI. When I login remotely (via SSH), FIDO2 authentication is not strictly necessary as I am fine with public/private key authentication over SSH. However, using FIDO2 authentication for SSH would be a plus for those cases when I try to login from an (foreign) SSH client without my public/private key.
Question 1: What is the "best" PAM service to add pam_u2f to? To clarify the issue for myself, I drew the following dependency diagram: Code: | sshd --> system-remote-login --+
|
kde --+ |
login --+--> system-local-login --+--> system-login -------+
rununser-l --+ | |
| |
sddm -------------------------------+ |
|
su-l --------------------> su --------------+--> system-auth
|
chfn --------------+
... |
<everything else> --+
... |
vlock --+ |
- Following option 2, i.e. adding pam_u2f to system-auth, essentially enables FIDO2 authentication for everything. I wonder if this isn't to much. In particular, if pam_u2f was made "required", I wonder if some service would break or become inaccessible (e.g. cvs, saslauthd, cups, etc. caught my attention).
- Intuitively, I would follow option 1, i.e. adding pam_u2f to system-local-login, because this seems to make sense.
- However, I figured out that sddm does not include system-local-login, but system-login. (Honestly I don't know why.) Hence, I conjecture that SDDM would not use FIDO2 authentication, if I added pam_u2f to system-local-login. That is why I came up with the third option to add pam_u2f to system-login. However, sshd also pulls in system-login (via system-remote-login) and I don't know how this would affect sshd.
Question 2: How do I keep password authentication (via pam_unix.so from system-auth) enabled as a fall-back mechanism and make pam_u2f only sufficient without giving up evaluation of the other PAM modules from system-auth?
As a safety measure (until my backup Yubikey arrives), I want to keep password authentication as a fall-back mechanism. However, if I do not set pam_u2f as "required" but as "sufficient" only, then the subsequent PAM modules are not evaluated if pam_u2f succeeds. At the moment, I am considering to add pam_u2f to system-login, but it seems that neither control keyword suits my needs. This is how my solution would like like: Code: | # system-local-login
auth include system-login |
Code: | # system-remote-login
auth include system-login |
Code: | # system-login
auth required pam_shells.so
auth required pam_nologin.so
auth <????> pam_u2f.so nouserok cue <--- newly added line
auth include system-auth |
Code: | #system-auth
auth required pam_env.so
auth requisite pam_faillock.so preauth
auth [success=1 new_authtok_reqd=1 ignore=ignore default=bad] pam_unix.so nullok try_first_pass
auth [default=die] pam_faillock.so authfail
auth optional pam_cap.so |
- If I chose control "required" for pam_u2f, then U2F must succeed. This seems to be to strict for my goal.
- If I chose control "sufficient" for pam_u2f and if FIDO2 authentication succeeds, then system-auth is not evaluated anymore. But I still want pam_faillock and pam_env from system-auth to run.
Last edited by nagmat84 on Sat May 18, 2024 9:51 am; edited 1 time in total |
|
Back to top |
|
|
nagmat84 Apprentice
Joined: 27 Mar 2007 Posts: 296
|
Posted: Sat May 18, 2024 9:51 am Post subject: |
|
|
After giving it some thought I decided for a solution that only modifies /etc/pam.d/system-auth like this Code: | auth required pam_env.so
auth requisite pam_faillock.so preauth
auth [success=2 new_authtok_reqd=2 default=ignore] pam_u2f.so cue <--- newly added line
auth [success=1 new_authtok_reqd=1 ignore=ignore default=bad] pam_unix.so nullok try_first_pass
auth [default=die] pam_faillock.so authfail
auth optional pam_cap.so |
Rationale: I wanted something between control sufficient and required. In terms of the extended control syntax, the control keyword sufficient is equivalent to Code: | [success=done new_authtok_reqd=done default=ignore] | and required is equivalent to Code: | [success=ok new_authtok_reqd=ok ignore=ignore default=bad] |
The newly added line behaves as follows:- If pam_u2f succeeds, PAM skips the next 2 lines, therewith by-passes the traditional password-based login, but still executes pam_cap. Using "success=done" here as it would have been the case for a sufficient module would be too excessive, because it would return prematurely and also skip pam_cap.
- If pam_u2f fails, then the result is ignored and pam_unix is executed next for traditional password-based login. That is the same behavior as for any sufficient module. Using "default=bad" as it would have been the case for a required module would be too excessive, because it would not allow to fall back to password-based login.
There are still some usability problems with SDDM and the KDE screen locker, but that's a different topic. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|