xProtect II, The Sequel: Now More xProtect-ier

By now, if you've not heard of Apple's hidden xProtect mechanism, you're probably not a SysAdmin: it's Apple's previously unknown mechanism to lock various aspects of how your OS behaves, mostly by enforcing minimum software requirements. Mostly these requirements seem to be restricted to items like Flash and Java but, in truth, Apple can add or subtract to their xProtect mechanism at will.

Unless you stop them. And, if you're a SysAdmin, locking down their mechanism is something you should consider.

With OSX 10.8.4, some of the the ground rules have changed:

1) The previous scripts that we've used to fix the issue (based partially on work by the formidable Greg Neagle and others) no longer work. Apple engineers —lovely people that they are — changed the xProtect meta plist "key" from "JavaWebComponentVersionMinimum" to "MinimumPlugInBundleVersion". Thanks, Apple.

2) A new executable, plist and launchD item have been included into the xProtect mechanism: xprotectupdater-init. This means now that you have two, not one, executables and their cruft to manage, lock or delete in order to stop Apple from wreaking havoc on your network.


What are the files and processes and where are they located?

The previously known files are located at:
/usr/libexec/XProtectUpdater
/System/Library/LaunchDaemons/com.apple.xprotectupdater.plist

The new files are located, similarly at:
/usr/libexec/XProtectUpdaterInit
/System/Library/LaunchDaemons/com.apple.xprotectupdaterinit.plist

The new launchD item is: 

sh-3.2# launchctl list | grep xprotect
- 0 com.apple.xprotectupdater-init

A previously known file that's now changed formatting is located at:
/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist


Good times.


What to do about it?

In my book, on an enterprise network, the SysAdmin and not Apple should be in control of software versioning. Which means it's my responsibility to fix this stuff. It's also important to note that even though we've been running a previous xProtect fix, the mechanism GOT REINSTALLED with the OSX 10.8.4 combo updater.

Which means, moving forward, you should either expect to re-run this script each and every time you update your Mac OS or, perhaps, create some kind of LaunchD item which is always running and looks for these processes and kills them.

Our method: doesn't delete the files, we unload them and then either move them or rename them so we can have access to them later if we so desire. Here's the script I put together yesterday that does the job on a one-time basis for us. We're big on logging here (as you'll see) but you can use whatever stdout you prefer.