Munki and Ventura - early notes
128 views
Skip to first unread message
Greg Neagle
Jun 14, 2022, 12:25:26 PM6/14/22
to munki-dev, 'Gregory Neagle' via munki-discuss
TL;DR:
It looks like Munki is going to need a signed binary and an MDM-delivered PPPC/TCC config profile to continue working properly on macOS Ventura.
Details
Last week was Apple’s Worldwide Developer Conference 2022. Among others things announced and introduced was macOS Ventura, or macOS 13.
As is not unusual for macOS releases, this release contains changes that may affect the functionality of Munki (and other similar tools).
Two changes in particular have the potential to affect Munki functionality (and there may be more, but these were discussed in WWDC sessions):
1) A new “Login Items” section in the System Settings (formerly System Preferences) application. This settings view allows users to easily disable Login Items, Launch Agents, and Launch Daemons. Users require admin rights to disable Launch Daemons. Since Munki makes heavy use of Launch Agents and Launch Daemons, a user could easily and trivially disable Munki from running. At present there appear to be no management options/tools to prevent this. File Feedback with Apple about how important managing would be to your organization.
2) A new privacy protection around “App Management”. This prevents software from changing or removing items from /Applications without user approval. Its affect on Munki can be subtle and easy to miss in simple testing.
On a fresh Ventura install, Munki can install software as it does under Monterey and earlier. But when updating or removing software, it may be blocked from making changes to apps in /Applications. Again, this can be easy to miss in testing. It’s common to have Terminal set for Full Disk Access, and also common for ssh to have Full Disk Access (via /usr/libexec/sshd-keychain-wrapper). Running managedsoftwareupdate via either of these methods will allow Munki to update and/or remove app bundles in /Applications. But Munki operations triggered via launchd jobs will fail to update or remove app bundles in /Applications.
Apple has not yet provided supported/documented management controls to affect or manage this behavior. It _appears_ at present that managing/allowing Full Disk Access will allow processes to update or remove app bundles in /Applications, but I’d really like to see official Apple documentation and recommendations on this topic.
It is possible to “pre-approve” binaries or apps for Full Disk Access via an MDM-delivered profile, but the binary or app must be signed. In the case of Munki, this will most likely have to take the form of a signed binary wrapper/launcher that calls munki-python and the needed Munki scripted tools.
But this surfaces another problem. I don’t want to sign this binary with my personal Apple Developer ID and then distribute that as part of the official Munki release. And (while I have not asked) I suspect my employer doesn’t want to publicly distribute a Munki binary signed by them. While orgs using Munki could sign the tool themselves (and some will), many orgs will find this hard to do. I’d like to find some way to have a “Munki Project” or “Mac Admins” identity for a publicly-distributed release of the Munki tools. If anyone has useful thoughts, ideas, or information on how that might happen, I’d greatly appreciate it.
-Greg
It looks like Munki is going to need a signed binary and an MDM-delivered PPPC/TCC config profile to continue working properly on macOS Ventura.
Details
Last week was Apple’s Worldwide Developer Conference 2022. Among others things announced and introduced was macOS Ventura, or macOS 13.
As is not unusual for macOS releases, this release contains changes that may affect the functionality of Munki (and other similar tools).
Two changes in particular have the potential to affect Munki functionality (and there may be more, but these were discussed in WWDC sessions):
1) A new “Login Items” section in the System Settings (formerly System Preferences) application. This settings view allows users to easily disable Login Items, Launch Agents, and Launch Daemons. Users require admin rights to disable Launch Daemons. Since Munki makes heavy use of Launch Agents and Launch Daemons, a user could easily and trivially disable Munki from running. At present there appear to be no management options/tools to prevent this. File Feedback with Apple about how important managing would be to your organization.
2) A new privacy protection around “App Management”. This prevents software from changing or removing items from /Applications without user approval. Its affect on Munki can be subtle and easy to miss in simple testing.
On a fresh Ventura install, Munki can install software as it does under Monterey and earlier. But when updating or removing software, it may be blocked from making changes to apps in /Applications. Again, this can be easy to miss in testing. It’s common to have Terminal set for Full Disk Access, and also common for ssh to have Full Disk Access (via /usr/libexec/sshd-keychain-wrapper). Running managedsoftwareupdate via either of these methods will allow Munki to update and/or remove app bundles in /Applications. But Munki operations triggered via launchd jobs will fail to update or remove app bundles in /Applications.
Apple has not yet provided supported/documented management controls to affect or manage this behavior. It _appears_ at present that managing/allowing Full Disk Access will allow processes to update or remove app bundles in /Applications, but I’d really like to see official Apple documentation and recommendations on this topic.
It is possible to “pre-approve” binaries or apps for Full Disk Access via an MDM-delivered profile, but the binary or app must be signed. In the case of Munki, this will most likely have to take the form of a signed binary wrapper/launcher that calls munki-python and the needed Munki scripted tools.
But this surfaces another problem. I don’t want to sign this binary with my personal Apple Developer ID and then distribute that as part of the official Munki release. And (while I have not asked) I suspect my employer doesn’t want to publicly distribute a Munki binary signed by them. While orgs using Munki could sign the tool themselves (and some will), many orgs will find this hard to do. I’d like to find some way to have a “Munki Project” or “Mac Admins” identity for a publicly-distributed release of the Munki tools. If anyone has useful thoughts, ideas, or information on how that might happen, I’d greatly appreciate it.
-Greg
Ben Toms
Jun 14, 2022, 12:36:31 PM6/14/22
to munki-...@googlegroups.com, munki-dev
One caveat with the signing, the PPPCP might need updating every time Python is updated for Munki.
We found this:
- identifier:/usr/local/munki/Python.framework/Versions/3.9/bin/python3.9
- type: path
So might be something that needs investigation too.
But as things are, the above link is what folks have needed with the signed Munki we deploy.
--
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/BBA2DCBF-2D89-4D32-856F-A892A42C0A48%40mac.com.
Regards,
Ben
Greg Neagle
Jun 14, 2022, 1:13:40 PM6/14/22
to munki-dev, munki-...@googlegroups.com
I’m actually not suggesting signing munki-python.
I’m suggesting that “managedsoftwareupdate” become a fairly simple signed C/Obj-C binary that essentially calls `munki-python msu.py [managedsoftwareupdate options]`.
But in either case, if the signing is done with a “stable” signing identifier, changes in the binary should not trigger the need for an updated PPPC/TCC profile.
-Greg
--
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/CADjniupUGfOd8HmEtCHT3WyONZ9iMRa4EDvPEXKdWd8PhhMRkA%40mail.gmail.com.
Ben Toms
Jun 14, 2022, 1:58:50 PM6/14/22
to munki-...@googlegroups.com, munki-dev
Sure, it’s worth a try.
We did see where we are manually triggering Munki with Jamf Pro, that despite the Jamf Pro binaries having a PPPCP.. we needed a separate PPPCP for python.. obvs to do with the calling process somewhere and changes will change results.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/63BC7692-C3CD-4163-AD30-88B0E3752975%40mac.com.
Regards,
Ben
Greg Neagle
Jul 7, 2022, 6:55:44 PM7/7/22
to munki-dev, 'Gregory Neagle' via munki-discuss
Update here.
I have a compiled binary wrapper for managedsoftwareupdate written in C that can be signed with a Developer ID or just left ad-hoc signed; once it’s “stable” I bet it will essentially never change.
But I cannot test it with Ventura b3 — because I cannot get Munki to fail to make changes to application bundles.
Here’s how I’ve been testing:
1) Manually install Google Chrome 102.x (a few versions out of date)
2) Launch Google Chome (apparently some of the protections don't kick in until an app has been launched at least once)
3) Wait for Munki to attempt to update Google Chrome (can't run managedsoftwareupdate manually as it would then inherit the permissions of Terminal.app or ssh-keychain-wrapper)
In my testing under Ventura b6, stock Munki (unsigned; no PPPC/TCC profile applied) has no issues updating Google Chrome.
If I can’t replicate what’s changed in Ventura, I can really test anything designed to adapt to these changes.
-Greg
I have a compiled binary wrapper for managedsoftwareupdate written in C that can be signed with a Developer ID or just left ad-hoc signed; once it’s “stable” I bet it will essentially never change.
But I cannot test it with Ventura b3 — because I cannot get Munki to fail to make changes to application bundles.
Here’s how I’ve been testing:
1) Manually install Google Chrome 102.x (a few versions out of date)
2) Launch Google Chome (apparently some of the protections don't kick in until an app has been launched at least once)
3) Wait for Munki to attempt to update Google Chrome (can't run managedsoftwareupdate manually as it would then inherit the permissions of Terminal.app or ssh-keychain-wrapper)
In my testing under Ventura b6, stock Munki (unsigned; no PPPC/TCC profile applied) has no issues updating Google Chrome.
If I can’t replicate what’s changed in Ventura, I can really test anything designed to adapt to these changes.
-Greg
> --
> 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/BBA2DCBF-2D89-4D32-856F-A892A42C0A48%40mac.com.
> 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.
Greg Neagle
Jul 7, 2022, 7:19:25 PM7/7/22
to munki-...@googlegroups.com, munki-dev
"In my testing under Ventura b6” should be "In my testing under Ventura b3”
-Greg
> You received this message because you are subscribed to the Google Groups "munki-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/0B0CA4FC-4555-4B60-809F-CA3D760AB0D2%40mac.com.
-Greg
> To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/0B0CA4FC-4555-4B60-809F-CA3D760AB0D2%40mac.com.
Steve Maser
Jul 7, 2022, 7:38:34 PM7/7/22
to munki-...@googlegroups.com
My story:
With b1, I had a significant number of apps that would not update with munki (I can’t remember the number now but it was in the low double-digits — not every single application failed to update.)
When b2 came out, I did an EACS install and clean installed our 300+ apps and as the weeks after that went by ended up with a much smaller number of apps (only 4) that would not update (most updated — including ones that would not update under b1. Microsoft Edge was one that was a problem in b1 *and* b2 (but, frustratingly, not all the time, but often enough on multiple computers).
When b3 came out, I updated from b2 to b3 — and those 4 app updates installed without issue. Though, admittedly, I did not try relaunching those 4 apps *again* after the update to b3 — I just ran munki to see if the 4 apps would update — and they did.
I then EACS’ed b3 today and installed the 300+ apps we deploy here.. We have 18 specific apps in “testing”, so I launched the older “production” versions of those 18 after the EACS, switched the catalogs to testing — and ran munki and — 17 of the 18 apps updated (I was honestly disappointed one was left…and it was *not* Edge...)
We made no changes to anything munki-related here — it’s exactly the same stock munki version/configuration we’ve been using since your last public release, but this one update has the same “Error -1” I would see in /var/log/install.log that the other apps generated when they failed to install:
2022-07-07 19:21:59-04 ultron shove[3049]: Error relinking file (primary): /Library/InstallerSandboxes/.PKInstallSandboxManager/DE10B3B0-25AB-4BCE-BC0F-FDADC81D7250.activeSandbox/Root/Applications/Resolume Wire/Wire.app/Contents/_CodeSignature/CodeResources to /Applications/Resolume Wire/Wire.app/Contents/_CodeSignature/CodeResources, error = 1
So we don’t know if Apple is loosening the app update restrictions now for specific applications as they get reported or what. I’m hoping they post something in future developer notes to indicate what the plans are.
All that said in a round-about, long-winded way: I’m suggesting that if you held on to the full installers of b1 and b2 (Mr. Macintosh’s web site still has links if they are still valid?) — you might be able to replicate the initial issue with b1 (or b2?) to see if your munki change works there? From my experience, b1 was the most problematic, b2 got better and (so far) b3 is even better.
- Steve
> You received this message because you are subscribed to the Google Groups "munki-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/0B0CA4FC-4555-4B60-809F-CA3D760AB0D2%40mac.com.
With b1, I had a significant number of apps that would not update with munki (I can’t remember the number now but it was in the low double-digits — not every single application failed to update.)
When b2 came out, I did an EACS install and clean installed our 300+ apps and as the weeks after that went by ended up with a much smaller number of apps (only 4) that would not update (most updated — including ones that would not update under b1. Microsoft Edge was one that was a problem in b1 *and* b2 (but, frustratingly, not all the time, but often enough on multiple computers).
When b3 came out, I updated from b2 to b3 — and those 4 app updates installed without issue. Though, admittedly, I did not try relaunching those 4 apps *again* after the update to b3 — I just ran munki to see if the 4 apps would update — and they did.
I then EACS’ed b3 today and installed the 300+ apps we deploy here.. We have 18 specific apps in “testing”, so I launched the older “production” versions of those 18 after the EACS, switched the catalogs to testing — and ran munki and — 17 of the 18 apps updated (I was honestly disappointed one was left…and it was *not* Edge...)
We made no changes to anything munki-related here — it’s exactly the same stock munki version/configuration we’ve been using since your last public release, but this one update has the same “Error -1” I would see in /var/log/install.log that the other apps generated when they failed to install:
2022-07-07 19:21:59-04 ultron shove[3049]: Error relinking file (primary): /Library/InstallerSandboxes/.PKInstallSandboxManager/DE10B3B0-25AB-4BCE-BC0F-FDADC81D7250.activeSandbox/Root/Applications/Resolume Wire/Wire.app/Contents/_CodeSignature/CodeResources to /Applications/Resolume Wire/Wire.app/Contents/_CodeSignature/CodeResources, error = 1
So we don’t know if Apple is loosening the app update restrictions now for specific applications as they get reported or what. I’m hoping they post something in future developer notes to indicate what the plans are.
All that said in a round-about, long-winded way: I’m suggesting that if you held on to the full installers of b1 and b2 (Mr. Macintosh’s web site still has links if they are still valid?) — you might be able to replicate the initial issue with b1 (or b2?) to see if your munki change works there? From my experience, b1 was the most problematic, b2 got better and (so far) b3 is even better.
- Steve
> To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/0B0CA4FC-4555-4B60-809F-CA3D760AB0D2%40mac.com.
Greg Neagle
Jul 7, 2022, 7:42:02 PM7/7/22
to 'Gregory Neagle' via munki-discuss
I don’t think it’s worth my effort to try to reinstall b1 or b2 and test there. Even if I can successfully replicate the blocking of app bundle updates there, and also successfully test a work-arounf/adaptation, it tells me nothing at all about what the behavior will be in b4 and later.
-Greg
> To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/DA31C653-AF12-41EB-9CA4-BB98926E0413%40umich.edu.
-Greg
Steve Maser
Jul 7, 2022, 7:44:05 PM7/7/22
to munki-...@googlegroups.com
Agreed. I’m hoping Apple will be a bit more forthcoming about why this works sometimes, but not others.
- Steve
> To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/8D5D005B-2A2F-4F7A-8BA8-9C263D06E64E%40mac.com.
- Steve
Reply all
Reply to author
Forward
0 new messages