os x el capitan

Manipulating Apple Applications: El Capitan and SIP

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.

SIP protected areas

 

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

For others, I have been required to relocate the applications into a new “applications” folder within the local administrator’s home area:

 sudo mv /path/to/application.app /path/to/local/admin/home/Applications/

Now this would vary site to site, with some requirements being requests, and others being requirements (the challenges of an external consultant!). This would usually include items such as the Mac App Store, Chess and FaceTime.

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.

Why?

Well for a number of reasons:

  1. 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.
  2. It’s not an easy task to complete in a deployment workflow (you are required to boot to the recovery partition to disable SIP).
  3. 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?

*hopefully!

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:

  1. Utilise the options provided in the Configuration Profile management system. Examples of this include:
    1. Limiting the Mac App Store to updates only, and to only allow updates to be installed by local administrators
    2. Using the option in the ‘Restrictions’ payload to blacklist certain applications and / or paths. An example payload from Graham Gilbert.
  2. (Casper Only) Utilise the built in Application Process restriction to detect the use of unapproved applications and optional:
    1. Kill the process
    2. Notify the end user
    3. Notify the IT department
  3. 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

Summary

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.

Thanks again!

Update 26-10-15:
Added a link to an example configuration profile for restricting applications, provided by Graham Gilbert

6 Replies to "Manipulating Apple Applications: El Capitan and SIP"

  • Lewis

    I’m often surprised by how dismissive people are of number 3 on your “Why” list. But, I agree, it has always been easier to follow the path Apple has decided on.

  • We have to block outside messaging apps on some of our machines, so with 10.11 we started using using a profile. It’s worked well for the most part – it gives a good error message rather than mysteriously quitting the app when it launches.

  • Maurice G

    Not that I didn’t believe you, but I just tested trying to hide a core app and got was politely told ‘Operation not permitted’…. 🙂 So SIP works!

    If you’re not using an MDM (stand alone, off-line) and you need to hide/restrict certain core apps?

  • With SIP enabled any system app can be infected, but you cannot fix it in right way. SIP is fake only block you, but some system services can do what you can’t. With SIP you stop to be owner of your computer.
    With El Capitan apps like Chrome can get root access without password to get force update and change privillages to root, in other *nixes, like BSD, or GNU/Linux it is impossible. In there you need put passwod by youself, nothing can change without you concern. What wrong with this? Apple make bug with automatic Appstore access and try fix it with SIP nothing else. Now look how many viruses born to OSX 10.11, but not work on SL.

    • Darren Wallace

      Hi ydk2,

      I’m afraid I respectfully disagree. If a system App can be infected with SIP enabled, then how can you also not fix it?

      I’ll freely admit that it’s not the 100 % fool proof method to defend against malware and misconfiguration by editing system files, but surely is better to have, than to not have?

      With other *nixes variants, you can have a cron job running as root which would also pose the same issue as your example of Chrome having root. Chrome should be running as the user who launches the application, with only the autoupdate process running as root, if configured that way.

      Thanks for your comment,

      Darren

Leave a Reply

Your email address will not be published. Required fields are marked *