yubico-pam icon indicating copy to clipboard operation
yubico-pam copied to clipboard

Breaks in macOS 10.15

Open Frederick888 opened this issue 5 years ago • 84 comments

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.

Frederick888 avatar Oct 09 '19 08:10 Frederick888

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]

Frederick888 avatar Oct 09 '19 08:10 Frederick888

Just compiled master branch locally and it was the same symptom.

Frederick888 avatar Oct 12 '19 07:10 Frederick888

+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]

face avatar Oct 12 '19 12:10 face

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 avatar Oct 15 '19 00:10 tob1k

@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 avatar Oct 16 '19 01:10 Frederick888

@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 avatar Oct 16 '19 02:10 tob1k

@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)?

Frederick888 avatar Oct 16 '19 03:10 Frederick888

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 avatar Oct 16 '19 03:10 tob1k

@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...

Frederick888 avatar Oct 16 '19 03:10 Frederick888

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?

Frederick888 avatar Oct 18 '19 07:10 Frederick888

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 avatar Oct 18 '19 08:10 klali

@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.

Frederick888 avatar Oct 18 '19 08:10 Frederick888

Still no response from Apple. Can anyone check

  1. the entitlements of authorizationhost in 10.14
  2. whether this is fixed in 10.15.1?

Thanks.

Frederick888 avatar Oct 29 '19 05:10 Frederick888

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.

Frederick888 avatar Nov 01 '19 08:11 Frederick888

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?

MartinMKD avatar Nov 10 '19 07:11 MartinMKD

Also… the newly released MacBookPro 16" only runs Catalina…

budachst avatar Nov 21 '19 18:11 budachst

@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.

andyneff avatar Nov 21 '19 19:11 andyneff

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 ....

MartinMKD avatar Nov 21 '19 20:11 MartinMKD

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...

phroze avatar Dec 03 '19 10:12 phroze

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

face avatar Dec 14 '19 23:12 face

Same issue here.

chuegel avatar Dec 15 '19 12:12 chuegel

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.

klali avatar Dec 16 '19 08:12 klali

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.

  1. Insert Yubikey
  2. Log in with correct password
  3. It does not wait for you to press the yubikey, but it did blink, and the screen turns white for a few seconds
  4. The login screen restarts, including the MOTD prompt showing up again.

So Apple has at least made it 100% broken instead of 80% broken.

andyneff avatar Dec 17 '19 21:12 andyneff

@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.

andyneff avatar Dec 17 '19 22:12 andyneff

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!

leggomyinfo avatar Dec 28 '19 02:12 leggomyinfo

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/

  1. if you have an apfs file system, replace coreStorage with apfs
  2. mount the volume with the id from the list of disk
  3. use your pw to decrypt the drive
  4. 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.

chulander avatar Jan 10 '20 05:01 chulander

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.

leggomyinfo avatar Jan 11 '20 00:01 leggomyinfo

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 avatar Jan 21 '20 21:01 GregoryEAllen

@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 avatar Jan 21 '20 21:01 MartinMKD

@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?

GregoryEAllen avatar Jan 21 '20 21:01 GregoryEAllen