Hi, I have met with a rather interesting phenomenon today and I couldn't figure out the reason. As part of a script, I import certificates and for that I create a designated keychain: security create-keychain -p "" $KEYCHAIN_NAME.keychain-db This has so far been creating the keychain at the expected location, Users/my-user/Library/Keychains/$KEYCHAIN_NAME.keychain-db. However, I have noticed that since yesterday, my script has been failing with a security: SecKeychainCreate XXXXXXXXX.keychain-db: UNIX[Permission denied] error. I kept investigating and noticed that the same script as given above, now tries to create the keychain on the /Library/Keychains/$KEYCHAIN_NAME.keychain-db path (the same path where System.keychain is located). I confirmed this in two ways: running the command with sudo no longer resulted in above UNIX error, instead created it next to the System keychain. locally, I tried to create a keychain with an absolute path, like this: security create-keychain -p 1234 "/Library/Keychains/new.keychain" and got back the same UNIX[Permission denied] error. I tried to poke around in the man page for security and search online, but found nothing that would mention the default path changing for the security command (because it must be some setting for security, given that a simple XXXX.keychain would be created at ~/Library/Keychain/***.keychain, whichever folder I execute the command from. Thanks in advance for any advice!

Hi! I am trying to make a UI Testing target in Xcode for my Application (Client). It works with Keychain items that are created during installation, so in order to mock this installation behavior I am creating the items like this: security add-generic-password -U -D "[item_kind]" -a "[account]" -l "[label]" -s [service] -w "[value]" -T path/to/UITest-runner.app -T path/to/Client-app.app However, during UI Testing, the application is still prompted to access or modify the Keychain Items as seen in the bottom half of this screenshot: These application paths have been obtained by the find terminal command inside DerivedData/.../Build/Products/... so they are the correct paths (which is also proven I guess by the fact that the apps are correctly listed in the ACL window of Keychain Access as seen on the top half of the screenshot). I also tried using the -A option instead of -T but the result is exactly the same. Why doesn't this approach work during UI Testing? I am using the same approach in my installation script for the real application installation process with the -T parameters and there is no issue in that case. This issue kills my UI Tests because I am constantly prompted when I want to read of modify the contents of these Keychain Items.

Hi! I am wondering about certain features that I witnessed today. Base scenario: I created a developer certificate signed version of my installer package and then downloaded it via the internet. It has not been notarized. As expected, macOS prevented the opening of the package, stating that it could not be determined whether it contained for malicious content. But, several operations I then performed made this package trusted by macOS: I moved the package through a file-sharing service via Finder, namely OneDrive. The recipient machine immediately opened the unsigned package, without any interruption from the operating system. This sounds extremely unsecure. I checked manually with xattr, and indeed, the com.apple.quarantine attribute has been removed on the recipient side. I used pkgutil to explode the package, modified some files in it, then recompiled it. xattr again confirmed that the quarantine attribute has been removed. Why can pkgutil operate on untrusted packages? I have personally been extremely surprised operations as simple as these remove security hurdles in macOS. These scenarios can be harmful for end-users who have little IT knowledge. Why are they allowed? Are these scenarios considered the responsibility of end-users? Why do we notarize and sign with precious distribution certificates if it's this simple to bypass any security check on macOS? :(

