So I submitted a hint for getting info about the Safe Downloads protection list, then I made a widget, now delving deeper into Safe Downloads list and the command line
Let’s look at the BOM for the update:
/Library/Preferences/com.apple.ReportMessages.domains
/Library/Preferences/com.apple.ReportMessages.v2.domains
/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist
/System/Library/CoreServices/MRTAgent.app
/System/Library/LaunchAgents/com.apple.mrt.uiagent.plist
/System/Library/LaunchDaemons/com.apple.mrt.plist
/System/Library/LaunchDaemons/com.apple.xprotectupdater.plist
/System/Library/PreferencePanes/Security.prefPane
/usr/libexec/MRT
/usr/libexec/XProtectUpdater
What’s interesting is after installation /usr/libexec/MRT, com.apple.mrt.plist, and com.apple.mrt.uiagent.plist delete themselves after they run?! This is odd, yes? From what it looks like MRT has a lot of pattern matching code in it… Also notable is that in the postflight action loadMRT, the launchagent and daemon are unloaded and reloaded in the postflight actions, however the loadXProtectUpdater script does not do this. So the XProtectUpdater does not run again if you rerun the installer since launchctl will report it’s already loaded, so you’ll have to wait a day for it to check again and update as seen in com.apple.xprotectupdater.plist (86400 seconds = 1 day).
If you want to manually force an update, you can run this command:
sudo /usr/libexec/XprotectUpdaterYou must run as root or else it informs you:
XprotectUpdater[pids] Unable to write new signature meta plist
You can also just toggle the preference in the Security prefpane, this causes the launchd job to be unloaded an reloaded, however from an admin POV it’s nice to have a non-GUI way to do this. Also there seems to be a bug in the prefpane so values are not written after it is open for more than 30 seconds! Come on 10.6.8! (It feels like this was Lion stuff that’s getting shoe-horned into Snow Leopard a bit earlier than they expected )
Another interesting tidbit is the actual malware list that is squirreled away here:
/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist
If you attempt to use the defaults command to read it you are given this:
defaults[pids] Preference plist was NOT a dictionary.
defaults[pids] Domain /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect does not exist
It seems the Apple folks have done some creative things so while this is still valid XML it is not a defaults compatible plist. The values are dictionaries stored in an array at the top level. Is this protection against script-kiddies who’d use defaults to change values in the list? While the file is root owned, one must wonder if there are safeguards to check its checksum against a server to detect unauthorized changes to it? Since admin status is enough to escalate to root using sudo (and every initial user in OS X is an admin), combine this with the fact that installer runs as root when installing a pkg, and this is something to keep an eye on… (oh right my point being this thwarts a script to list detected threats, at least easily using defaults)
And some parting advice: Turn off Open Safe Downloads in Safari! It’s an oddly bad decision by Apple, its paralells to Windows’ AutoPlay/AutoRun give me goose bumps! I don’t want a dmg opening itself up and copying out it’s pkg payload into Downloads, then auto launching it! CRAZY BAD! Malware on a platinum platter, Apple couldn’t have made it easier!
Here’s the code for turning this off in Safari, it is a per user preference:
defaults write com.apple.Safari AutoOpenSafeDownloads -bool FALSE
And so concludes this expedition, hope you learned something, and can teach me something back in the process, thanks!