Still no good way to restrict system updates?

[znilsson]

I know this has been a thing for a long time now, just wanted to see if anything had improved with regards to point upgrades like today's 10.11.5 update. We still can't set a Restricted Software record for this because it just uses Installer.app, correct? I mean we can't restrict that without restricting every valid package we have available.

And we've blocked software updates, so just assume our users are savvy enough to download the updater at home, put it on a USB stick and bring it in to their work Mac to install it. Or use Dropbox or whatever.

So with all that said, how do we completely block the install of the 10.11.5 combo updater? If we can't block the process, is there a way to identify the name of the package, i.e. OSXUpdCombo10.11.5.pkg, and delete it before it can be run? Like config profile style? Or is there another way to take care of it?

And finally, does anybody know if any of this will be addressed in Jamf's upcoming patch management goodies?

[gregneagle]

To "block" Apple updates, you point your clients at an Apple Software Update Server that you control.

You can use OS X Server and its Software Update Service, JAMF's NetSUS Appliance, or Reposado running on virtually any OS and hardware.

You'd then approve only those Apple updates you've tested and are ready/willing to support.

As for blocking manually downloaded OS updates, this would be a reason to not give your users admin rights.

If your users do have admin rights and do manually download and install such updates, and you can't block Installer.app, I think you are out of luck.

[znilsson]

@gregneagle Yeah, this is a relatively new Casper installation, we are still working on getting all the applications set up so that end users don't need admin access any more, but for right now a lot of them do. While we are planning on fixing that. and I do have a SU server set up to not show updates and there is a config profile set up to point all users to that SU server, there is still the potential issue of somebody grabbing the update from an outside source and putting it on their Mac manually.

"Out of luck" is what we seem to be. I can try blocking Installer.app, does anybody know if that will restrict software that is installed by Casper via Self Service, for example? Using the 10.11.5 combo updater as an example, if I block Installer.app, that will prevent the 10.11.5 installer from running, but will it also prevent the installer from running if it's in Self Service?

To put it another way, when you install a standard Apple package via Self Service, is it running Installer.app or is it doing it some other way, like via command line? Because if it still allows the installation of software via self service, then blocking Installer.app would be feasible.

[gachowski]

Zak,

Here is another way to look at this issue.. why do you want to blocking security updates? Almost every Apple update in the past few years has had security improvement.

While years ago blocking Apple updates could have of made some sense, I think in this day and and age running the most current secure OS is the most important step of having a secure Mac.

C

[znilsson]

@gachowski Because we're in a production environment and the update hasn't been tested yet. You don't ever push new OS updates straight out to users without testing it first. We are planning on making the update available to everybody, but not until we've vetted it to make sure it's not going to break any of the software we're using.

[bentoms]

You could try & ignore the update via the softwareupdate binary. (I forget the syntax, but it's in the man page).

That should hide it from MAS updates too.

But will not stop someone using a manually downloaded update.

[gachowski]

@znilsson Right I understand your point of view but .. but now I can attack every Mac in the world that is not running X.10.11.5 with known exploits.

What software is left theses days that can't survive a software update? Also usually Apple has 4 to 5 beta's that can be tested...

We test in the beta program to be ready for the public release ... is it perfect no, but no upgrade is perfect and I think the risk to have insecure machines is much more than the risk of a having an app break... it's the same amount of work testing in the beta program or testing after release.. also I am not even sure that we are testing/vetting correctly...

I have asked a few times in Jamf Nation if anybody has an automated process or tools to test their build and nobody responded.

I also disagree that " you don't ever push new OS updates without testing"... I think there have been a few security updates over the past year or two were Apple didn't even provide beta testing.

C

[znilsson]

@gachowski Are you serious? OK, the decision to test system updates before pushing them out is non-negotiable in our environment. Also, security updates are not the same thing as OS updates.

Now that we've cleared that up, does anybody know if restricting Installer.app via software restriction will also prevent apps from being installed via Self Service?

[gachowski]

I am ... and that is my point when was the last OS update that didn't include security updates ?

C

[znilsson]

@gachowski OK, thanks for your input, moving on.

[davidacland]

Hi @znilsson

I think you're right, blocking installer.app will cause more trouble than it's worth. In environments where we want to have people "hold back" from grabbing the latest, greatest and unproven updates like 10.11.5, we use a SUS server and remove their admin rights.

If your users are admins, and are determined to get their hands on 10.11.5, there's not going to be much you can do to stop them I'm afraid. At least not without hacking the OS to bits.

[cpdecker]

I know in Windows you can block files from executing bashed on the file hash. Is there any possibility Casper could implement something like this? Is it even possible in OS X? Could an AV client do it perhaps?

[znilsson]

@davidacland Yeah I've been running some tests with self service, and on smaller packages it's hard to tell because it goes so quickly, but on larger packages I do see installer come up in activity monitor, in addition to installd, so I think that answers that question. And I agree with you, probably more trouble than it's worth to block it.

@cpdecker Yeah I keep hearing how Casper is going to have some cool patch management features, I'm hoping something like that might be one of them.