Update on using Munki to upgrade macOS on Apple Silicon

143 views
Skip to first unread message

Greg Neagle

unread,
Aug 8, 2022, 2:41:59 PM8/8/22
to munki-dev
Original discussion here:

The two possible approaches discussed were:

1) Similar to the way Munki/MSC supports authenticated restarts on FileVault-encrypted volumes, MSC could prompt for credentials and securely store them, then Munki could securely retrieve them for use with the `startosinstall` tool. 

2) Similar to the way Munki now opens the System Preferences Software Update pane for Apple software updates; Munki could just open the “Install macOS Foo.app” and allow the user to do a self-install via that app. For users who are Volume Owners, but do not have Administrator rights, there are two possible approaches: 
a) Temporarily add the user to the admin group; configure a signal that causes the user to be removed from the admin group when a process exits. This might not be desirable in some orgs because the user does have admin rights for a time. 
b) Launch the “Install macOS Foo.app” as root. This avoids having to promote the user to admin temporarily, but there may be other risks or issues triggered by running a GUI app as root within a “normal” user session. 

I originally started work on approach #1, but I’m rapidly deciding it’s just too complex to implement in a way that satisfies me. In order to maintain security around the user credentials, the demon that stores the user credentials must also be the daemon that runs `startosinstall`. That, in turn, triggers two challenges: 1) Since the existing code to run `startosinstall` does so via a launchd job, and there’s no way to securely provide a user password to that launchd job, we’d have to instead use subprocess. Now the code is further forked between Intel and Apple silicon :-(.  2) The authrestartd daemon that handles authenticated restarts takes commands and sends short replies. A daemon that runs `startosinstall` would send progress data over a period of several minutes or more. I’m not exactly sure how to manage all that with the existing socket code I have.

