Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breaks in macOS 10.15 #201

Open
Frederick888 opened this issue Oct 9, 2019 · 84 comments
Open

Breaks in macOS 10.15 #201

Frederick888 opened this issue Oct 9, 2019 · 84 comments

Comments

@Frederick888
Copy link

Frederick888 commented Oct 9, 2019

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
Copy link
Author

Frederick888 commented Oct 9, 2019

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
Copy link
Author

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

@face
Copy link

face commented Oct 12, 2019

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

@tob1k
Copy link

tob1k commented Oct 15, 2019

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 🤔

#197

@Frederick888
Copy link
Author

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

@tob1k
Copy link

tob1k commented Oct 16, 2019

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

@Frederick888
Copy link
Author

Frederick888 commented Oct 16, 2019

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

@tob1k
Copy link

tob1k commented Oct 16, 2019

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)

@Frederick888
Copy link
Author

@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
Copy link
Author

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?

@klali
Copy link
Member

klali commented Oct 18, 2019

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.

@Frederick888
Copy link
Author

@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
Copy link
Author

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
Copy link
Author

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.

@MartinMKD
Copy link

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?

@budachst
Copy link

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

@andyneff
Copy link
Contributor

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

@MartinMKD
Copy link

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

@phroze
Copy link

phroze commented Dec 3, 2019

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

@face
Copy link

face commented Dec 14, 2019

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

@chuegel
Copy link

chuegel commented Dec 15, 2019

Same issue here.

@klali
Copy link
Member

klali commented Dec 16, 2019

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.

@andyneff
Copy link
Contributor

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
Copy link
Contributor

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

@leggomyinfo
Copy link

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!

@chulander
Copy link

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.

@leggomyinfo
Copy link

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.

@GregoryEAllen
Copy link

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?

@MartinMKD
Copy link

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

@GregoryEAllen
Copy link

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

@MartinMKD
Copy link

I am not paying 100 euros for something as simple as this. I'll try the self signed cert approach. I can live w/a smartcard + password login, but I definitely want to learn how to disable login and leave smartcard only enabled.

@andyneff
Copy link
Contributor

@MartinMKD The rest of the instructions mentioned at https://support.apple.com/en-us/HT208372 will guide you through smart card ONLY setup (via editing PAM files). Basically they say "Smart card is sufficient" and then if you go down the password (pam_opendirectory) route it is "denied" (pam_deny)

Warning: There is a bug I've observed in Catalina that trying to unlock "Users & Groups" will not work with a smart card. All other Settings admin unlocks DO work (AFAIK) with a smart card, but that one will not. I have no idea why this is. This means it becomes impossible to access this menu (without editing the pam file first, temporarily, and then using a password to log in. It is the authorization file that controls all the GUI admin unlocks.

@zero-one-devteam
Copy link

Whats not quite clear to me: If I've enabled SmartCard only via profile, why should I edit /etc/pam.d/login?

@andyneff
Copy link
Contributor

Unfortunately I'm not sure, as I don't have a clue what a Profile or Configurator is, and I don't know what those profile settings even do. If Configurator edits the pam files for you with those settings, then I suspect no, you don't need to edit /etc/pam.d.

