There’s no doubt that System Integrity Protection has helped keep macOS more secure since its introduction in 10.11, and it continues to see updates that restrict what can be modified and where non-system files can be stored.
Apple’s official, user-facing documentation says:
Unfortunately, this documentation leaves out an important part of the story. The full list of protected paths and process labels can be found in a bunch of related files in the Sandbox folder within System/Library.
Among these are a list of protected locations in the rootless.conf file. The file, however, tells a little more than Apple’s user-facing documentation. Not only does it list the locations that can’t be modified, it also lists some that can. Despite what Apple officially says, not everything in System, it turns out, is in fact protected by SIP.
We can use a quick-one liner on the command line to output the exceptions on the current system like so:
awk '$1 ~ /^\*/' /System/Library/Sandbox/rootless.conf
On my 10.13.6 system that returns 9 locations, four of which are within the System’s Library folder:
Let’s check to see if these paths are really writable. We’ll create a simple script that, when run, produces a dialog box showing where the script is located. We first create the script in the /tmp folder, give it executable permissions, then move it into the System Library’s ‘Speech’ folder. We can do all this on the command line in Terminal, then execute it:
Sure enough, our test produces a script showing that it’s running out of one of the locations listed as an exception in rootless.conf.
This, of course, isn’t a SIP vulnerability. The paths we’re talking about are listed as exceptions to SIP protection, after all; what’s more, they do indeed require administrator privileges to write to (although not to run). The issue is that very few users will know that these paths are exceptions. In fact, aside from their being written in rootless.conf, there may be no other place where they are all documented, at least not at the user level. And that obscurity, of course, means many will have no idea that malware can install itself in places in the System folder where, for sure, most users will fear to tread.
Moreover, even if the user were to notice these paths in a process output or list of open files in Activity Monitor, it would be very easy to overlook them as being legitimate since they would all begin with the path ‘/System/Library/…’. Naturally, we assume the System’s folder is reserved for system files, not the user’s and not third-party applications’ either. Apple’s user-facing documentation that we referred to earlier encourages this very assumption.
What does it all mean?
In this post we’ve seen that there are places in the System folder that could easily be adopted as a nice hiding place for malware which has acquired elevated privileges. The aim here was to make these exceptions a little less obscure and to encourage people – especially those troubleshooting macOS for malware and adware issues – to add these locations to their list of places to keep an eye on.