I could avoid these complexities if instead the daemon stored the credentials and then mananagedsoftwareupdate could just retrieve those credentials for use with `startosinstall` but I cannot think of a way to do that without opening a huge security hole. (if managedsoftwareupdate can successfully retrieve credentials, then anything can

So right now I’m leaning quite hard towards putting approach #1 on the shelf and focussing my efforts on approach #2. Besides the possible issues around temporarily promoting users to admin, a couple of other issues occur to me:

  - Admins would have to remove anyhing preventing the launch of “Install macOS Foo.app” they might have in place (we have this — to force people to use Managed Software Center to trigger the upgrade)

  - This would allow admin users to upgrade without Munki being involved at all. If additional items need to be installed or updated after a major OS upgrade, Munki would not know to do this on the next boot — instead it would happen some time later when Munki did its automatic background run. This might result in poor user experience, depending on how vital those updates are.

As always, I’d appreciate any thoughts or ideas anyone has on this topic and the hard choices to be made.

-Greg

Eric Holtam

unread,
Aug 8, 2022, 3:20:16 PM8/8/22
to munki-dev
My initial opinion would be the route option 1. That mimics the model Apple uses for their own Software Update mechanism, as proprietary as it may be. It would also allow the linking/smarts of Munki to continue to be used for requires/update_fors and such.

In regard to keeping a password securely, I have no experience with it so it may be an amateur question, but can a custom Keychain be created with the password stored inside where only munki tools are listed in the access control so only those processes have access to use it? Granted the password for unlocking the keychain would need to be accessible or generate-able which lowers that security, especially with code being open source and could be reverse-engineered. I also don't know how much iteration Apple has done with the Keychain framework over the years so that may be adding another layer of code compatibility complexity going forward. Just my $.02.

Rick Heil

unread,
Aug 8, 2022, 3:26:56 PM8/8/22
to munk...@googlegroups.com
Firstly - thank you for your continued work on this problem. It is deeply appreciated.

For 1, is there a reason to store the credentials longer term other than not prompting users every update? Essentially, is it worth the tradeoff of asking users for credentials more often to avoid the issues that come from storing them in the first place? While doing anything around softwareupdate is full of corner cases and weird sharp edges, I would imagine that wrapping startosinstall will be as stable as you can get on the Apple side of things.

For 2a, would an admin-configurable key to put the user into a mode similar to "Aggressive Mode" where only the Install macOS Foo.app and MSC are "available" solve for the question of trying to ensure users who shouldn't have admin rights can't alter/update other things in the mean time?

For 2b, it would be interesting to do some testing, but we've seen in the past that Apple isn't really interested in fixing issues with their installers that may come up and break workflows (e.g. the instalinstallmacos.py workaround for the postinstall script bug). That makes me wonder if future maintenance would be more painful than pursuing the other options.

-R

--
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/AB09865D-AD87-473F-A890-CA03F0DAC981%40mac.com.

Greg Neagle

unread,
Aug 8, 2022, 4:03:16 PM8/8/22
to munki-dev

On Aug 8, 2022, at 12:20 PM, Eric Holtam <eho...@gmail.com> wrote:

My initial opinion would be the route option 1. That mimics the model Apple uses for their own Software Update mechanism, as proprietary as it may be. It would also allow the linking/smarts of Munki to continue to be used for requires/update_fors and such.

I must not have been clear, or perhaps I’m misunderstanding your reply.

I do not know how to implement approach #1 in a way that meets my standards for security and end-user experience. Given enough time and effort and assistance, I might be able to figure something out. But I’m not convinced that would happen in the available time frame. And it would be a large chunk of new, untested code.

-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.

Greg Neagle

unread,
Aug 8, 2022, 4:09:18 PM8/8/22
to munki-dev

On Aug 8, 2022, at 12:24 PM, Rick Heil <rick...@samsara.com> wrote:

Firstly - thank you for your continued work on this problem. It is deeply appreciated.

For 1, is there a reason to store the credentials longer term other than not prompting users every update? Essentially, is it worth the tradeoff of asking users for credentials more often to avoid the issues that come from storing them in the first place? While doing anything around softwareupdate is full of corner cases and weird sharp edges, I would imagine that wrapping startosinstall will be as stable as you can get on the Apple side of things.

As with authorized restarts, the credentials would not be stored long-term. They don’t survive restarts. MSC would ask for them when asking to install the upgrade, they’d be stored by an equivalent to the current/existing authrestartd, and managedsoftwareupdate would then tell this new daemon to handle the upgrade.

For 2a, would an admin-configurable key to put the user into a mode similar to "Aggressive Mode" where only the Install macOS Foo.app and MSC are "available" solve for the question of trying to ensure users who shouldn't have admin rights can't alter/update other things in the mean time?

Not really. Once we switch away from Managed Software Center, we lose a lot of control over what the user is allowed to do. You can make it annoying to try to access other things, but cannot prevent it.


For 2b, it would be interesting to do some testing, but we've seen in the past that Apple isn't really interested in fixing issues with their installers that may come up and break workflows (e.g. the instalinstallmacos.py workaround for the postinstall script bug). That makes me wonder if future maintenance would be more painful than pursuing the other options.

I really think that if we go the route of launching Install macOS Foo.app, that we must do it as Apple intends, as an admin who is a volume owner.

precu...@gmail.com

unread,
Aug 10, 2022, 3:18:07 PM8/10/22
to munki-dev
Not that this helps you in the discussion but from my perspective one the greatest things about munki is that it does what it Does largely in the way that Apple intends right down to the look and feel of how that transpires. So I would agree that it is best to move forward in the way that Apple intends - both as a practical matter but also for the ease of user adoption and usage that this will steer us toward.
As far as I can discern, what Apple intends is that users be directly involved in system updates - whether we as admins like it or not...

Steve Major

unread,
Aug 11, 2022, 7:56:00 AM8/11/22
to munki-dev
That is all well and good when users are assigned individual computers, which is true for us.  However, what is also true for us is we're an Arts & Music campus and have several computing labs totaling 400+ Macs.  Apple seems to think it is okay for us Admins to "touch" every one of those systems in order to do system updates.  That's pure insanity and will probably drive several of those labs to Windows based machines.

Gregory Neagle

unread,
Aug 11, 2022, 10:08:29 AM8/11/22
to munk...@googlegroups.com
In this scenario, Apple wants you to use MDM to handle the OS upgrade. There are also tools like Graham Pugh’s eraseinstall, which despite the name, doesn’t have to erase. 

Sent from my iPhone

On Aug 11, 2022, at 4:56 AM, Steve Major <maj...@gmail.com> wrote:

That is all well and good when users are assigned individual computers, which is true for us.  However, what is also true for us is we're an Arts & Music campus and have several computing labs totaling 400+ Macs.  Apple seems to think it is okay for us Admins to "touch" every one of those systems in order to do system updates.  That's pure insanity and will probably drive several of those labs to Windows based machines.


On Wednesday, August 10, 2022 at 3:18:07 PM UTC-4 precu... wrote:
Not that this helps you in the discussion but from my perspective one the greatest things about munki is that it does what it Does largely in the way that Apple intends right down to the look and feel of how that transpires. So I would agree that it is best to move forward in the way that Apple intends - both as a practical matter but also for the ease of user adoption and usage that this will steer us toward.
As far as I can discern, what Apple intends is that users be directly involved in system updates - whether we as admins like it or not...

--
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.

Steve Major

unread,
Aug 14, 2022, 9:33:31 AM8/14/22
to munki-dev
Greg, thank you! I was unaware of Graham Pugh's tool. I'll look into this!
Reply all
Reply to author
Forward
0 new messages