Home / Blog / OS X security model (II)

OS X security model (II)

Posted on 02/18/2016, by Antonio López (INCIBE)
OS X

In the article: Security Model in OS X (I), we introduced the operating system’s main accumulated security features accumulated up to Yosemite (OS X 10.10). With the latest version, launched in September 2015, an interesting new security feature appears in the system.

System Integrity Protection (SIP)

As of OS X 10.11 (El Capitan), Apple is tightening security measures even further with the implementation of System Integrity Protection (SIP) technology, or rootless, a mechanism which prevents the manipulation of certain system files or paths, even when acting with root privileges.

The incorporation of rootless technology in OS X is intended to protect files and/or processes and to avoid, as far as possible, actions that modify resources and/or services that are critical for the system’s operation. This could, for example, prevent the exploitation of a vulnerability that led to privilege escalation from succeeding in fully compromising the system.

So... does this limit full system access, even for legitimate root users? The truth is: yes, it does, at least if this functionality is not disabled.

image001

- Rootless... Will a jailbreak be necessary for Mac in the future? .xkcd.com -

SIP technology is situated at POSIX permission level, meaning that a running system cannot modify its own behaviour. To manipulate SIP-protected resources, it would have to be disabled from the OS’s recovery mode at computer start-up.

Layered model of OS X security

-Layered model of OS X security -

SIP in action

System Integrity Protection focuses on three main factors: file system protection, running processes protection and kernel extension protection.

File system protection

In general, SIP prevents the addition, modification or deletion of any content at the following locations:

 

  • /bin
  • /sbin
  • /usr (except /usr/local, which is permitted)
  • /System

Any attempt to modify any of these resources will be denied, with an “Operation not allowed” error notification appearing. We can find out quickly and easily if a file is SIP-protected using the ls command. To do that, we specify the parameter “-O” ( ls –O); if the resource is protected, the attribute “restricted” will be shown:

SIP prevents /bin

- SIP prevents /bin from being modified. Note the property “restricted” with ls -lO -

Rootless file

SIP keeps a list of protected locations in a configuration file (rootless.conf), with allowed exceptions marked “*”. In this file, we can check how, for example, applications installed by default by the system (OS X native applications) are protected, and how some exceptions are allowed under restricted paths such as /System, /Library or libraries (dydl). In principle, any path that is not listed in this file as protected or as an exception is beyond the reach of SIP.

rootless.conf file

- rootless.conf file-

SIP is configured to maintain a file system structure that allows applications to be installed and adequately managed. It allows access to the paths:

  • /usr/local
  • /Applications
  • /Library
  • ~/Library

System updates or any other operation that involves the modification of restricted paths will only be possible with software carrying an Apple digital signature.

SIP-protected files

- SIP-protected files. Note the “restricted” attribute -

Exceptions and compatibility

To solve possible compatibility problems with applications installed prior to the El Capitan update, SIP implements a mechanism for files that conflict with locations in the path: /Library/SystemMigration/History/Migration-<UUID>/QuarantineRoot/

It also implements other compatibility systems for third-party software, contained in the folder: /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

Running processes protection

As of OS X 10.11, when a process is running, the kernel verifies if the main executable is SIP-protected; if it is, it will stop the user from interfering in its execution, for example by analysing it with a debugger.

SIP protection prevents the Finder process from being attached to a debugger

- SIP protection prevents the Finder process from being attached to a debugger -

SIP also increases protection against attacks that inject libraries by purging environment variables in function calls, invalidating DYDL_LIBRARY_PATH or DYDL_INSERT_LIBRARIES, for example. This measure, together with protection against the debugging of binaries, adds layers of protection against the exploitation of attacks against system processes.

Kernel extension protection

The OS X operating system allows the use of additional functions (kexts), which can be loaded as kernel extensions and integrated into the kernel’s functioning during execution. As of OS X 10.10 Yosemite, it is obligatory to possess a recognised Developer ID signature to develop kexts for loading kernel extensions onto the operating system. However, in Yosemite, through a system start-up parameter, it was possible to deactivate this kernel extension signing and bypass this restriction.

However, this measure has no effect in El Capitan, and the only way of allowing kext extensions without the appropriate signature is through completely disabling SIP from the computer’s recovery mode.

Yosemite

- Yosemite: disabling kext signing. This is not valid in El Capitan -

Back in time: enabling/disabling SIP

The command csrutil is responsible for enabling and disabling SIP, and includes the options: clear, enable, disable, status and netboot.

csrutil Utility for managing SIP

- csrutil Utility for managing SIP. It only allows changes to be made when executed in recovery mode -

To modify the status, it is necessary to boot in recovery mode (R) and run csrutil disable in Terminal as is shown in the following screenshots:

Disabling SIP from computer recovery mode 1

Disabling SIP from computer recovery mode 2

- Disabling SIP from computer recovery mode -

SIP may be a headache for people who prefer to have absolute control over their operating system. If that is the case, the solution is to disable SIP, eliminating all the restrictions the mechanism imposes on the system’s root user.

Is it recommended? Is it absolutely necessary? In short, no. But the freedom of being the system’s lord and master is a privilege that is difficult to let go, and implies one of the premises that sudo and other permission elevations try to remind us of:

  1. Respect the privacy of others.
  2. Think before you type.
  3. With great power comes great responsibility.