+10After the last few Java updates, and now Adobe Flash, I'm wondering what others out there are doing to manage XProtect on there managed machines.
I'm all for protecting Macs against malware and security threats, but it's now affecting enterprises who rely on those services for business continuity. What are people doing outside of just patching the software. There's got to be a better way than trying to keep up with Apple and their whim to update XProtect without telling anyone first.
+17Xprotect is probably great for home users.
I (now) treat it like software update & will keep it disabled and push patches after we test them. I can't afford for Apple to disable Java, especially when there is no new update available - even for a day.
It's a shame Apple doesn't give some visibility to OSX Admins. Microsoft has a security mailing list that if new patches are released, they email me to let me know (I got one for Flash yesterday, so it's not even just their products). What Apple is trying to do is great - I just don't like the secretive/back door way they try to do it.
I am grateful for places like OSX Enterprise and JAMFNation to keep me updated versus monitoring a plist.
+10We're not managing Xprotect, just pushing the updates out as soon as we can. With testing we've been on about a 48 hour lag to get these updates patched. The Windows side of the business is well behind that.
+6Give this a read...
http://managingosx.wordpress.com/2013/02/01/more-thoughts-on-xprotect-updater/
That's a good article by Greg Neagle. However we're not managing it at all. We have greater priorities right now than managing Xprotect.
+19yeah, I wish the macops.ca article about how to monitor the xprotect plist file for changes was still up.
With apple killing everything but the latest version of flash today, I'm starting to think managing xprotect might be a good idea . . . . .
+5We've disabled the thing. Not ideal, but hard to justify not allowing our users to use VPN or Flash.
While shoving out updates is great in theory, we have some old systems that aren't compatible with Java 7. Fortunately, there are upgrades going on, so we should be able to go to 7 soon, but not today.
+13Although it's probably not best practice to deny Apple access to manage their precious xprotect.meta.plist file, we too are stuck at the mercy of having to run Java 6 for client system compatibility. therefore, I've decided that, until I can control xprotect's entries individually, I am going to remove it completely. Ah, but the issue is that if you remove it, or edit the file, on next reboot, Apple "fixes" it to the way they think it should be.
So a coworker found a work-around: If you remove the file and replace it with a folder, on reboot, the OS can't fix it. Alas, Apple can't control xprotect!
You can do this manually, of course, but here's what I wrote:
#!/bin/sh
### this first line simply removes the xprotect file
rm -R /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist
### this next line simply creats a folder in it's place. The folder has the same name of the file
mkdir /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist
### with this in place, the OS can't overwrite their precious xprotect file, saving me headaches!Do this at your own risk, of course, but for now, it's working for me.
+19I was just about to make a pitch to our corporate security folks about disabling xprotect as it's causing significant issues for the production staff that rely on vendor web site java applets.
Not a big deal to loose Apple's auto blacklisting of plug-ins, BUT, if we disable the 'automatic update safe downloads list' then I suppose we are also going to loose the desirable functionality of Apple identifying and blocking actual malware (OSX.OpinionSpy, MacDefender). Right? I've not seen that aspect of this mentioned yet.
So what to do? It appears that the xprotect.meta.plist is the plugin blacklist, and the xprotect.plist has the malware definitions. Maybe we leave the auto update turned on (allowing Apple to ID and block malware), edit the xprotect.meta.plist to allow plug-in versioning we desire, and then add that edited plist to a daily install policy...?
Opinions?
I've got a couple of scripts for managing XProtect. One is for managing its ability to block the Java browser plug-in and the other manages its ability to block Adobe Flash.
I've got posts on them here:
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
