- Managed Login Items
Managed Login Items are something which will I expect will be widely blogged about, but SystemPolicyAppBundles might not be as to trigger this new PPPC requires a narrow path to be trodden and even then, can be bypassed.
The below details the path required to trigger this new PPPC, and how to bypass.
Throughout the beta period of macOS Ventura the only publicly available documentation is that which is shown in the header image of this article, and available at: https://developer.apple.com/documentation/devicemanagement/privacypreferencespolicycontrol/services.
In addition, AppleSeed for IT had no test plans for this PPPC (unlike Managed Login Items) and the documentation supplied to AppleSeed for IT contained only 4 bullet points of detail.
As such, I’ll not be surprised if this new PPPC is unknown by many.
So, what is this “path”?
Well, several conditions must be met for SystemPolicyAppBundles to be triggered:
- The application must be signed, hardened and notarised.
- The application has to have been launched at least once.
And, the following will not trigger this new PPPC:
- Deleting the application.
- Deploying a package which is signed by the same developer.
- The InstallEnterpriseApplicationCommand can update or modify applications.
- This new PPPC is a subset of Full Disk Access (aka: SystemPolicyAllFiles). So if the installing process has Full Disk Access, it’ll also have the needed PPPC to not trigger SystemPolicyAppBundles.
Therefore, if your testing has been with signed vendor packages or via an MDM using the InstallEnterpriseApplicationCommand, you’ll have not triggered this new PPPC.
Likewise, if testing installations via DMG where the item installing the DMG deletes the application prior to copying from the DMG (such as, Munki’s copy_from_dmg functionality), then you’ll have not triggered this DMG (as per the above conditions).
So, the bypass that I alluded to prior isn’t to do with the aforementioned path or items which are expected to not trigger this new PPPC. It is to do with differing package formats.
As per the above, macOS has several package formats. And in my testing, component packages bypass this new PPPC but distribution packages do not (I haven’t tested all formats, so it’s possible that more bypass this new PPPC).
So, not only might your own testing not have triggered SystemPolicyAppBundles as it might have deviated from the undocumented path needing to be followed to trigger this new PPPC. It could well be that the format of the package(s) you’ve been testing were not triggering SystemPolicyAppBundles.
Trust, but verify…
Don’t just take my word for it, to recreate:
- Install Google Chrome on macOS Ventura manually from their website.
- Launch and quit Google Chrome.
- Create 2 packages of Google Chrome, just containing the application bundle in applications:
- Install the packages, in any order.
The expectation is that you should see the below when installing either package. But macOS will only prompt installing the distribution package (if you click OK, you’ll need to remove Installer from App Management to correctly re-test):
Feedback or CVE?
This has been logged as:
FB11700807 (macOS Ventura - SystemPolicyAppBundles protection, bypassed by some types of package)
I don’t see this as a CVE, as this is either undocumented behaviour for SystemPolicyAppBundles or it’s an oversight with a new protection.
If this was a change in behaviour for a prior working PPPC, then maybe would look at raising this as more of a CVE.
I expect Apple will correct this behaviour in a future revision of macOS Ventura, and as such I’d suggest testing workflows with distribution packages to make sure you have the needed PPPCP’s in place.
Many thanks to the folks that helped define the path to trigger SystemPolicyAppBundles, and those paths that were expected not to trigger this new PPPC.
And a special thanks to Patrick van Nerum for helping me confirm that package formats were at play here.