rcmdnk's blog

OS X 10.11 El CapitanのSystem Integrity Protection(SIP)についてちょっと詳しく
The Complete Beginners Guide to Mac OS X El Capitan: (For MacBook, MacBook Air, MacBook Pro, iMac, Mac Pro, and Mac Mini) (English Edition)

OS X 10.11 El Capitan adopts new security system called SIP (System Integrity Protection).

This new system affects some applications and some of them can not be used under it. It also affects on Homebrew.

Sponsored Links

SIP (System Integrity Protection)

SIP (System Integrity Protection) is new security system adopted in OS X El Capitan.

It is sometime called rootless1, because it reduces authorities of root.

Under this security system, even root can modify limited files/directories, and some processes are also limited to be modified.

20160517_osxsecuritylayers.png

This is conceptual picture of El Capitan’s security layer.

  • Gatekeeper

At the outermost, Gatekeeper 2 rejects to install applications which do not have a correct developer ID.

  • Sandbox

Applications, which are confirmed by Gatakeeper, are launched in a sandbox OS X - Security - Apple. This protects data of OS X from unexpected access/change by applications.

  • POSIX

In addition, as OS X is UNIX, it has an access control of POSIX, which limits access/change authorities of each file/directory for each user.

In POSIX control, basically root can access/change all files/directories.

  • Keychain

At the innermost, there is Keychain. Keychain is special database which has such password information, and is encrypted. It is strongly protected and even root can not access directly.

In short, OS X’s security system can be described like this. But there is a problem, until Yosemite (or say in Unix), that if someone obtains full authority at POSIX, he/she can change everything other than Keychain 3.

To solve this, new system which limits the authority of root. (This is pictured as separated parts of Keychain in the above picture.)

Under this system, even if a user allows root authority to applications, some parts in OS X are protected for sure.

But it becomes too strong and some applications can work under this system any more…

Files/directories under the protection

Protected files/directories are written in

/System/Library/Sandbox/rootless.conf

Try to check:

$ cat /System/Library/Sandbox/rootless.conf
                /Applications/App Store.app
                /Applications/Automator.app
                /Applications/Calculator.app
                /Applications/Calendar.app
                /Applications/Chess.app
                /Applications/Contacts.app
                /Applications/Dashboard.app
                /Applications/Dictionary.app
                /Applications/DVD Player.app
                /Applications/FaceTime.app
                /Applications/Font Book.app
                /Applications/Game Center.app
                /Applications/Image Capture.app
                /Applications/Launchpad.app
                /Applications/Mail.app
                /Applications/Maps.app
                /Applications/Messages.app
                /Applications/Mission Control.app
                /Applications/Notes.app
                /Applications/Photo Booth.app
                /Applications/Photos.app
                /Applications/Preview.app
                /Applications/QuickTime Player.app
                /Applications/Reminders.app
                /Applications/Safari.app
                /Applications/Stickies.app
                /Applications/System Preferences.app
                /Applications/TextEdit.app
                /Applications/Time Machine.app
                /Applications/Utilities/Activity Monitor.app
                /Applications/Utilities/AirPort Utility.app
                /Applications/Utilities/Audio MIDI Setup.app
                /Applications/Utilities/Bluetooth File Exchange.app
                /Applications/Utilities/Boot Camp Assistant.app
                /Applications/Utilities/ColorSync Utility.app
                /Applications/Utilities/Console.app
                /Applications/Utilities/Digital Color Meter.app
                /Applications/Utilities/Disk Utility.app
                /Applications/Utilities/Feedback Assistant.app
                /Applications/Utilities/Grab.app
                /Applications/Utilities/Grapher.app
                /Applications/Utilities/Keychain Access.app
                /Applications/Utilities/Migration Assistant.app
                /Applications/Utilities/Script Editor.app
                /Applications/Utilities/System Information.app
                /Applications/Utilities/Terminal.app
                /Applications/Utilities/VoiceOver Utility.app
                /Library/Preferences/SystemConfiguration/com.apple.Boot.plist
                /System
*               /System/Library/Caches
booter          /System/Library/CoreServices
*               /System/Library/CoreServices/Photo Library Migration Utility.app
                /System/Library/CoreServices/RawCamera.bundle