If I understand correctly, Apple Distribution certificate type aims to replace the separate platform-specific certificate types. (Please don't jump me, I know this is a very simplified way to put it :D) I am 100% sure Apple Distribution certificate can be used instead of a "Mac App Distribution" certificate, but I'm not sure whether the same is true for installers, namely the "Mac Installer Distribution" certificate. I have read eskimo's great articles on packaging (https://developer.apple.com/forums/thread/701581) and signing (https://developer.apple.com/forums/thread/128166) but I have not seen a definite answer to this question in those. Our command line builds started to fail with a 'no certificate of type Mac Installer Distribution is found' without any actual apparent change to the build process, so I'm just trying to understand this certificate type better. I see no sign of this certificate ever having existed in developer.apple.com under Certificates tab. We use the xcodebuild -exportArchive command with an -exportOptionsPlist that has the following content: <dict> <key>[redacted]</key> <string>[redacted]</string> <key>[redacted]</key> <string>[redacted]</string> </dict> <key>installerSigningCertificate</key> <string>3rd Party Mac Developer Installer</string> <key>signingCertificate</key> <string>Mac App Distribution</string> and this has not changed at all either between the last successful build and the failing ones. I listed the existing code signing identities with security find-identity -p codesigning and only an Apple Distribution certificate shows up, not Mac Installer Distribution certificate.

Basically what it says in the title. Is it expected that /var/db/auth.db is recreated when updating to a newer macOS major version? This effectively removes the installed authorization plug-ins from the login flow, decreasing the intended security. And it's not a good end-user experience either to have to reinstall the plugin after updating - nothing such can be noticed with regular applications.

Has anyone managed to ui test an authorization plugin that is based on SFAuthorizationPluginView? I have searched on the internet and nothing shows up. I know that if we open separate windows in a mechanism that's not based on SFAuthorizationPluginView we can create a standalone app for those windows and ui test them, but it would be great if we could UI test whole flows, beginning with SFAuthorizationPluginView / built in login window and then continue on our own windows in further mechanisms. What I tried: XCUITest needs an XCUIApplication to oparete on. But what is the application here? I'd assume it's SecurityAgentHelper-x86_64 (based on accessibility inspector that is the root ancestor of my window: SecurityAgentHelper-x86_64 > Login (window) > [my text field]). But that is an XPC process, which brings me to my next point: I don't think xpc processes can be the target application in XCUIApplication's init. The init(bundleIdentifier: "com.apple.SecurityAgentHelper.x86_64") call crashes with app not found, while the init(url: URL(string: "/System/Library/Frameworks/Security.framework/Versions/Current/MachServices/SecurityAgent.bundle/Contents/XPCServices/SecurityAgentHelper-x86_64.xpc")!) call simply hangs forever, then times out. Based on the Accessibility Inspector hierarchy this app is the host application which should be opened. Without a main XCUIApplication it is impossible to start querying UI elements for UI tests, so I am stuck here.

Hi, I have experienced undocumented changes in the behavior of SFAuthorizationPluginView and Authorization Plug-ins while testing our Auth Plugin under macOS Sonoma Beta 3 (latest seed as of today). Prerequisites: macOS Sonoma Beta 3 Settings &gt; Lock Screen &gt; Login window shows: List of Users Note: it is visible the login screen changed in behavior, this can be noticed even without the installation of any authorization plugin. There is now a default selected user with the password field always visible. Up until Ventura, a user had to be picked manually first to then open up their login password textfield. After logout I noticed that the order of delegate methods have changed. Previously, until macOS Ventura the order of methods seemed to be: displayView() --&gt; viewForType() --&gt; view.viewDidLoad() --&gt; willActivateWithUser() --&gt; firstResponder --&gt; didActivate() where view is my custom NSViewController.view embedded in the SFAuthorizationPluginView. viewDidLoad is called because my implementation of viewForType returns view - which in turn should call loadView() based on documentation for NSViewController.view: If this property’s value is not already set when you access it, the view controller invokes the loadView() method. Now it seems that the order has changed: displayView() --&gt; didActivate() --&gt; firstResponder This means that viewForType(), willActivateWithUser() are not called. And then my console application crash log shows that the application crashed at firstResponder, probably because view.viewDidLoad() is not called for my view due to viewForType() not being called either. Has anyone met a similar issue? This really seems like an undocumented change. macOS Ventura 13.3, plugin built with XCode 14.3.1 -&gt; our app works macOS Sonoma 14.0 Beta3, plugin built with XCode 14.3.1 -&gt; our app does not work macOS Sonoma 14.0 Beta3, plugin built with XCode 15.0 Beta4 -&gt; our app does not work P.S.: I do see methods new in macOS Sonoma appeared for NSViewController, like loadViewIfNeeded - but sadly these new methods have zero documentation attached. P.S #2: I have checked with a minimal repro example, and the order has indeed changed. When the view does not have to be loaded via an NSViewController, i can see the full new order: displayView() --&gt; didActivate() --&gt; firstResponder --&gt; viewForType() --&gt; willActivateWithUser() --&gt; didActivate() (called twice??) --&gt; firstResponder --&gt; firstResponder This above order of calls is without a single user interaction, just logging out (or using security authorize -u system.login.console from the terminal)

I am currently in a rather problematic context while developing my custom login application. I leave the original loginwindow:login mechanism intact, and present a non-privileged GUI auth plugin. (So it is not based on SFAuthorizationPluginView). The problem to solve I'll be as specific as possible, because the following certainly seems a very security-intensive task. The problem I'm trying to solve is storing a secret item in Keychain that is relevant only for the currently logging in user. This looks like an issue because: The "login" keychain item for said user is unavailable, as I am outside of the per-user security context based on Daemons and Agents. The "system" keychain item is available if I connect to a launchd daemon, but if I understand correctly, this is a file-based keychain item. Option 2 looks like a definite go-to from the two, but I have several issues with the (seemingly) only available option 1 - The keychain basically loses its purpose if I use the "system" Keychain, because anyone with admin credentials can open and read the item, not just the currently logging in user. So I would have to implement manual per-user encryption INSIDE the system keychain. I (maybe falsely) view the keychain as the equivalent of a password-based key derivation function, and in this example, I would have to implement a double encrpytion: [System Keychain] ---(encryption)---> [keychain item] ---(my own encryption, maybe something based on PBKDF2 + AES-GCM, which is partly CommonCrypto, so I really want to avoid it)---> [secret] 2 - The system keychain is a file-based keychain as far as I know, thus it cannot be protected by the Secure Enclave, which means based on documentation that: Keeping a private key in a keychain is a great way to secure it. The key data is encrypted on disk and accessible only to your app or the apps you authorize. However, to use the key, you must briefly copy a plain-text version of it into system memory. While this presents a reasonably small attack surface, there’s still the chance that if your app is compromised, the key could also become compromised. As an added layer of protection, you can protect a private key using the Secure Enclave. 3 - Can a file-based keychain still be trusted? Does it use the same encryption algorithms as the data protection keychain? Based on documentation for Keychain, Keychain items are encrypted using two different AES-256-GCM keys: a table key (metadata) and a per-row key (secret key). But since this certain piece of documentation seems to not detail normally the difference between file-based and data protection keychains, still it says (right at the top!) that "In macOS (including a Mac with Apple silicon), Data Protection is not used directly to enforce these guarantees.", I am really unsure if the above encryption details are used for file-based keychains. I do not want to use some old, unsecure encryption mechanism if I can avoid it, and yet, file-based keychains seem to be the only option for me. I really want to make sure file-based keychain indeed uses an algorithm that is (currently) considered secure. 4 - Which brings me to another issue: I seem to have non-conditional access to the user's password via context values. I can freely query it with GetContextValue passing kAuthorizationEnvironmentPassword. This does not seem secure, its availability although looks related to another context key, kAuthorizationEnvironmentShared. Is this really set by Apple's own mechanism? And is this okay? What stops me from creating a malicious auth plug-in and just constantly reading this value from every login session? Obviously users need to install plugins themselves, but any benign-looking plugin can exploit this. And if this is true, I have better things to worry about than a momentary plain-text exposure of my key without the use of secure enclave. 5 - Although this above feature(? bug?) makes it easy to hash the password, send it (hopefully securely - client side sets .priviliged flag on the connection and daemon side implements Code Signing Requirement check) via XPC to the launchd daemon, and then encrypt the secret based on that. _Is this something that's okay? As a primary attempt, I thought about switching my userid temporarily (which I can do from a launch daemon by pthread_setugid_np), creating a custom file-based keychain item with SecKeychainCreate in the user's Application Support directory, protecting it with their password that I can obtain by above means, and then save the secret unencrypted there, because this way I (seemingly...) have some advantages over the system keychain: A - My Keychain file is only accessible once the user's home directory is mounted, meaning that HomeDirMechanism has already run for the current user. This seems to separate my file from other users of the machine. B - My Keychain item is not protected by any admin's credential anymore, instead, it is only unlockable by the current user's password. This seems like an option where I can avoid the above-described double encryption since it provides no gain to encrypt something by a user's password myself if it's already in a file-based keychain protected by the user's password (if the used encryption is indeed aes-256-gcm). C - I no longer have to give (in my opinion) very unsecure access to my Keychain Item to the security agent, in order to avoid a credentials popup, but instead, I can use the (sadly deprecated) SecKeychainUnlock/SecKeychainOpen APIs to retrieve the item from the keychain. So the custom keychain is not openly accessible by any process hiding behind the securityagent/authorizationhost. The main question is definitely this above attempt and whether it's secure or not This is obviously a very long post, with lots of questions, but I believe it's about a very important concept that's probably overlooked by more important OS features. I am mostly just looking for confirmation/disproof. Authorization Plugins are definitely old school, but they are a crucial part of the OS and they deserve the greatest security measures, yet, they seem to have lacking support for them (this is mostly a reference to data protection keychain being unavailable).

Our team is working on an Authorization Plugin that includes a UI as well, thus it works by creating a subclass of SFAuthorizationPluginView. Some of our users have reported that controls remain on the screen for a period of time even after a successful login. As shown in the attached screenshot, the native, inherited controls are the ones that remain on the screen, our plugin's controls disappear immediately. What I did to investigate this issue further, is that I checked the very basic Apple-provided example (modified by the community to bypass its issues): https://github.com/antoinebell/NameAndPassword Our users reported the exact same behavior once more. Inherited native controls (the back, forward buttons, the bottom 3 buttons <restart, sleep...>) all remained on the screen for a significant amount of time, even after the PluginDestroy and MechanismDestroy functions have been called. I would like to get confirmation on whether this is indeed an Apple-side issue or if anyone else have met this problem. I as a developer failed to replicate it, but users reported a 100% reproduction rate. Their setup was: Mac Mini (M1, 2020) macOS Monterey version 12.6 (later they reported the same behavior with macOS Ventura 13.0 and 13.1 as well) Thanks in advance! Screenshot: https://www.icloud.com/iclouddrive/008--bn6TlDACoimvINZYTAkQ#login%5Fscreen%5Fissue