Potential roadblocks with softwareupdate

Content Authoring
1

Hi all,

I was wondering if there might be any potential issues with, or any recommendations against, sending the login credentials of a securetoken account via secure parameters to run softwareupdate on a macOS machine.

We’ve been using MDM commands, but have found them somewhat unreliable, especially for machines running macOS Ventura or older. We’ve also found softwareupdate somewhat unreliable, but our idea is to leverage both and hopefully reach full coverage.

In cases where the MDM update commands seem to hang, we’ve had good success remoting into the machine, signing in to an account with a securetoken, and running softwareupdate -iaR. So, I’d like to mirror this with a fixlet that passes the necessary account credentials through secure parameters.

Does anyone have any words of wisdom against this? In all the discussions I’ve seen on patching macOS, I can’t recall anyone recommending this — I’m wondering if I’m missing something obviously inadvisable.

Thank you.

2

This is an issue of safe handling of passwords, and also proper handling of privileged accounts.

One shouldn’t have admin accounts where there’s a common account with a known-same-password on endpoints. This is what LAPS is for. (But many still do because reasons shhhhhhh.)

If you put the password inside the actionscript, it’s stored as cleartext inside BigFix, and appears as cleartext in the client log. And, depending on how you invoke softwareupdate, it may appear as a property in the ps list.

The safest way for this is to use a secure parameterized fixlet, wherein you enter the password in a field before invoking the fixlet. And you do this every time. And because of how secure fixlets work, you can only deploy this to static-enumerated machines, not by property or dynamic group membership.

BUT… secure fixlets are horridly underdocumented, and not supported in WebUI.

3

For the most part, we’ll be relying on MDM commands to keep our machines up-to-date, and the plan was to use softwareupdate to plug the holes left behind.

We’re currently implementing some LAPS-like software, but given the low volume, it should not be a problem to enter each password manually (although it will be annoying if the password rotates before the command reaches the machines…).

Secure parameters not being available in the webUI yet is a big annoyance, but there’ s just no way around that for now.

Can you expand on this? Which methods would be safe/unsafe?

4

I believe the safest way would be to use the -user prompt within an expect directive that supplies the password when prompted.

The other way is to echo the password value into softwareupdate with the --stdinpass option. This is easier, but you have that moment when the password is being echoed in cleartext through stdin.

5

Real confessions of BigFix: I use the --stdinpass method.

if (architecture of operating system = "arm64") 
 run bash -c "echo '{parameter "adminPw" of action}' | softwareupdate -iaR --force --user {parameter "theAdmin"} --stdinpass" 
else 
 run sudo -i softwareupdate -iaR --force 
endif
6

Thanks @atlauren , I ended up using the method you described.

If anyone else would like it, I shared the fixlet here: https://www.bigfix.me/fixlet/details/27345 . You can select if you want to --download or --install, reboot or not, and other options. So far it has been working well.

3 Likes
7

Nicely done!

Also, TIL sysadminctl -secureTokenStatus