Closed cmagahern closed 3 years ago
Thanks for your interest in this project! Do note that this project specifically deals with the keyboard interface parts of the YubiKey, so it needs to open the keyboard interface. Do these changes fix something that doesn't work without them?
Thanks for your interest in this project! Do note that this project specifically deals with the keyboard interface parts of the YubiKey, so it needs to open the keyboard interface.
Is there a reason why it specifically needs to open the keyboard device instead of the FIDO device? In my testing with two different U2F tokens, I can see that sending HID reports to the FIDO device works in exactly the same way as when opening the keyboard device, with the exception that the OS doesn't need to prompt for user approval.
Do these changes fix something that doesn't work without them?
Yes, in macOS Catalina and later, initializing a IOHID user device for keyboard or pointer devices requires explicit user approval. This is because opening these kinds of devices is a common attack vector for malware such as keyloggers or remote access tools (RATs). As a result, a large amount of the software stack around PAM authentication does not work at all in macOS Catalina or later. For example the ykpamcfg
provisioning tool can't communicate with any USB YubiKey devices, nor can the PAM module work when loaded inside loginwindow
or SecurityAgent
.
This fix will allow users to be able to use YubiKey U2F tokens again for macOS login as well as build other applications on top of the PAM infrastructure.
Ok. I see what you're saying. This is a bit counter intuitive, but should work as long as there is no enforcement of authorization for the FIDO interface. An interesting parallel here is windows where there is heavy enforcement of the FIDO interface, I will have to look a bit at the compatibility with different YubiKeys of something like this, so leaving it open for a couple of days until I've had the possibility to do that.
Thanks for the longer explanation and the code!
I'll merge this. It is not the very straightforward, but if it makes apple devices work better it makes sense to do. Is this interface going to remain open? Will this continue to be possible?
I appreciate you merging the patch, thanks!
The IOHID userspace APIs will remain open since a lot of third-party apps rely on it for low-level access to hardware devices. The security restrictions apply only to keyboards and pointer devices because of the privacy concerns mentioned earlier.
Starting in macOS Big Sur, we added first-party support for a FIDO usage page in the public IOKit framework which can be used to identify U2F devices as well as for sending report data to these devices. (e.g. kHIDUsage_FIDO_U2FDevice
) Adopting these new usage pages is not something I recommend doing right now, since you likely want to maintain backward compatibility with a couple of previous macOS versions, but it at least demonstrates Apple's commitment to the FIDO standard and the permanence of U2F over HID.
Thanks for the response!
I was mostly pondering whether Apple would continue to consider the FIDO endpoints as not of concern and allow traffic. Microsoft has made a different choice there, so it would be helpful to know ahead of time if this kind of thing will break.
I don't know of any plans in the near future to change access to FIDO devices, but I will do my best to let you know if there is. :-)
When opening a connection to the USB HID device, always prefer the FIDO interface over the keyboard one in the macOS platform layer. This is because accessing keyboard and pointer HID devices is protected behind explicit user dialogs starting in macOS Catalina. PAM modules are loaded in various privileged system processes that do not trigger permission prompts, so it is important that the support libraries prefer the FIDO device instead, which does not require explicit user authorization.
Apple Legal ticket OSS-3019