Feeds:
Posts
Comments

Archive for August 7th, 2018

by Tom Nelson

Originally introduced with OS X El Capitan, System Integrity Protection, usually referred to as SIP, is a security feature built into the Mac operating system that’s designed to protect most system locations, system processes, and Kernel extensions from being written to, modified, or replaced.

SIP and related security protections in the Mac operating system have undergone changes with each release of the OS, but the basics of how the SIP system works have remained the same, including how SIP can be enabled, disabled, and have its current status checked on.

Rootless, More or Less
OS X El Capitan was the first version of the Mac operating system to incorporate SIP, as well as the idea that the Mac operating system was now rootless; that is, there was no longer a root account, the all-powerful primary account that had access to almost the entire system. But it turns out the concept of the Mac being rootless was more of a security marketing gimmick than actual fact. There was still a root account; the difference is that when enabled, SIP poses additional restrictions on the root account, walling off certain portions of the system from access by an account with root level privileges.

The additional isolation of system components from accounts with root privileges helps to prevent malware from being able to gain access to the system, where it could embed itself and take advantage of all of the system services running on a Mac.

System Integrity Protection (SIP)
While “rootless” was mostly marketing, SIP actually hardened the Mac by preventing modifications to the following locations:

  • /System
  • /usr
  • /bin
  • /sbin
  • All apps preinstalled by Apple

The exceptions to the rule are apps or processes that have been signed by Apple and have special entitlement to write to system files. This includes Apple installers and Apple software update services.

SIP is effective at stopping system locations from being written to by third-party apps and services. Only Apple-signed system processes can write to system locations.

System processes can’t be attached to. This prevents code injection or runtime attachment to system processes, techniques often used by malware to force privileged processes to run the malware code.

Kernel extensions must be signed with an Apple Developer ID that specifically allows for signed Kext (kernel extensions) certificates. This can prevent kernel extensions from being replaced or modified by malware, as well as prevent new unsigned kernel extensions from being installed.

Read more on Rocket Yard, The MacSales.com Blog

Advertisements

Read Full Post »