System Integrity Protection
Security layers present in OS X.
|
|
| Developer(s) | Apple Inc. |
|---|---|
| Development status | Active |
| Operating system | OS X |
| Website | {{ |
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
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 that necessarily carries administrative credentials with it, which means that most users can grant root access to any program that asks for it. Whenever a user on such a system is prompted and enters their account password – which Martel says is often weak or non-existent – the security of the entire system is potentially compromised.[4] Restricting the power of root is not unprecedented on OS X. For instance, versions of Mac OS X prior to Leopard enforce level 1 of securelevel, a security feature that originates in BSD and its derivatives upon which OS X is partially based.[6]
Functions
System Integrity Protection applies limitations to all processes on the system, including privileged and unsandboxed ones. Certain system files, folders and processes are flagged for protection with an extended file attribute. Among the protected directories are: /System, /bin, /sbin, /usr (but not /usr/local).[7] The symbolic links from /etc, /tmp, and /var to /private/etc, /private/tmp, and /private/var are also protected, although the target directories are not themselves protected. Most preinstalled Apple applications in /Applications are protected as well.[1] The kernel stops all processes without specific privileges from writing to flagged files and folders. It also prevents code injection, runtime attachment (like debugging) and DTrace with respect to flagged processes or processes signed with an Apple private entitlement key.[8] The "kext signing" feature that Apple introduced in OS X Yosemite, which prevents the installation of kernel extensions (typically called kexts), such as drivers, without an approved developer certificate, has been integrated into System Integrity Protection as well.[4][9]
System Integrity Protection can only be disabled (either wholly or partly) from outside of the system partition. To that end, Apple provides the csrutil command-line utility which can be executed from a Terminal window within the recovery system or a bootable El Capitan install disk, which adds a boot argument to the device's NVRAM. This applies the setting to all of the installations of El Capitan on the device.[4] Upon installation of OS X El Capitan, the installer moves any unknown components within flagged system directories to /Library/SystemMigration/History/Migration-[some UUID]/QuarantineRoot/.[1][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[10] and the corresponding diskutil operation.
Reception
Reception of System Integrity Protection has been mixed. Macworld expressed the concern that Apple could take full control away from users and developers in future releases and 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.[2][11] 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
<templatestyles src="Div col/styles.css"/>
References
- ↑ 1.0 1.1 1.2 1.3 Lua error in package.lua at line 80: module 'strict' not found.
- ↑ 2.0 2.1 Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ 4.0 4.1 4.2 4.3 4.4 Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
