Upgrading macOS on Apple silicon

[Greg Neagle]

As I’m sure you know, Munki does not currently support upgrading macOS on Apple silicon. This is because the `startosinstall` tool needs the credentials of a “Volume Owner” on Apple silicon, and Munki does not currently have access to those, or a way to request those credentials.

I’d like to get this issue resolved before macOS Ventura ships. Some possibilities:

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. This would be a fair amount of work to implement, but I’ve done it before with FileVault auth restarts, so I’m reasonably certain it can be done.

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.

In neither case would _unattended_ upgrades of macOS be possible; for that you’d need to look to your MDM vendor.

The second option would be (probably) easier to implement, and since we’re running the Install macOS Foo.app, more like what Apple expects and has tested, but for non-admin users has some potential security implications.

The first option of course has a different set of security implications, as we’re collecting and storing user credentials.

Would love thoughts, reactions, and additional ideas.

-Greg

[Dustin Davis]

I would prefer the second option. As you mentioned, it aligns with Apple’s expected use which will hopefully means it is less likely to break in a future OS update.

Our users are all admins, but I also think it would be reasonable to not address that problem directly with Munki. Orgs that have standard users could potentially use MDM or deploy their own method of temporarily elevating users. (But maybe I’m ignorant about managing a fleet of standard accounts)

Dustin

> On Jun 15, 2022, at 9:39 AM, 'Greg Neagle' via munki-dev <munk...@googlegroups.com> wrote:
>
> As I’m sure you know, Munki does not currently support upgrading macOS on Apple silicon. This is because the `startosinstall` tool needs the credentials of a “Volume Owner” on Apple silicon, and Munki does not currently have access to those, or a way to request those credentials.

> --
> 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/80C0A2D0-F6E8-4311-A0D1-05225A1D34FE%40mac.com.

[Gregory Neagle]

I’d think coordinating Munki and MDM to temporarily elevate users would be quite tricky. Better to do it all inside Munki.

Sent from my iPhone

> On Jun 15, 2022, at 12:40 PM, Dustin Davis <1dusti...@gmail.com> wrote:
>
> I would prefer the second option. As you mentioned, it aligns with Apple’s expected use which will hopefully means it is less likely to break in a future OS update.

> To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/F06360E9-5519-4EFE-9ECB-4C01774066CA%40gmail.com.

[Nixtar]

If 1 was implemented it would be nice if it could use a keychain entry to check for volume owner creds.

Similar to how https://github.com/joshua-d-miller/macOSLAPS handles secure token password resets.

Alternatively a script to retrieve the username and password instead of prompting the user would be interesting.

In our case we could utilise macOSLAPS -getPassword in the script to get the creds and return it to munki.

This could be a security issue however as it would allow admins to be lazy and hardcode creds in the script..

[bryanzak]

I would be ok with #2 and elevating the non-admins to admin for a period to allow them to run the installer.

I think it's the least fragile and maybe even the least insecure option? Most of my staff (education) probably wouldn't even realize that their credentials had been elevated.

[Nixtar]

This is admittedly an issue with our device management choices..

But my concern with #2 is that none of our users are volume owners as our MDM does not support bootstrap tokens.

So in our environment our only way currently to patch macOS on Apple Silicon devices is using the account created during Setup Assistant.

I was thinking about this more and with option 1 a neat way to inject credentials could be to expand the middleware system that's currently for manipulating web requests.

With the default ( no middleware returns a valid credential dictionary ) prompting the user for for volume admin creds.

Something like:
def process_volumeowner_credentials(creds):
   creds['username'] = "Username"

   creds['password'] = "Password!" # Hopefully something more elaborate/secure then this!
   return creds

[miawri]

FWIW, I think #1 feels neater and if any security concerns can be mitigated, it allows munki to continue to use the startosinstall as it does with Intel machines.  As you say, munki can already do FileVault authorised restarts so similar things already exist within it.

I imagine #2 would be quicker to implement but it would mean users will need to run through the installmacOS app gui which I would rather avoid.  We also use the BigSurBlocker tool to prevent 'unauthorised' administrative installs to ensure the installs are kicked off through MSC.  #2 would mean we would need to drop it.

MIke