Testing for Ventura App Management privacy protections

[Gregory Neagle]

Apple has added a new “privacy protection” to macOS Ventura: “App Managment”. The intent is to prevent unauthorized software from modifying (including updating) or removing application bundles.

In practice, this protection isn’t triggered very often with Munki: /usr/bin/installer is allowed to install signed packages if the identifier and developer ID match; Munki removes the existing app bundle before copying in the updated bundle with copy_from_dmg items, so in most cases, Munki is allowed to install and update and remove app bundles.

But it _is_ possible to trigger this protection, and Munki will need changes to allow admins to approve managedsoftwareupdate as allowed to update apps.

I need help in testing. Since it’s fairly tricky to reliably trigger the protections, I’ve made available an archive here (https://www.dropbox.com/s/ci6putvmyjlanct/Munki_App_Management_test_resources.zip?dl=1) that contains resources and instructions for 1) replicating the issue, and 2) allowing the admin to approve managedsoftwareupdate for App Management, and thereby avoid the issue.

If you can test, please do, and share your results and findings here.

-Greg

[Gregory Neagle]

The link got formatted oddly and should be: 

https://www.dropbox.com/s/ci6putvmyjlanct/Munki_App_Management_test_resources.zip?dl=1

-Greg

[Allister Banks]

I tested on a single device, replicating the failure scenario and confirming that, after manually installing the provided 6.1 munkitools, pushing the MDM payload, and rebooting, the update then worked right away.

Allister

On Dec 6, 2022, at 2:31 AM, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> wrote:

Apple has added a new “privacy protection” to macOS Ventura: “App Managment”. The intent is to prevent unauthorized software from modifying (including updating) or removing application bundles.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/079E3DB6-B6CB-466F-86DC-31BE684ACA96%40mac.com.

[Gregory Neagle]

Thanks for this update! Which MDM payload did you use successfully? Full Disk Access or App Management?

-Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/9099B019-C6D1-4B60-90BD-263E82F4CB57%40aru-b.com.

[Allister Banks]

AppManagement, with the kindly included profile 2 as a base. I’m one version behind on my MDM but them not supporting the payload doesn’t prevent me from pushing arbitrary contents, by all indications it worked as specified/intended although I didn’t ask a binary with FDA to confirm the entry in the TCC db. Allister 

On Dec 7, 2022, at 1:09 AM, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> wrote:

Thanks for this update! Which MDM payload did you use successfully? Full Disk Access or App Management?

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/A836E076-2079-497D-934D-D8DDA7F565C5%40mac.com.

[Rob Renstrom]

I went though the test scenario in a macOS 13.0.1 virtual machine, and the install worked fine with Munki 6.1 and a SystemPolicyAppBundles PPPC profile for the signed managedsoftwareupdate (profile created in Intune).

I first tested with Munki 6.0.1 and was able to reproduce the failed install, as noted in apple system log:

 tccd    Refusing TCCAccessRequest for service kTCCServiceSystemPolicyAppBundles from client Sub:{/usr/sbin/installer}Resp:{TCCDProcess: identifier=com.apple.installer, pid=30197, auid=0, euid=0, responsible_path=/usr/sbin/installer, binary_path=/usr/sbin/installer} in background session

and install log:

shove[30204]: [source=file] failed _relinkFile(/Library/InstallerSandboxes/.PKInstallSandboxManager/67825AAC-C9F1-4B6D-94FE-A3A4E928AA76.activeSandbox/Root/Applications/Google Chrome.app/Contents/CodeResources, /Applications/Google Chrome.app/Contents/CodeResources): Operation not permitted

[pne...@gmail.com]

I will work in this this week and report back asap! 

[pne...@gmail.com]

I also went through te testing scenario and encountered the error when updating Chrome.

I used the SystemPolicyAppBundles profile provided by Greg and deployed it using Jamf School as a custom profile. Installed the signed Munki 6.1 client, followed by a reboot.

Managedsoftwareupdate was able to update Chrome successfully.

Patrick van Nerum

[Dave Bergstrom]

Replicated issue in test setup (Ventura 13.0.1, Munki 6.0.1).

Managed Software Center error:

• Jan 20 2023 14:29:29 -0500 Install of Google Chrome-106.0.5249.119: FAILED with return code: 1

/var/log/install.log error:

• installer[3046]: install:didFailWithError:Error Domain=PKInstallErrorDomain Code=120 "An unexpected error occurred while moving files to the final destination." UserInfo={NSUnderlyingError=0x600001a936f0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}, NSLocalizedDescription=An unexpected error occurred while moving files to the final destination., arguments=("-f", "-s", "/Library/InstallerSandboxes/.PKInstallSandboxManager/AFA44796-548D-49D5-9935-5AAB47BEAC24.activeSandbox/Root","/")}

system.log with tccd filter:

• Refusing TCCAccessRequest for service kTCCServiceSystemPolicyAppBundles from client Sub:{/usr/local/munki/Python.framework/Versions/3.9/bin/python3.9}Resp:{TCCDProcess: identifier=python3, pid=3500, auid=0, euid=0, responsible_path=/usr/local/munki/Python.framework/Versions/3.9/bin/python3.9, binary_path=/usr/local/munki/Python.framework/Versions/3.9/Resources/Python.app/Contents/MacOS/Python} in background session

Created a SystemPolicyAppBundles config profile with iMazing and deployed with Jamf Now, and updated Munki to 6.1.  Updating Chrome subsequently worked fine.  I did have to wait a little more than an hour just as described in the instructions.

Note that we haven't seen this issue much (or possibly at all?) in our prod environment -- assuming that's due to the relative difficulty of triggering this protection with Munki?

- Dave Bergstrom

[Gregory Neagle]

"and updated Munki to 6.1. “  I assume you mean you installed the test build of Munki with the compiled binary at /usr/local/munki/managedsoftwareupdate (as opposed to installing the Munki 6.1 release, which does not contain this binary).

"Note that we haven't seen this issue much (or possibly at all?) in our prod environment -- assuming that's due to the relative difficulty of triggering this protection with Munki?”

Yes, it’s fairly difficult to trigger — AFAIK we’re not seeing it with the packages we currently install. But it seems it’s just a matter of time (and maybe luck) before any of us are affected by the issue.

-Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/1ce46b0b-e362-4deb-a4e9-303a8a890914n%40googlegroups.com.

[Dave Bergstrom]

That's correct - I used the included munkitools-6.1.0.4533.pkg from the test resources.  

Thank you for that info!

- Dave

[Gregory Neagle]

Building on a lot of work by Kory Prince and Per Olofsson, here is a more robust approach:

https://github.com/munki/munki/tree/munkishim

https://www.dropbox.com/s/yqzjd0lhxyhfn0g/munkitools-6.3.0.4544.pkg?dl=0

The managedsoftwareupdate binary in this testing package is not signed with my Developer ID. You can still create a PPPC profile for testing using the adhoc signature:

$ codesign -dr - /usr/local/munki/managedsoftwareupdate 

Executable=/usr/local/munki/managedsoftwareupdate

# designated => cdhash H"1898eb298f4aae79674016bb0b2d8bd99c2664c7" or cdhash H"198e381e5928273992ca02b3893435968545abf3"

Or you may elect to sign it with a Developer ID of your own.

-Greg