System Integrity Protection

System Integrity Protection

System Integrity Protection
Security layers present in OS X.
Developer(s) Apple Inc.
Development status Active
Operating system OS X

System Integrity Protection (SIP,[1] sometimes referred to as rootless[2][3]) is a security feature of OS X El Capitan, the operating system by Apple Inc. It protects certain system processes, files and folders from being modified or tampered with by other processes even when executed by the root user or by a user with root privileges (sudo). Apple says that the root user can be a significant risk factor to the system's security, especially on systems with a single user account on which that user is also the administrator. System Integrity Protection is enabled by default, but can be disabled.[4][5]


  • Overview 1
  • Functions 2
  • Reception 3
  • See also 4
  • References 5
  • External links 6


Apple says that System Integrity Protection is a necessary step to ensure a high level of security. In one of the WWDC developer sessions, Apple engineer Pierre-Olivier Martel described unrestricted root access as one of the remaining weaknesses of the system, saying that "[any] piece of malware is one password or vulnerability away from taking full control of the device". He stated that most installations of OS X have only one user account, thus carrying default administrative credentials with it, which means that most users can grant root access to any program that asks for it. Once a user on such a system is prompted and enters their account password—which he says is often weak or non-existent—the entire security model of the system is compromised.[4] Restricting the power of root is not unprecedented on OS X. For instance, versions of Mac OS X prior to Leopard apply a so-called kernel security level, a feature that originates in BSD upon which OS X is partially based.[6]


System Integrity Protection applies limitations to all processes on the system, including privileged and unsandboxed ones. In addition, certain system files, folders, and processes will be flagged for protection with an extended file attribute. Among the protected directories are these: /System, /bin, /sbin and /usr (but not /usr/local) as well as most preinstalled Apple applications in /Applications.[1] The kernel then stops all processes without specific privileges from writing to flagged files and folders and will prevent code injection and runtime attachment (like debugging) with respect to flagged processes or processes signed with an Apple private entitlement key.[7] Kernel extensions (typically called kexts), such as drivers, cannot be installed without approval from Apple, a feature that was introduced in OS X Yosemite and is known as kext signing.[8] Upon installation of OS X El Capitan, the installer will move any unknown components within protected system directories to /Library/SystemMigration/History/Migration-(some UUID)/QuarantineRoot/.[4][1]

System Integrity Protection can be disabled completely by booting into the recovery system and using the csrutil command-line utility in Terminal, causing a boot argument to be added to the system's NVRAM. This applies the setting to all of the system's installations of El Capitan.[4] By preventing write access to system directories, the system file and directory permissions are maintained automatically during Apple software updates. As a result, permissions repair is not available in Disk Utility[9] and the corresponding diskutil operation.


Reception of System Integrity Protection has been mixed. Some have expressed the concern that Apple could take full control away from users and developers in future releases. Macworld expressed the concern that this could move the security policy of OS X slowly toward that of Apple’s mobile operating system iOS, whereupon the installation of many utilities and modifications requires jailbreaking.[10][2] Some applications and drivers will not work to their full extent or cannot be operated at all unless the feature is disabled, either temporarily or permanently. Ars Technica suggested that this could affect smaller developers disproportionately, as larger ones may be able to work with Apple directly. However, they also remarked that by far most users, including power users, will not have a reason to turn the feature off, saying that there are "almost no downsides" to it.[1]

See also


  1. ^ a b c d Cunningham, Andrew; Hutchinson, Lee (September 29, 2015). "OS X 10.11 El Capitan: The Ars Technica Review". Ars Technica. Retrieved September 29, 2015. 
  2. ^ a b Cunningham, Andrew (June 17, 2015). "First look: OS X El Capitan brings a little Snow Leopard to Yosemite".  
  3. ^ Slivka, Eric (June 12, 2015). "OS X El Capitan Opens Door to TRIM Support on Third-Party SSDs for Improved Performance".  
  4. ^ a b c d Martel, Pierre-Olivier (June 2015). "Security and Your Apps" (PDF).  
  5. ^ "Configuring System Integrity Protection". Mac Developer Library. Apple. September 9, 2015. Retrieved October 13, 2015. 
  6. ^ Garfinkel, Simon;  
  7. ^ "What's New In OS X - OS X El Capitan v10.11". Mac Developer Library. Apple. Code injection and runtime attachments to system binaries are no longer permitted. 
  8. ^ "Trim in Yosemite". Cindori. Retrieved June 18, 2015. 
  9. ^ "OS X El Capitan Developer Beta 2 Release Notes". Mac Developer Library. Apple. June 22, 2015. At section Notes and Known Issues. Retrieved June 29, 2015. 
  10. ^ Fleishman, Glenn (July 15, 2015). "Private I: El Capitan's System Integrity Protection will shift utilities' functions".  

External links

  • System Integrity Protection Guide in Apple's Mac Developer Library