Macjutsu / super

S.U.P.E.R.M.A.N. optimizes the macOS software update experience.
Apache License 2.0
627 stars 84 forks source link

Pass LAPS password as an authentication option #154

Closed jshirle2 closed 1 year ago

jshirle2 commented 1 year ago

We use EasyLAPS in our environment and for us to use Super on Apple Silicon we will need LAPS support. Could we get the ability to pass an EA ID to use for the password in Super? Thinking there would be a script option to enable LAPS support, and then another one to define where that password would come from (either EA ID or maybe support for JAMF LAPS in the future).

Thanks for all the work you do!

Macjutsu commented 1 year ago

One could do this but it would fundamentally break the entire security model for your LAPS implementation.

Think about it... how does super find out the local computer's LAPS password? In the example you gave, super would be reading from the Jamf API. For this to work you'd have to give super a Jamf API credential (which itself has no automated method to rotate/change) allowing it to read every single LAPS password for every single computer.

Congratulations, not only did you just undermine the entire point of LAPS (the Jamf API credential used by super cannot be changed automatically), you actually created an even worse security vulnerability. This is because super had to save that Jamf API credential to the local System keychain for future use. Every local administrator can read the System keychain. Thus, you just programmatically stored a Jamf API credential on every computer allowing any local administrator to find out the LAPS password for every Jamf-managed computer.

In other words, until Jamf allows for a limited per-computer authentication method to access the Jamf Pro API, giving super the ability to read anything from your Jamf Pro database is fundamentally insecure.

staze commented 1 year ago

Thanks for the response @Macjutsu. Guess I'm curious the alternative. A service account would require being granted volume ownership and cryptouser, which means it would show up on FV unlock, and now you've got a shared account across all machines with the same username and password. It seems like LAPS is the lesser of two evils here... (which, sadly, seems like a lot of what we do)... =/

Macjutsu commented 1 year ago

@staze Incorrect. Assuming the default settings, the super service account password is randomized on each computer, similar to the FileVault recovery key. https://github.com/Macjutsu/super/wiki/Apple-Silicon-Local-Credentials#local-super-service-account-details

Now the creation of a local super service account via your LDAP account is technically interesting... In fact, that is already an open issue that I do plan on evaluating in the future: https://github.com/Macjutsu/super/issues/86

FWIW... the new super v4 --auth-ask-user-to-save-password option is currently, and will likely always be, the safest, most reliable, and performant authentication option.

staze commented 1 year ago

Thanks @Macjutsu. I guess I'm just not sure here. Our goal is to be able to update unattended machines, so you can't prompt for credentials in that case. Our erase-install process, or self service upgrade processes also grab the laps credentials for running those processes.

It seems, if you ask me, like we have to work around Apple's "broken" update processes to get things to work, and asking that something be implemented in super to support either in our case EasyLAPS, or macOSLAPS, and letting the jamf/macOS admins to make that call on if they're comfortable granting those permissions, is reasonable.

The service account showing up on filevault login will sadly annoy/freak out many of our users who already think they "own" the devices provided to them by the institution. =/ So leveraging the existing LAPS enabled account for this, as mentioned, seems like (to use the phrase again) the lesser evil. =/

staze commented 1 year ago

might be honestly barking up the wrong tree on this... while I think using the existing laps account is the way to go for unattended computers, the reality is Apple just needs to make updates more reliable so that unattended machines can get unattended installs, which isn't really Super's target audience.