*               /System/Library/Extensions
                /System/Library/Extensions/*
UpdateSettings  /System/Library/LaunchDaemons/com.apple.UpdateSettings.plist
*               /System/Library/Speech
*               /System/Library/User Template
                /bin
dyld            /private/var/db/dyld
                /sbin
                /usr
*               /usr/libexec/cups
*               /usr/local
*               /usr/share/man
# symlinks
                /etc
                /tmp
                /var

Like this.

You can see such /System, /user, /bin, or /sbin.

In addition, some pre-installed applications are also included.

In the list, lines starting with * means that these files/directories are not protected even if they are under protected directories.

Therefore, /user is under protection but /usr/local is not and user can modify it.

Disabling SIP

As described above, /usr/local can be modified, but you can not make new directory under /usr, so if /usr/local does not exist, /usr/local can not be created.

In addition, some applications are listed, too, and it means you can not modify such icons of them.

To modify them, you need to disable SIP.

To disable SIP, first launch OS X in Recovery Mode, start OS X with pushing -R.

In Recovery Mode, you can find Utility in the menu bar, and there is Terminal.

Launch Terminal and execute command:

-bash-3.2 # csrutil disable
Successfully disabled System Integrity Protection. Please restart the machine for the changes to take effect.
-bash-3.2 #

After reboot and launch OS X normally, SIP is disabled.

To check it, launch terminal and execute command:

$ csrutil status
System Integrity Protection status: enabled (Custom Configuration).

Configuration:
        Apple Internal: disabled
        Kext Signing: enabled
        Filesystem Protections: disabled
        Debugging Restrictions: disabled
        DTrace Restrictions: disabled
        NVRAM Protections: disabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
$

It should be like this4.

Here, it says enabled like:

System Integrity Protection status: enabled (Custom Configuration).

but you can see that each component under it are all disabled.

To modify icons or creating /usr/local, SIP need to be disabled temporarily, so that it may be better to re-enable SIP after changes.

To enable SIP, launch OS X in Recovery Mode again, and execute following command in terminal:

-bash-3.2 # csrutil enable
Successfully enabled System Integrity Protection. Please restart the machine for the changes to take effect.
-bash-3.2 #

Then reboot.

To check SIP, use csrutil status:

$ csrutil status
System Integrity Protection status: enabled.
$

Now SIP is enabled completely.

On the other hand, if you want to use such XtraFinder or TotalFinder, you need to disable SIP always.

These applications seem not compatible with El Capitan, but you can use them if SIP is disabled.

But it is a bit unsecure if you disable all SIP functions. If you see above csrutil status results, you can see that SIP is separated in some groups.

For such XtraFinder, you can disable only a part by command of csrutil enable -without debug:

-bash-3.2 # csrutil enable --without debug
csrutil: requesting an unsupported configuration. This is likely break in the future and leave your machine in an unknown state.
Successfully enabled System Integrity Protection. Please restart the machine for the changes to take effect.
-bash-3.2 #

This enables all SIP functions but debug part. This command can be used even if all SIP is enabled. (It disables only debug part.)

After executing this command, you can see the status like:

$ csrutil status
System Integrity Protection status: enabled (Custom Configuration).

Configuration:
        Apple Internal: disabled
        Kext Signing: enabled
        Filesystem Protections: enabled
        Debugging Restrictions: disabled
        DTrace Restrictions: enabled
        NVRAM Protections: enabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
$

So, only Apple Internal and Debugging Restrictions: are disabled.

Such FileSystem Protections is enabled, therefore you can not modify /usr even as root in this case.

Under this condition, you can use XtraFinder or TotalFinder. If you want to use them, it is better to disable minimal part (debug part).

If you want to disable only FileSystem Protections, you can use --without fs:

-bash-3.2 # csrutil enable --without fs

NVRAM related to SIP

I found some documents which show that SIP can be disabled not entering Recovery Mode, for example:

Rootless and boot-args · Cryptomonkeys Consulting: https://www.cryptomonkeys.com/2015/07/osx-rootless-boot-args/

Here, you can disable SIP by using command:

$ sudo nvram boot-args="rootless=0"

in normal mode, and restarting, but I could not reproduce it.

In addition, it is said that a command

$ sudo nvram boot-args="-x"

makes the next boot to be Safe Mode. But I can’t do it, neither.

NVRAM is small memory which has some OS X settings5.

In above SIP’s status list, you can find NVRAM Protections, so that this is also protected by SIP.

Therefore, NVRAM can not be modified if SIP is enabled.

In addition, I found following article:

SIP/Rootless Internal in El Capitan Delta’s Lair: http://www.idelta.info/archives/sip-rootless-internal-in-el-capitan/

It explains what is changed by csrutil. It is boot property data and SIP information is included in it.

For example, such --without debug changes only some bit.

But it says that such "rootless=0" is removed at El Capitan.

It seems that these SIP related things are changed so much since Beta version, such that GUI application was there. Therefore, you need to be careful about information as it is very deep settings in OS.

Sponsored Links
  1. System Integrity Protection - Wikipedia, the free encyclopedia

  2. OS X: About Gatekeeper - Apple Support

  3. System Integrity Protection – Adding another layer to Apple’s security mode Der Flounder

  4. Only status subcommand for csrutil is available in other than Recovery Mode. If you try to use other subcommands, it argues like:

    $ csrutil  enable
    csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
    

  5. How to Reset NVRAM on your Mac - Apple Support

Sponsored Links

« How to add non-Gmail address to Gmail with Gmail's SMTP server How to disable Mac's startup chime »

}