Calling Softwareupdate from self service as root

[#1]

I'm no security expert, so I pose this question to all of you.

It seems to work well to have a self service item that runs
/System/Library/CoreServices/Software Update.app/Contents/MacOS/Software
Update. This just brings up the GUI softwareupdate.app. Since it's running
from self service, it runs as admin/root, which therefore does not require
admin credentials to install updates. This works for all users, admin or
not. We control the updates available though SUS and therefore control what
they can get.

Is this an acceptable and secure solution to software updates?

[bentoms]

We allow software updating through self service, but we run the command sudo softwareupdate -i -a.

We too have our own asus.. & this seems fine.

Regards,
Ben Toms
IT Support Analyst GREY Group
The Johnson Building, 77 Hatton Garden, London, EC1N 8JS
T: +44 (0) 20-3037-3819 |
Main: +44 (0) 20 3037 3000 | IT Helpdesk: +44 (0) 20 3037 3883

[tlarkin]

we also do it through self service. We are finding some connection
issues and it seems to take longer than just sending the commands itself
but it allows me to managed 1 parent SUS with 6 children SUS servers and
do it all through setting one server and forgetting about it while
letting self service allow the user to trigger updates with out being
admin.

Anything critical gets pushed out regardless

[rockpapergoat]

the relative security of this approach seems to be acceptable within the community. i can see where it may be possible to replace the softwareupdate binary or other components to do nefarious things, but you have bigger problems if someone can get that far in the first place.

you shouldn't need to call the app like you mentioned above or preface softwareupdate with "sudo" if you're running these from casper.

likewise, it may be better to look at using munki for such things. i prefer it to the self service method.

http://code.google.com/p/munki/

[#5]

I don't mind the command line approach, and do use that now. With policies associate with boot/login/logout/shutdown, I've had people shut down with (even when using notification) due to the extended times related to installing the software.
On Nov 12, 2010, at 10:50 AM, Nate St. Germain wrote:

Currently I force a logout or restart then "softwareupdate -i -a ; reboot". If they call it themselves, then they are more aware of what is happening. Also, for a lot of non-critical updates it would be nice to say "iTunes is available if you want it". This way, people could install approved updates from our SUS and I could still maintain my update schedule without having to randomly install desired updates for non-essential apple updates.

It appears the consensus is that as long as the binary is properly secured, it should be an acceptable method.

Thanks for the replies. Aaron

[#6]

Thanks for pointing this option out Aaron. I was looking for something like this.

Launching Software Update.app UI enables better UI dialogs and the "install after logging out the user" functionality. It also provides a progress bar to the end user. I really prefer that over the faceless CLI command.

However for me when I put "/System/Library/CoreServices/Software Update.app/Contents/MacOS/Software Update" in the "Run Command" field of the Advanced tab, the Software Update UI launches in the background behind the Self Service window. I am certain this will confuse/confound some users.

I have fixed this by changing the "Run Command" field to

osascript -e 'tell application "System Events" to set visible of process "Self Service" to false' && /System/Library/CoreServices/Software Update.app/Contents/MacOS/Software Update

Which hides Self Service before launching Software Update. The Software Update window will still be hidden by other windows if they are open, but it's an improvement.

If there are better solutions to this that I am missing I'd appreciate suggestions.

Armin

[peterleeman]

Thanks for the osascript. I wonder if there is a way to utilize "activate" to both launch...

/System/Library/CoreServices/Software Update.app/Contents/MacOS/Software Update

...and force it to the front. I have attempted to do this but the following do not work;

osascript -e 'tell application "Software Update" to activate' <- works but requires admin privileges.

osascript -e 'tell application "/System/Library/CoreServices/Software Update.app" to activate' <- syntax errors

Maybe this is not possible using osascript and will ultimately require a script?

Thanks

[jwojda]

Can someone point in the direction of what i'm doing wrong? I think the script is okay, because it's finding the updates, the problem is getting it to call the MAS for software updates... When I just paste the line into terminal MAS opens as expected...

Running script SWUJH.sh...
Script exit code: 0
Script result: available updates is Software Update Tool
Copyright 2002-2010 Apple
Software Update found the following new or updated software:
* OS X v10.8.2 Supplemental Update-1.0
OS X v10.8.2 Supplemental Update (1.0), 26712K [recommended] [restart]
there are updates available
updates need a restart
value of logged in user is jwojda..
as there is a logged in user checking whether ok to restart
0
User said YES to Updates
Checking for policies triggered by "runsoftwareupdate"...
Executing Policy Jamf Helper Trigger - Software Updates available...
Running command "/System/Library/CoreServices/Software Update.app/Contents/MacOS/Software Update"...
Result of command:
Submitting log