Apple's Worldwide Developer Conference (WWDC) session What's new in privacy introduced a new security feature in macOS Ventura called App Management. Here's an excerpt from the session transcript.
Gatekeeper checks the integrity of newly-downloaded apps. In macOS Ventura, Gatekeeper will now check the integrity of all notarized apps, not just quarantined apps.
First, apps need to be properly signed. Starting with macOS Ventura, if your notarized app is no longer validly signed, it will be blocked by Gatekeeper on first launch. You should sign all your executables and bundles and ensure that their signatures stay valid when you make changes to your apps. In addition to an integrity check, Gatekeeper will also prevent your app from being modified in certain ways.
The most common way apps are modified is for updates. Apps validly signed by the same developer account or team will continue to be able to update each other. This will just work.
To allow another development team to update your app or restrict updates to only your updater, you can update your info-plist. For example, here, Unrelated App can allow Pal About to update it with just a plist change.
Simply add the NSUpdateSecurityPolicy you want to allow. Within NSUpdateSecurityPolicy, add “AllowProcesses”, a dictionary mapping team identifiers to an array of signing identifiers. In this example, the policy allows any process with the signing identifier com.example.pal.about signed by Pal About's team identifier to update your app. If an app is modified by something that isn't signed by the same development team and isn't allowed by an NSUpdateSecurityPolicy, macOS will block the modification and notify the user that an app wants to manage other apps. Clicking on the notification sends people to System Settings, where they can allow an app to update and modify other apps.
Under Privacy & Security in System Settings — don't even get me started on System Settings — you can find the new section App Management. By default, it's an empty list. (Disclaimer: These screenshots were taken on a non-retina monitor, but any other crappiness is attributable to Ventura.)
For illustration, I'll use my open source Mac app Bonjeff, which has been notarized by Apple, and I'll attempt to modify the app's license file, which is located at the file path /Applications/Bonjeff.app/Contents/Resources/LICENSE.txt inside the app bundle. I've written a "maliciously crafted" test app to modify the license file using the Objective-C -[NSString writeToFile: atomically: encoding: error:] API. Here's some code to replace the contents of the license file with the string "Testing":
[@"Testing"
writeToFile: @"/Applications/Bonjeff.app/Contents/Resources/LICENSE.txt"
atomically: NO
encoding: NSUTF8StringEncoding
error: NULL];When I run the test app containing this code, I get a Privacy & Security system notification saying that my test app "was prevented from modifying apps on your Mac."
When I hover over the notification, I see a close button and an Allow… button.
The Allow… button doesn't actually allow modification, it simply opens the App Management section in System Settings.
Bonjeff is still validly code signed and hasn't been modified.
% codesign --verify --verbose /Applications/Bonjeff.app
/Applications/Bonjeff.app: valid on disk
/Applications/Bonjeff.app: satisfies its Designated RequirementIf I want to give my test app permission to modify other apps, I have to enter my administrator password.
After my test app relaunches, it is able to modify Bonjeff app successfully.
% codesign --verify --verbose /Applications/Bonjeff.app
/Applications/Bonjeff.app: a sealed resource is missing or invalid
file modified: /Applications/Bonjeff.app/Contents/Resources/LICENSE.txtNonetheless, the modified Bonjeff app still launches successfully, which raises questions about Apple's explanation of the feature. The WWDC session said, "Starting with macOS Ventura, if your notarized app is no longer validly signed, it will be blocked by Gatekeeper on first launch." How does the "first launch" qualifier make Ventura different from previous versions of macOS? In my testing, the difference seems to be that Ventura will block the first launch of a modified notarized app even if the quarantine extended attribute (xattr) was removed from the app, whereas Monterey and earlier will only block the first launch if the modified notarized app is still quarantined. (The quarantine is added by your web browser when you download the app.)
It's unclear how much of a barrier this poses to attacks, however, because the app could be allowed to run first unmodified before it's then maliciously modified and run again. I've seen it claimed elsewhere that Ventura will block any launch of a notarized app if its code signature has been broken, but this is proven untrue in testing.
We've examined what happens when a maliciously crafted app attempts to modify another notarized app. But what if I try to modify the notarized Bonjour app directly from the Terminal app; is that also prevented? Well, it depends! By default, it is prevented.
% echo "Testing" > /Applications/Bonjeff.app/Contents/Resources/LICENSE.txt
zsh: operation not permitted: /Applications/Bonjeff.app/Contents/Resources/LICENSE.txt
Now I'll try again, but this time granting full disk access to Terminal. (I've restored the original, unmodified version of Bonjeff in Finder for this additional test.)
% echo "Testing" > /Applications/Bonjeff.app/Contents/Resources/LICENSE.txt
% codesign --verify --verbose /Applications/Bonjeff.app
/Applications/Bonjeff.app: a sealed resource is missing or invalid
file modified: /Applications/Bonjeff.app/Contents/Resources/LICENSE.txtIt turns out that full disk access automatically entails app management permission. This is true even if app management permission is disabled for Terminal in System Settings! So the user interface can be misleading.
Regular readers of my blog may remember that a month ago I wrote about how every unsandboxed app has Full Disk Access if Terminal does. I had a bit of a "hidden agenda" behind that blog post, because it was preparation for this blog post! If Terminal app is granted full disk access, as it frequently is by Mac "power users", then Terminal is thereby granted app management on Ventura. Consequently, any unsandboxed app is also granted app management permission on Ventura, because an unsandboxed app can "piggyback" on Terminal's permissions by running a shell script in Terminal.
By the way, I reported all of my findings to Apple Product Security, including the App Management implications on Ventura, before publishing last month's blog post. To their credit, Apple Product Security was patient and responsive to my multiple emails exploring the issue, and seemed genuinely curious about it. In the end, though, they didn't see a problem: "After examining your report further, we do not see any actual security implications. This is because using Full Disk Access to modify an app in Terminal is expected behavior."
I may have the last laugh, though, because in the process of writing this blog post, I found a new App Management bypass that doesn't require full disk access. I won't discuss the details of that here (I sent them to Apple Product Security a few days ago), but I will discuss one more thing. Surprisingly, there are at least six different ways for an app to acquire app management permissions, four of which I've already mentioned above.
NSUpdateSecurityPolicy in the modified app's Info.plist filecom.apple.macl extended attributeI blogged about the fifth, the com.apple.macl extended attribute, a few years ago when it was introduced in macOS Catalina. A file typically acquires the xattr as the result of a user action in Finder, such as drag and drop. You can see this if you disable Full Disk Access for Terminal, disable App Management for Terminal, and then enter the following.
% echo "Testing" > This time don't type /Applications/Bonjeff.app/Contents/Resources/LICENSE.txt but instead drag the file itself from Finder into Terminal, which will automatically add the file path at the end of the command. Even though Terminal no longer has any explicit app management permission, it now works, and Terminal can modify the file! Not only that, but Terminal will continue to have permission to modify the file indefinitely, after quit and relaunch. In fact, you can't remove access without disabling System Integrity Protection (SIP).
% xattr -l /Applications/Bonjeff.app/Contents/Resources/LICENSE.txt
com.apple.macl:It happens with the containing directory too! Enter the following in Terminal.
% ls -@lR Then drag the Bonjeff app from Finder into Terminal and run the command. Now it's game over for App Management.
% echo "Testing" > /Applications/Bonjeff.app/Contents/MacOS/Bonjeff
% cat /Applications/Bonjeff.app/Contents/MacOS/Bonjeff
TestingDragging the app (which is a package) into Terminal adds a com.apple.macl xattr to the app and gives Terminal access to everything inside the app, permanently. This makes macl a minefield. Actions that users perform can leave little silent macl attributes all over the place on disk, and the users are none the wiser. You can't even easily tell which app is granted access by a macl, because the structure of the value is opaque and undocumented. Your file system is now a random collection of little special permissions that you can neither view nor remove. Welcome to the future of macOS security.