XProtect on 10.9 Mavericks

I'm managing it, with regards to Java. This approach still appears to work in Mavericks:

http://derflounder.wordpress.com/2013/02/24/managing-java-browser-plug-in-settings-for-apples-xprotect-malware-protection/

As an alternative, the approach I've been using (MCX to manage the ManagedPluginPolicies key in com.apple.Safari.plist) is still working perfectly, but only in Casper 8.x (Casper 9 removes fully customizable MCX, but there's not really a suitable replacement). Further, it allows me to keep updating Xprotect so that most sites require the latest, most secure version of a plugin, while protecting the functionality of core business apps.

I most recently outlined it here, as it pertains to Java and NetConnect, but the same applies for other plugins:

https://jamfnation.jamfsoftware.com/discussion.html?id=8789

Rather than editing XProtect directly, it appears that XProtect is just reading the CFBundleVersion.

If you wish to use an older version of something, eg. Flash, then rewrite this value in the software package. So with version 12.0.0.38 installed, write the value to match XProtect. With the below settings, the flash version still works, whilst XProtect is still doing it's thing and the Flash Version page will report the correct installed version:

http://www.adobe.com/software/flash/about/

You have version 12,0,0,38 installed

Note below that whilst the CFBundleShortVersionString is still set to 12.0.0.38 the CFBundleVersion has been rewritten to 12.0.0.44 and Flash Player is working.

sh-3.2# defaults read /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist | grep -A 1 Flash
            "com.macromedia.Flash Player.plugin" =             {
                MinimumPlugInBundleVersion = "12.0.0.44";
sh-3.2# defaults read /Library/Internet Plug-Ins/Flash Player.plugin/Contents/Info.plist  CFBundleShortVersionString
12.0.0.38
sh-3.2# defaults read /Library/Internet Plug-Ins/Flash Player.plugin/Contents/Info.plist  CFBundleVersion
12.0.0.44

You can set up a launchd WatchPath to monitor the change of the XProtect.meta.plist and then rewrite values appropriately to the Plug-In.

Regarding Xprotect in Mavericks, I saw this post over on MacEnt
https://groups.google.com/forum/#!topic/macenterprise/hF5sofyHiik

from Tim Sutton "In Mavericks, XProtect metadata is made available via software update (as now are other configuration items like energy settings for specific known 3rd-party apps). "

Does this mean if we don't allow users to run software update, they won't get XProtect updates anymore in 10.9 so outdated plugins won't be automatically blocked? Or is that info still coming down silentlyeven without manual run of software update if we don't use netsus?

Thanks.

Does this mean if we don't allow users to run software update, they won't get XProtect updates anymore in 10.9 so outdated plugins won't be automatically blocked? Or is that info still coming down silentlyeven without manual run of software update if we don't use netsus?

You'd have to disable all automatic Software Update checks.

XProtect updates are downloaded at installed during Software Update's background update checks.

thanks for quick response @gregneagle

Sorry to necro this thread, but again: how do people with netsus/reposado manage this? It seems in order to get new XProtect definitions, one needs to turn on Automatic updates and "install system files and security updates". But we don't want Automatic updates turned on, do we, since that will cause our (non-admin) endusers to get the message that they really should update to Yosemite?

Our current process is to run software update daily on computers on our wired networks and less often on wifi. But those updates doesn't seem to download XProtect/Gatekeeper. I've chatted some with @gregneagle on irc about this a month or two ago, but I don't know if anyone has come up with a good solution where:
- we still can trigger software updates on a schedule, and
- includes Xprotect/Gatekeeper

What say you, learned people?

Drop XProtectPlistConfigData.pkg and GatekeeperConfigData.pkg into Casper perhaps and use the same trigger method.

Yeah, Sean, that is probably the solution we will use. Still, it's kind of pesky that you can't get them via standard software update commands, maybe something jamf runSoftwareUpdate was able to include. Otherwise, there is a big risk that many managed mac will remain at an old Gatekeeper/XProtect version.

Arguably it has a bonus side. You say that you reduce the frequency of software updates on WiFi, but as these have little overhead and as you could have a separate mechanism to install, then at least you know these could be up to date, whilst other software updates may be on hold.

As it happens, I am doing something different to the suggestions above. The software is already downloaded on our Software Update Server and is available via http. Therefore we have a script to pull the pkg using 'curl' and then running 'installer' against this download.

The script is being passed the difference in the path of the download as a string, since each version will have it's own download path. Actually, I'm passing two strings, the first stating if it is Gatekeeper or XProtect and the second string is the path difference. By doing this, we can use the same script for both XProtect and Gatekeeper.