Over the years, Apple has added some great security layers to OS X to help make using a Mac more secure. These have included FileVault, App Sandboxing and Gatekeeper.
In El Capitan, Apple are adding a new layer of security called System Integrity Protection. This new layer of security is designed to protect the integrity of the system itself.
As with all traditional Unix systems, the root account is all empowering. It can practically do anything it wants including removing or replacing key system files.
With Mac systems, a typical setup would be a single user who is also an admin on that computer, which means you are one step away from granting someone root access to the system.
How many times are you prompted for your password when an App wants to make a change or perform an install? Most users blindly just enter their password. Once the password is entered, that app would not have too much trouble getting root access to the system and thus could perform any untold amount of damage.
This is where System Integrity Protection comes into play. In a nutshell, it prevents key system directories from being modified even by the root account. This is why this feature is sometimes known as “Root Less”. So even if a process was granted root access, it could not modify or delete certain directories within key parts of the file system.
So as an example, the following directories would be protected. /System, /bin, /usr.
This command would now fail in El Capitan: sudo touch /usr/test
For most users, they will not be aware that this service is in play. Apple code is exempt so installations from the Mac App Store or system updates would not be affected.
For some more advanced users, this potentially could cause some issues.
As an example, if you install homebrew services or have custom bespoke services installed, then potentially they could live in /usr, which is now out of bounds in El Capitan. Therefore, when you upgrade to El Capitan, a migration will be performed, moving these items to directories that are allowed, which could break some solutions.
In the case of the /usr directory, /usr/local is still allowed for this sort of circumstance.
This feature can be disabled by booting to the Recovery OS and running a new Security Configuration utility to disable it. Beware that this actually sets a parameter in NVRAM, so it’s persistent between OS’s on that box.
Overall though, this is a nice addition to OS X.