I’m writing this blog after having sat through Rich Trouton’s great JNUC talk on OS X security, especially around the use of SIP.
The usual Disclaimer:
While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. Amsys will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.
SIP (System Integrity Protection)
I’m sure many of you have heard but OS X 10.11 (El Capitan) has shipped with a new security feature called SIP (also commonly kno’wn as ‘rootless’). If you haven’t, I strongly recommend that you check out Rich’s blog on the subject.
In a nutshell, SIP will prevent the modification of areas of OS X that Apple deems they own. This is to pre-emptively protect against malware embedding itself in trusted areas of the system.
The SIP Playbook
As part of Rich’s talk he showed a list of protected areas (found in ‘/System/Library/Sandbox/rootless.conf’ – Shown below, and ‘/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths’) and it confirmed something I though I saw previously.
That’s right, Apple have locked out the modification of the majority of their core, built-in Apps.
That’s great, but how does this apply to me?
Good question, I’m glad you asked 🙂
As part of the project work we carry out, we discuss with the end customer which settings they would want to be pre-configured. With education institutions, this also stretches to what areas of the OS we need to lock out from ‘untrusted’ students (typically under 18s). One of the common requests I get is to hide or move applications the customer doesn’t want students to be ‘playing with’ instead of working.
Often, depending on the customer’s exact requirements, this has involved simply using the ‘chflags’ command to hide an item:
sudo chflags hidden /path/to/application.app
sudo mv /path/to/application.app /path/to/local/admin/home/Applications/
What’s changed with SIP?
Now if you go over the last two sections, you may see what I had confirmed from Rich’s presentation at JNUC:
If the application in question is in SIPs playbook, I cannot modify this in anyway.
This includes (but isn’t limited to):
- Modifying the permissions to prevent the application from being launched.
- Hiding the application from the GUI using ‘chflags hidden’.
- Moving the application from the /Applications folder to somewhere else in the system.
Why don’t you just turn SIP off?
We have been discussing this internally at Amsys and have reached a decision that we will not be disabling SIP. We have even made the decision to not publically document how to disable SIP.
Well for a number of reasons:
- It’s a core part of Apple’s OS X security model, and disabling this would be leaving an aspect of the OS unprotected. An area that Apple has actively decided it wants protected.
- It’s not an easy task to complete in a deployment workflow (you are required to boot to the recovery partition to disable SIP).
- Apple has decided that this is the direction they will be moving in. In the past, we have found that fighting against the vender’s decision on their own products just results in more issues, more work and further stress.
Makes sense*, what should I do instead?
Good question, and not one I can answer for everyone. But there are some possible options we will certainly be using and recommending to our customers:
- Utilise the options provided in the Configuration Profile management system. Examples of this include:
- Limiting the Mac App Store to updates only, and to only allow updates to be installed by local administrators
- Using the option in the ‘Restrictions’ payload to blacklist certain applications and / or paths. An example payload from Graham Gilbert.
- (Casper Only) Utilise the built in Application Process restriction to detect the use of unapproved applications and optional:
- Kill the process
- Notify the end user
- Notify the IT department
- Discuss the use of IT technology (with a possibly bad return on investment for each particular scenario) to resolve behaviour and / or HR issues. For example, treating the use of unapproved applications during lesson time the same way you’d treat a student who is misbehaving
Thanks for reading through the blog and letting me ramble on about my thoughts. In our mind, SIP is here to stay and fighting against it (especially in the long term) will cause more issues then it will fix.
As always, if you have any questions, queries or comments, let us know below and I’ll try to respond to and delve into as many as I can. Alternatively, feel free to give me a shout at on the Mac Admins Slack (@daz_wallace) or if you see me at one of the Mac meet ups or conferences and I’ll my best to help.
Added a link to an example configuration profile for restricting applications, provided by Graham Gilbert