System Integrity Protection and the end of XProtect management for browser plug-ins
OS X El Capitan adds a new security feature named System Integrity Protection (SIP). Among other things, SIP prevents parties other than Apple from adding, deleting or modifying directories and files stored in certain directories:
- /bin
- /sbin
- /usr
- /System
Apple has indicated that the following directories are available for developers to access:
- /usr/local
- /Applications
- /Library
- ~/Library
All directories in /usr except for /usr/local are protected by SIP.
SIP’s protection of /System affects XProtect’s XProtect.plist and XProtect.meta.plist configuration files as they are stored in the following location inside /System:
/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist
/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist
As the XProtect configuration files will be locked against editing on OS X El Capitan, this means that they can no longer be managed to allow older versions of the Flash and Java browser plug-ins to run.
If your shop includes a mission-critical system that requires using older Flash or Java browser plug-ins, I recommend working with your vendor and/or in-house developers to find out:
- If the use of the Java and/or Flash browser plug-ins can be discontinued.
- If their use can’t be discontinued, if the system in question can be updated to support the latest versions of these plug-ins and continue to be compatible as new versions of the Java and/or Flash browser plug-ins are released.
Update – 9-14-2015: Josh Dyson has pointed out that there is a way to allow older plug-ins to access specific sites.
By adding the needed sites to a whitelist in Safari and setting those specific sites to Allow Always, those sites’ functions will be accessible with the older browser plug-in even if XProtect would otherwise block the use of the plug-in. Websites not included in the whitelist would still have the use of the plug-in blocked.
Apple has provided a KBase article showing how to manage Safari plug-in options, including how to whitelist websites, using a configuration profile. It’s available via the link below:
Leave a comment
Recent Comments
 | Ben LeRoy on Losing a giant |
 | Peter-Erik on Downloading installer packages… |
 | nathanhaggard on Losing a giant |
 | andras0602 on Disabling login window clock d… |
 | Jeff on Losing a giant |
Der Flounder 
Providing you are using the Software Update Service of OS X Server, and it’s set to Manual, you should still be able to delay changes to the XProtect configuration plist that way.
Yes, you can, but you can only delay ALL changes, what is not recommended…
You can use MCX to manage plugin settings for Safari (ManagedPlugInPolicies); this allows you to apply the XProtect updates from Apple so that unsafe plugin versions are blocked on arbitrary sites, but still permitted on sites you care about.
Rich,
Do you know if the User Template is still available for system admins in El Capitan? I was able to copy a file to it and remove it from Terminal and it was there for a test user, but if I am going to implement El Capitan right around here, then I need to know if continuing to use the User Template is going to backfire on me.
Been working fine for me through beta Brian. I may have had SIP disabled though, not sure. But working fine for me.
I have had major problems trying to put a pre-set Standard User account into the User Template as I have in every other OS X version. After turning of SIP and running a script that deletes everything from Englis.lproj and replaces it with the information for /User/account name and try to make a new account all the base folders in the dock and finder window are not pointing at the User folder anymore. Even after I repair permission with the Terminal. How have you been able to fix that? Thanks for you help!
Glad to see this plugin management like Josh mentioned, I put in a bugreport on this a year or two ago to have this ability and be able to manage it from MCX/Profiles.
@cashxx This has been around for quite a while – Safari 7 maybe? Even in Safari 6 there was a whitelist, albeit somewhat different in design. In any case, you can certainly manage it via MCX or Config Profile (the latter requiring a custom payload, which is a bit annoying to maintain – keep a catalog of plist snippets somewhere safe).
For those of us who like to tweak our system at the UNIX level, SIP can be turned off. Boot into the recovery partition then open Utilities, System Configuration and uncheck Enforce System Integrity Protection. Apply Configuration then reboot.
very true…use csrutil while booted to Recovery HD. BUT, it is very possible in future hardware that Apple may not allow that anymore…the trends I am seeing by all computer manufacturers is to move toward a model where customers cannot circumvent some security measures. For example on Windows, you’ve heard of “Secure Boot”. Right now many users can turn that off and modify their systems at will. Given time that option could disappear or just not be included, or worse a manufacturer could charge more for that option to disable it. Apple is moving more toward OS security with each OS they release and I’m guessing that csrutil could disappear just as easily as it appeared if Apple wanted it that way.
In my case (10.11.1 with SIP fully disabled) the XProtect plist files do not even exist in /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/ … as a result, for example, the menu bar app XProtectPluginChecker only returns an error. Or could it be that the XProtect blacklist information is now stored in a different location?
It has been moved to /System/Library/CoreServices/XProtect.bundle
Thank you. Weird thing is, the last modification date on my machine is 19 October 2015; will monitor it.