Apologies for a late reply.Thank you for a quick response.

Thank you very much for a quick response. I see you have already mentioned, "I’m not aware of a good workaround." Here are the steps to reproduce with Mac provided settings:- We modified the system.login.screensaver configuration to switch from the modern UI to the legacy UI method in order to support our custom SFAuthorizationPluginView. Specifically, we replaced use-login-window-ui with authenticate-session-owner-or-admin. Note: without our custom SFAuthorizationPluginView integration After this change, attempting to launch Keychain access app triggers two consecutive password prompts, and the application fails to launch. This issue is occurring with the released version of our agent, we would end up more support calls. Again, checking if there are any suggestions, this was completely broken in unlock the screen flow with legacy UI configuration authenticate-session-owner-or-admin. Any tentative release plans to get a fix for FB13128730 Any help would be highly appreciated.

Thank you for your response. We would greatly appreciate it if you could provide any recommendations, along with details(high-level) on the potential impacts of this issue. This information will help us prepare and include an appropriate advisory in the released version and upcoming releases.

Many thanks for getting back to me. Or whether that code will work in an authorisation plug-in? I’m looking for USB monitoring code that can function within an authorization plugin, specifically, a custom GUI AuthPlugin window that displays prompts when a FIDO key is inserted or removed.

Thanks again for your inputs. Yes, I started with a test app, and it worked as expected. Then I moved on to the authorization plugin, where the detection part isn’t behaving as expected. I later thought of checking with Apple in case there’s any limitation around the monitoring part within securityd. I’ll review it again based on your suggestions to see if I missed anything.

Thank you! The APIs listed below are utilized to identify FIDO HID devices exclusively, with their corresponding callback registration functions shown here. // Match only FIDO HID devices let matchingDict: [String: Any] = [ kIOHIDDeviceUsagePageKey as String: 0xF1D0 ] IOHIDManagerSetDeviceMatching(mgr, matchingDict as CFDictionary) // Register callbacks IOHIDManagerRegisterDeviceMatchingCallback(mgr, deviceAddedCallback, UnsafeMutableRawPointer(Unmanaged.passUnretained(self).toOpaque())) IOHIDManagerRegisterDeviceRemovalCallback(mgr, deviceRemovedCallback, UnsafeMutableRawPointer(Unmanaged.passUnretained(self).toOpaque())) // Schedule with current run loop IOHIDManagerScheduleWithRunLoop(mgr, CFRunLoopGetCurrent(), CFRunLoopMode.defaultMode.rawValue) let result = IOHIDManagerOpen(mgr, IOOptionBits(kIOHIDOptionsTypeNone)) Randomly it crashes at runloop Terminating Process: SecurityAgentHelper-arm64 [2303] Application Specific Information: abort() called Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x1883c9c34 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x1883dc3a0 mach_msg2_internal + 76 2 libsystem_kernel.dylib 0x1883d2764 mach_msg_overwrite + 484 3 libsystem_kernel.dylib 0x1883c9fa8 mach_msg + 24 4 CoreFoundation 0x1884f6cbc __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x1884f55d8 __CFRunLoopRun + 1208 6 CoreFoundation 0x1884f4a98 CFRunLoopRunSpecific + 572 7 HIToolbox 0x193f9727c RunCurrentEventLoopInMode + 324 8 HIToolbox 0x193f9a4e8 ReceiveNextEventCommon + 676 9 HIToolbox 0x194125484 _BlockUntilNextEventMatchingListInModeWithFilter + 76 I’m able to perform FIDO authentication with the key inserted via USB randomly crashes most of the time crash log shows runloop; however, NFC-based authentication does not work (NFC-over-HID devices (OMNIKEY): communication with ctkpcscd failed Could you please share any inputs

Thanks for your time and input. After making a few code changes, everything started working. I’ve moved the monitoring logic into an XPC daemon, and things are functioning as expected.

Thanks for the detailed information. I’ll take a look and follow up. _It’s hard to say what’s going on there without seeing the specific requirement you’re using_ Here are the specific requirement i've tried anchor apple generic and ( identifier "com.apple.SecurityAgentHelper.arm64" or identifier "com.apple.loginwindow" or identifier "com.apple.authorizationhost") Thanks!

Thanks for the detailed information. I’ll take a look and follow up. _It’s hard to say what’s going on there without seeing the specific requirement you’re using_ Here are the specific requirement i'm using from the Authorization Plugin(xpc client) "com.apple.SecurityAgentHelper.arm64", "com.apple.loginwindow", "com.apple.authorizationhost", "com.apple.SecurityAgent", bash-3.2$ codesign --display -r - /System/Library/CoreServices/loginwindow.app Executable=/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow designated => identifier "com.apple.loginwindow" and anchor apple I attempted to apply a loose constraint (accepting any Apple-signed code), but it still fails. Please let me know if I’m approaching the loose constraint correctly. I was able to block other applications(created a custom app) trying to connect to my daemon. However, during the login and lock screen flows, it fails with error -67050 (errSecCSReqFailed). Is there a way to identify whether the client originates from Authorization Services or SFAuthorization and ignore the security check? It would be helpful if you could share any info. Thanks!

Thank you again for the prompt response and for sharing the additional information. How would you expect that to work? Your plug-in is loaded into a system process. How can your daemon, as the XPC listener, identify which code within that process sent the XPC message. It’s conceptually impossible. I acknowledge the limitation,I wouldn’t try to distinguish specific code within the process, since that isn’t feasible. Instead, I’d skip client validation for the authorization plug-in path. For other clients communicating with the daemon, I already enforce validation using proper identifiers and code-signing checks and works. Since the core logic is shared, the idea is to rely on those validated clients and bypass the check only for the authorization process. Now I’d argue that defending yourself from rogue authorisation plug-ins is pointless, because if an attacker is in a position to install an authorisation plug-in the game is basically over, but that’s a policy question that’s firmly in your court. I completely agree, if someone can install an authorization plug-in, they already have deep access. My intent was mainly to get confirmation and close for our internal security reference.considerations. Thanks!