yubico-pam
yubico-pam copied to clipboard
Breaks in macOS 10.15
Hi,
I have just upgraded to macOS 10.15 and it seems yubico-pam no longer works for /etc/pam.d/authorization
and /etc/pam.d/screensaver
.
/etc/pam.d/authorization
After the upgrade, I re-configured /etc/pam.d/authorization
to:
# authorization: auth account
auth optional pam_krb5.so use_first_pass use_kcminit
auth optional pam_ntlm.so use_first_pass
auth required pam_opendirectory.so use_first_pass nullok
auth required /usr/local/lib/security/pam_yubico.so mode=challenge-response
account required pam_opendirectory.so
This caused me not able to log in or authenticate in e.g. System Preferences -> Security & Privacy. (had to enter recovery mode to unlock, oops!)
/etc/pam.d/screensaver
My /etc/pam.d/screensaver
is configured as:
# screensaver: auth account
auth optional pam_krb5.so use_first_pass use_kcminit
auth required pam_opendirectory.so use_first_pass nullok
auth required /usr/local/lib/security/pam_yubico.so mode=challenge-response
account required pam_opendirectory.so
account sufficient pam_self.so
account required pam_group.so no_warn group=admin,wheel fail_safe
account required pam_group.so no_warn deny group=admin,wheel ruser fail_safe
It works ok if you don't have a YubiKey plugged in (blocks login successfully) or normally touch YubiKey when prompted. BUT, it crashes and forcibly logs out the user if you unplug YubiKey when the LED is blinking.
And since I cannot use yubico-pam in /etc/pam.d/authorization
now, it means the challenge-response can be effectively bypassed since if my password is leaked, one can simply plug in a wrong key to log me out, then use my password to normally log in.
Logs
# pam_yubico-authorization.log
debug: pam_yubico.c:838 (parse_cfg): called.
debug: pam_yubico.c:839 (parse_cfg): flags 0 argc 3
debug: pam_yubico.c:841 (parse_cfg): argv[0]=mode=challenge-response
debug: pam_yubico.c:841 (parse_cfg): argv[1]=debug
debug: pam_yubico.c:841 (parse_cfg): argv[2]=debug_file=/var/log/pam_yubico.log
debug: pam_yubico.c:842 (parse_cfg): id=0
debug: pam_yubico.c:843 (parse_cfg): key=(null)
debug: pam_yubico.c:844 (parse_cfg): debug=1
debug: pam_yubico.c:845 (parse_cfg): debug_file=3
debug: pam_yubico.c:846 (parse_cfg): alwaysok=0
debug: pam_yubico.c:847 (parse_cfg): verbose_otp=0
debug: pam_yubico.c:848 (parse_cfg): try_first_pass=0
debug: pam_yubico.c:849 (parse_cfg): use_first_pass=0
debug: pam_yubico.c:850 (parse_cfg): nullok=0
debug: pam_yubico.c:851 (parse_cfg): authfile=(null)
debug: pam_yubico.c:852 (parse_cfg): ldapserver=(null)
debug: pam_yubico.c:853 (parse_cfg): ldap_uri=(null)
debug: pam_yubico.c:854 (parse_cfg): ldap_bind_user=(null)
debug: pam_yubico.c:855 (parse_cfg): ldap_bind_password=(null)
debug: pam_yubico.c:856 (parse_cfg): ldap_filter=(null)
debug: pam_yubico.c:857 (parse_cfg): ldap_cacertfile=(null)
debug: pam_yubico.c:858 (parse_cfg): ldapdn=(null)
debug: pam_yubico.c:859 (parse_cfg): user_attr=(null)
debug: pam_yubico.c:860 (parse_cfg): yubi_attr=(null)
debug: pam_yubico.c:861 (parse_cfg): yubi_attr_prefix=(null)
debug: pam_yubico.c:862 (parse_cfg): url=(null)
debug: pam_yubico.c:863 (parse_cfg): urllist=(null)
debug: pam_yubico.c:864 (parse_cfg): capath=(null)
debug: pam_yubico.c:865 (parse_cfg): cainfo=(null)
debug: pam_yubico.c:866 (parse_cfg): proxy=(null)
debug: pam_yubico.c:867 (parse_cfg): token_id_length=12
debug: pam_yubico.c:868 (parse_cfg): mode=chresp
debug: pam_yubico.c:869 (parse_cfg): chalresp_path=(null)
debug: pam_yubico.c:899 (pam_sm_authenticate): pam_yubico version: 2.26
debug: pam_yubico.c:914 (pam_sm_authenticate): get user returned: frederick
debug: pam_yubico.c:490 (do_challenge_response): Checking for user challenge files
debug: pam_yubico.c:493 (do_challenge_response): Challenge files found
debug: pam_yubico.c:514 (do_challenge_response): Failed initializing YubiKey
debug: pam_yubico.c:706 (do_challenge_response): USB error: unknown error
debug: pam_yubico.c:718 (do_challenge_response): Challenge response failed: No such file or directory
debug: pam_yubico.c:1220 (pam_sm_authenticate): done. [authentication error]
# pam_yubico-screensaver.log
debug: pam_yubico.c:838 (parse_cfg): called.
debug: pam_yubico.c:839 (parse_cfg): flags 0 argc 3
debug: pam_yubico.c:841 (parse_cfg): argv[0]=mode=challenge-response
debug: pam_yubico.c:841 (parse_cfg): argv[1]=debug
debug: pam_yubico.c:841 (parse_cfg): argv[2]=debug_file=/var/log/pam_yubico.log
debug: pam_yubico.c:842 (parse_cfg): id=0
debug: pam_yubico.c:843 (parse_cfg): key=(null)
debug: pam_yubico.c:844 (parse_cfg): debug=1
debug: pam_yubico.c:845 (parse_cfg): debug_file=14
debug: pam_yubico.c:846 (parse_cfg): alwaysok=0
debug: pam_yubico.c:847 (parse_cfg): verbose_otp=0
debug: pam_yubico.c:848 (parse_cfg): try_first_pass=0
debug: pam_yubico.c:849 (parse_cfg): use_first_pass=0
debug: pam_yubico.c:850 (parse_cfg): nullok=0
debug: pam_yubico.c:851 (parse_cfg): authfile=(null)
debug: pam_yubico.c:852 (parse_cfg): ldapserver=(null)
debug: pam_yubico.c:853 (parse_cfg): ldap_uri=(null)
debug: pam_yubico.c:854 (parse_cfg): ldap_bind_user=(null)
debug: pam_yubico.c:855 (parse_cfg): ldap_bind_password=(null)
debug: pam_yubico.c:856 (parse_cfg): ldap_filter=(null)
debug: pam_yubico.c:857 (parse_cfg): ldap_cacertfile=(null)
debug: pam_yubico.c:858 (parse_cfg): ldapdn=(null)
debug: pam_yubico.c:859 (parse_cfg): user_attr=(null)
debug: pam_yubico.c:860 (parse_cfg): yubi_attr=(null)
debug: pam_yubico.c:861 (parse_cfg): yubi_attr_prefix=(null)
debug: pam_yubico.c:862 (parse_cfg): url=(null)
debug: pam_yubico.c:863 (parse_cfg): urllist=(null)
debug: pam_yubico.c:864 (parse_cfg): capath=(null)
debug: pam_yubico.c:865 (parse_cfg): cainfo=(null)
debug: pam_yubico.c:866 (parse_cfg): proxy=(null)
debug: pam_yubico.c:867 (parse_cfg): token_id_length=12
debug: pam_yubico.c:868 (parse_cfg): mode=chresp
debug: pam_yubico.c:869 (parse_cfg): chalresp_path=(null)
debug: pam_yubico.c:899 (pam_sm_authenticate): pam_yubico version: 2.26
debug: pam_yubico.c:914 (pam_sm_authenticate): get user returned: frederick
debug: pam_yubico.c:490 (do_challenge_response): Checking for user challenge files
debug: pam_yubico.c:493 (do_challenge_response): Challenge files found
debug: util.c:222 (check_firmware_version): YubiKey Firmware version: 5.1.2
debug: pam_yubico.c:528 (do_challenge_response): Loading challenge from file /Users/frederick/.yubico/challenge-xxx
debug: drop_privs.c:58 (pam_modutil_drop_priv): Privilges already dropped, pretend it is all right
debug: util.c:437 (load_chalresp_state): Challenge: xxx, hashed response: xxx, salt: xxx, iterations: 10000, slot: 2
debug: drop_privs.c:102 (pam_modutil_regain_priv): Privilges already as requested, pretend it is all right
debug: pam_yubico.c:582 (do_challenge_response): Challenge-response FAILED
debug: pam_yubico.c:706 (do_challenge_response): USB error: unknown error
debug: pam_yubico.c:718 (do_challenge_response): Challenge response failed: Operation timed out
debug: pam_yubico.c:1220 (pam_sm_authenticate): done. [authentication error]
Just compiled master branch locally and it was the same symptom.
+1 I can confirm the same USB error for /etc/pam.d/authorization on catalina. ssh pgp key management, and pam sudo appear to work ok. The same configurations work working fine on mohave.
The screensaver integration will also log you out if you type the wrong user password and touch the yubikey (the expected behavior is for osx to offer another password attempt, not log you out).
Here is the log file from a screensaver session with the wrong user password which causes a logout:
debug: pam_yubico.c:838 (parse_cfg): called. debug: pam_yubico.c:839 (parse_cfg): flags 0 argc 3 debug: pam_yubico.c:841 (parse_cfg): argv[0]=mode=challenge-response debug: pam_yubico.c:841 (parse_cfg): argv[1]=debug debug: pam_yubico.c:841 (parse_cfg): argv[2]=debug_file=/var/log/pam_yubico.log debug: pam_yubico.c:842 (parse_cfg): id=0 debug: pam_yubico.c:843 (parse_cfg): key=(null) debug: pam_yubico.c:844 (parse_cfg): debug=1 debug: pam_yubico.c:845 (parse_cfg): debug_file=14 debug: pam_yubico.c:846 (parse_cfg): alwaysok=0 debug: pam_yubico.c:847 (parse_cfg): verbose_otp=0 debug: pam_yubico.c:848 (parse_cfg): try_first_pass=0 debug: pam_yubico.c:849 (parse_cfg): use_first_pass=0 debug: pam_yubico.c:850 (parse_cfg): nullok=0 debug: pam_yubico.c:851 (parse_cfg): authfile=(null) debug: pam_yubico.c:852 (parse_cfg): ldapserver=(null) debug: pam_yubico.c:853 (parse_cfg): ldap_uri=(null) debug: pam_yubico.c:854 (parse_cfg): ldap_bind_user=(null) debug: pam_yubico.c:855 (parse_cfg): ldap_bind_password=(null) debug: pam_yubico.c:856 (parse_cfg): ldap_filter=(null) debug: pam_yubico.c:857 (parse_cfg): ldap_cacertfile=(null) debug: pam_yubico.c:858 (parse_cfg): ldapdn=(null) debug: pam_yubico.c:859 (parse_cfg): user_attr=(null) debug: pam_yubico.c:860 (parse_cfg): yubi_attr=(null) debug: pam_yubico.c:861 (parse_cfg): yubi_attr_prefix=(null) debug: pam_yubico.c:862 (parse_cfg): url=(null) debug: pam_yubico.c:863 (parse_cfg): urllist=(null) debug: pam_yubico.c:864 (parse_cfg): capath=(null) debug: pam_yubico.c:865 (parse_cfg): cainfo=(null) debug: pam_yubico.c:866 (parse_cfg): proxy=(null) debug: pam_yubico.c:867 (parse_cfg): token_id_length=12 debug: pam_yubico.c:868 (parse_cfg): mode=chresp debug: pam_yubico.c:869 (parse_cfg): chalresp_path=(null) debug: pam_yubico.c:899 (pam_sm_authenticate): pam_yubico version: 2.26 debug: pam_yubico.c:914 (pam_sm_authenticate): get user returned: face debug: pam_yubico.c:490 (do_challenge_response): Checking for user challenge files debug: pam_yubico.c:493 (do_challenge_response): Challenge files found debug: util.c:222 (check_firmware_version): YubiKey Firmware version: 5.1.2
debug: pam_yubico.c:528 (do_challenge_response): Loading challenge from file /Users/face/.yubico/challenge-xxxx debug: drop_privs.c:58 (pam_modutil_drop_priv): Privilges already dropped, pretend it is all right debug: util.c:437 (load_chalresp_state): Challenge: xxxx, hashed response: xxx, salt: xxx, iterations: xxx, slot: 2 debug: drop_privs.c:102 (pam_modutil_regain_priv): Privilges already as requested, pretend it is all right debug: pam_yubico.c:604 (do_challenge_response): Got the expected response, generating new challenge (63 bytes). debug: drop_privs.c:58 (pam_modutil_drop_priv): Privilges already dropped, pretend it is all right debug: pam_yubico.c:690 (do_challenge_response): Challenge-response success! debug: drop_privs.c:102 (pam_modutil_regain_priv): Privilges already as requested, pretend it is all right debug: pam_yubico.c:1220 (pam_sm_authenticate): done. [success]
Can confirm the same problem here.
I found this closed issue which describes the same problem happening during the public betas, and then being subsequently fixed 🤔
https://github.com/Yubico/yubico-pam/issues/197
@tob1k I don't think that's the same issue tho? I'm not familiar with the macOS entitlements stuff but I can use challenge-response for sudo right now.
@Frederick888 Yeah I'm not 100% sure either. But the log output seemed the same, and if you check the entitlements for sudo, it's missing the usb entitlements as described in #197
$ sudo codesign -d --entitlements :- /usr/bin/sudo
Executable=/usr/bin/sudo
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.private.AuthorizationServices</key>
<array>
<string>com.apple.security.sudo</string>
</array>
</dict>
</plist>
@tob1k I think you might be on the right track. I just checked my Console -> Errors and saw a 0x100001988: TCC deny IOHIDDeviceOpen
error as mentioned in #197.
May I know whether it's possible to overwrite the entitlements (or disable runtime entitlement check system-wide)?
May I know whether it's possible to overwrite the entitlements (or disable runtime entitlement check system-wide)?
@Frederick888 I'm not sure. I looked into the same thing but at the very least it looks like you would need an Apple Developer ID (which I don't have)
@tob1k Well, I remembered that I once code signed lldb/gdb to work around the entitlements as described in https://opensource.apple.com/source/lldb/lldb-69/docs/code-signing.txt but apparently a random self-signed root certificate will just break sudo
as it's a system executable...
I've filed an issue regarding the entitlements of /System/Library/Frameworks/Security.framework/Versions/A/MachServices/authorizationhost.bundle/Contents/MacOS/authorizationhost
to Apple but haven't got any response so far.
But, I mean, where are the Yubico devs? Is this project still maintained?
But, I mean, where are the Yubico devs? Is this project still maintained?
We're aware of the issue, unfortunately not with alot of insight to add at this point.
authorizationhost has changed entitlements for 10.15, if that's the culprit or not is a good question. This might even be an intentional change from Apple, that the login process should not be able to talk with a USB device.
@klali I really believe you guys need to talk to Apple about this. I don't think such kind of technical feedback from individual customers who are not familiar with either macOS entitlements or yubico-pam per se like me would attract much attention from them.
Still no response from Apple. Can anyone check
- the entitlements of
authorizationhost
in 10.14 - whether this is fixed in 10.15.1?
Thanks.
I can confirm that this issue can still be reproduced in 10.15.1. And the bloody update reset a bunch of /etc
files again including /etc/pam.d
... do they plan to inflict this atrocity on me every time it updates in the future? Geez, I mean, geez... I gotta make some time to figure out the EFI chainloading asap so that I can ditch the rubbish system.
upvoting this. Worked on El Capitan for both authorization and screensaver PAM. Now only screensaver works on Catalina, but Apple seems to have disabled Yubkey working in 'authorization'.. Any ideas if this is entirely Apple's doing or can Yubi fix this?
Also… the newly released MacBookPro 16" only runs Catalina…
@MartinMKD I'm not 100% sure if Yubico can fix it. But the extra piece of information I'll throw out there is that this does not only affect pam_yubico. I know some others who were using some form of pam kerberos, and it was broken by Catalina too, so this does not bode well. That being said, it may always be possible to have it fixed on the Yubico side, I just don't know enough about the problem to say for sure.
In their zeal to remain "inventive"/ahead of the curve, Apple manages to break things that work such as Yubikey/PAM auth.. along with other useless innovations, like the function key touchbar ....
Any updates on a potential fix for this issue? It's been a while since Catalina was released. Currently our company is not security compliant since we require Yubikey 2FA at logon. Why isn't Yubico providing us updates/information on this issue? This is an important feature, one of the reasons we chose for the Yubikey...
This is still broken in osx 10.15.2. Is Yubico working with Apple to fix this?
debug: pam_yubico.c:514 (do_challenge_response): Failed initializing YubiKey
debug: pam_yubico.c:706 (do_challenge_response): USB error: unknown error
Same issue here.
Mostly as an update. Yubico has no more information about this, we've opened a radar with apple and tried to get clarity with no answers so far.
After updating to from 10.15.1 to 10.15.2, logging in with the yubikey worked without issue (It's been working for login only in Catalina this whole time, just not screensaver or privilege elevation). But after a second reboot, it stopped working.
- Insert Yubikey
- Log in with correct password
- It does not wait for you to press the yubikey, but it did blink, and the screen turns white for a few seconds
- The login screen restarts, including the MOTD prompt showing up again.
So Apple has at least made it 100% broken instead of 80% broken.
@Frederick888 in regards to you comment about the pam.d files being reset, I always assume that anything I customize on a mac will be reset. I treat OS updates a "firmware" updates. For this reason, I configure a LaunchDaemon that will reprogram anything I ever edit on a mac. In this case I run a carefully crafted awk and sed script that will update pam.d files every time the computer is rebooted, fairly robustly. This has kept my yubikey setting since I started using it a year and a half ago.
Could anyone post instructions on how to remedy this from recovery mode? I’m struggling with Terminal and am locked out. Thank you for any help!
Could anyone post instructions on how to remedy this from recovery mode? I’m struggling with Terminal and am locked out. Thank you for any help!
https://vcsjones.dev/2016/01/21/regaining-access-to-os-x-after-a-lost-yubikey/
- if you have an apfs file system, replace coreStorage with apfs
- mount the volume with the id from the list of disk
- use your pw to decrypt the drive
- edit the /Volumes/YOUR-VOLUME-ID/etc/pam.d/authorization file and remove the yubikey line. if you edit the /etc/pam.d/authorization, that is the incorrect file.
Thanks for the reply @chulander. I forgot to update this thread when my computer was stolen shortly after I posted. Unfortunately, it's moot now.
Yubikeys are now a requirement at our lab, and new Macs come with Catalina. So this issue is affecting our ability to purchase Apple hardware. Can you please point me to the Radar issue, so I can try to escalate this issue with Apple directly?
@GregoryEAllen I got logins to work on Catalina by configuring Yubi to work as a smartcard. It's a bit more involved to set up but at least it works until Apple issues a fix for killing Yubikey PAM based logins.
@MartinMKD could you please provide a link to instructions for this workaround? Does it also support screensaver authorization?
Do we know whether this is Apple's bug, or in yubico-pam?