(My use case was setting up with an AD domain, so it's a little different, but I have it working). However, I do understand the PAM changes, and they make sense to me, so I can try and help with that part.

@zero-one-devteam
Copy link

No, the profile does not make any changes in the pam files. I do not know what they will do ... my user is an AD user as well but I set up the smartcard outside AD.

@tob1k
Copy link

tob1k commented Jan 22, 2020

FWIW I just took the config sample from apples documentation here and saved it with a .mobileconfig extension, and applied it using the Profiles prefpane and it's all working hunky dory.

This has enforced smart cards everywhere, sudo, screensaver lock, etc without editing any pam files, or dealing with configurator/profile creator etc.

Granted the profile isn't signed, but for my purposes (a small team of 12 devs or so) this is fine.

Thanks again @MartinMKD for pointing me in the right direction here 🙏

@maxheld83
Copy link

not to be pedantic, but any chance the discussion about smartcard config could move somewhere else?
As I understand it this issue is about PAM support, not smartcard.

@MartinMKD
Copy link

The smartcard discussion is relevant to anyone who is grappling with the PAM issue if nothing else then as a workaround.

@dagheyman
Copy link

FYI, we put together a small guide on the macOS smart card support, heavily based on Apples documentation, available here: https://developers.yubico.com/PIV/Guides/Smart_card-only_authentication_on_macOS.html

No updates on the pam module as far as I know.

@MillsapCyber
Copy link

Any update on the pam module?
I just tested on 10.15.3 and everything seems to work fine, until you reboot. From a reboot you can't log in and the only way to fix it is by booting to recovery mode, mounting your system partition, and removing the yubikey code from the pam files.
Also even when everything is working, the yubikey was not required to unlock the system with touchID, the system would just log in even if the key was unplugged.

@andyneff
Copy link
Contributor

@MillsapCyber As far as I know, if you want to enforce 2fa, you need to disable touchID, it will always bypass all other pam security measures.

pam_yubico.so still did not work on the latest Catalina, when I tried on 3/23/2019.

I've looked into this a little more since last time. It seems like only the pam modules that don't exist as actual files on disk work in Catalina. pam_krb5.so, pam_ntlm.so, pam_opendirectory.so, pam_opendirectory.so, etc... won't be found on your filesystem anywhere, it's like they are virtually somewhere else, and only those files will work always. It's almost as if Apple decided these are the only ones that can be trusted, and will only use them, but that's a pure guess on my part. It's a shame this problem has yet to be addressed by Apple...

@ChristopheH-Ekonoo
Copy link

Anyone has already tested with the new version 10.15.4?
Thanks
Any response from Apple?

@TarekMowafy
Copy link

TarekMowafy commented Mar 29, 2020

@ChristopheH-Ekonoo i am trying to setup my key on 10.15.4 but it keeps failing

➜ ~ ykpamcfg -2
USB error: unknown error

@Frederick888
Copy link
Author

(I'm back on macOS, duh...)

I can still confirm this issue on 10.15.5.

Btw I noticed that screen saver does not crash if yubico_pam is not the last one in your PAM auth stack (probably...).

@nevun
Copy link
Contributor

nevun commented Oct 1, 2020

There has been a workaround committed for this in the yubikey-personalization repo.

If you run homebrew, try applying this diff to the ykpers formula:
nevun/homebrew-core@8f433b6

..and then do brew reinstall ykpers. This made it work for me on catalina

% sw_vers 
ProductName:	Mac OS X
ProductVersion:	10.15.7
BuildVersion:	19H2
debug: pam_yubico.c:838 (parse_cfg): called.
debug: pam_yubico.c:839 (parse_cfg): flags -2147483648 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=/tmp/lol
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=5
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: user
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: 3.5.0

debug: pam_yubico.c:528 (do_challenge_response): Loading challenge from file /Users/user/.yubico/challenge-7346642
debug: util.c:437 (load_chalresp_state): Challenge: 860d5142c4535001d5c6f58ffa6879baf37d9468cbe219561292ef868f0cec258fdc4646cee54707df7bf184c3acc9b2b7a0d2121bd640655c2f539ca71a16, hashed response: cce19f04672c22899c7288ebc4248296d9f9e535, salt: bf26a4e37b149057465e7a23edbcabd6a8a3bdc6dd98bd71894e3311b5a41d9b, iterations: 10000, slot: 2
debug: pam_yubico.c:604 (do_challenge_response): Got the expected response, generating new challenge (63 bytes).
debug: pam_yubico.c:690 (do_challenge_response): Challenge-response success!
debug: pam_yubico.c:1220 (pam_sm_authenticate): done. [success]

@Frederick888
Copy link
Author

@nevun May I know if Yubico/yubikey-personalization@7ee7b11 is the only required patch here?

I'm not able to verify this atm so I'd appreciate it if anyone can backport it and check it out. It can be cherry picked onto v1.20.0 without any merge issues.

@nevun
Copy link
Contributor

nevun commented Oct 2, 2020

@Frederick888 yes. but please be aware of the fact that this is a work around and might stop working at any time.

@rotorstudios-gg
Copy link

@nevun We've used the mac login tool pkg from yubico. How do we apply this fix? Do we need homebrew ?

@nevun
Copy link
Contributor

nevun commented Nov 24, 2020

@rotorstudios-gg there has not been a new release of yubico-pam packaged for mac by Yubico and since the package bundles libykpers you either have to build libykpers yourself and replace the dependency lib or remove the mac package and go with homebrew for both. I am not sure about your situation, it might make sense to take this to [email protected]?

Note, I am not an official spoke person on this matter for Yubico. I used the homebrew version though when I tested this on Catalina.

@rotorstudios-gg
Copy link

@nevun thanks. can you share how you got the homebrew version working? I got as far as installing homebrew via "/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" " . Thanks again

@nevun
Copy link
Contributor

nevun commented Nov 24, 2020

@rotorstudios-gg if you have install brew, next step is brew install pam_yubico should be enough to install the pam module and pull in the libykpers library which already has the applied patch required.

Note that you should definitely have a root shell opened in another terminal ready in case you mess up your pam config because sudo might stop working. I cannot stress this enough, as soon as you touch the pam configuration, you need to test it in another terminal before closing the root shell terminal because otherwise you could lock yourself out of your system.

After you installed the pam_yubico module from brew you should update your pam configuration to point to the correct pam module (the one from brew, not the one you had before).

Good luck

@rotorstudios-gg
Copy link

@nevun Thanks for that. Where is the patched libykpers library?

@nevun
Copy link
Contributor

nevun commented Nov 25, 2020

@rotorstudios-gg the homebrew repo already includes the patch so you only need to install pam_yubico through brew (https://github.com/Homebrew/homebrew-core/blob/master/Formula/ykpers.rb#L36)

@Frederick888
Copy link
Author

By the way has anyone tested pam_yubico on macOS 11 (Big Sur)?

@rotorstudios-gg
Copy link

Thanks @nevun . That worked and I am using Big Sur. Now the next question is that if I dont want to use homebrew and create a standalone .pkg to be deployed, how do I find out what files are required? is it just the /usr/local/lib/security/pam_yubico.so file?

PS: I am familiar with creating pkg (via the Packages tool).

@nevun
Copy link
Contributor

nevun commented Nov 27, 2020

@rotorstudios-gg glad to hear it!

You can run otool -L /usr/local/lib/security/pam_yubico.so to see which libraries it depends on that you also need to bundle. libykpers also needs libjson-c for exampel. Feels like a brittle solution to me. Yubico making a yubikey-personalization release and then making a new yubico-pam release using that would be the best solution but I have no pull in getting that done.

@rotorstudios-gg
Copy link

Im not sure if this is the right place or not but it seems that although this now works (building/installing yubico via brew); it now breaks in the new M1 apple macbooks. The yubikey is recognized and is able to generate a challenge-response file but when prompting for user and password, the yubikey doesnt flash or anything and is immediately denied login. Just wondering if anyone else has found workarounds to this?
Thanks

@andyneff
Copy link
Contributor

andyneff commented Jun 7, 2021

@Frederick888 I just had one of my users update to BigSur, and they said the following:

folks, i have managed to elevate, sudo, and login + screensaver using the challenge-response mode of the yubikey
this was done by upgrading pam_yubico to version 2.27

By "elevate", they mean graphically, like in System Preferences.

@andyneff
Copy link
Contributor

andyneff commented Jun 7, 2021

We were upgrading from Mojave straight to Big Sur:

  1. Install Xcode from the Appstore App
  2. from the terminal run xcode-select --install
  3. brew update
  4. git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core fetch --unshallow
  5. brew update
  6. brew uninstall pam_yubico
  7. brew install pam_yubico

Brew needed a little special help. We uninstalled then reinstalled pam_yubico because we were told that both the fixed version and broken version were numbered 2.27, so we didn't know how brew would react to seeing the old 2.27 was already installed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests