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.