13

What sources say

Like everyone else’s, my /System/Library/Sandbox/rootless.conf file contains the following entries:

$ cat /System/Library/Sandbox/rootless.conf
[…]
        /System
[…]
*       /System/Library/Extensions
        /System/Library/Extensions/*
[…]

All sources on the subject I’ve found (example 1 2 3) seem to suggest that according to the rules of rootless.conf, those entries will be enforced at boot time, and can be roughly interpreted as follows:

  1. Inside the /System hierarchy, no process is allowed to write to any file or folder, except when a more specific rule grants such access;

  2. inside /System/Library/Extensions, any process that has root privileges is allowed to create new files and subfolders;

  3. however, no process is allowed to modify or delete any existing files or subfolders inside /System/Library/Extensions.

What I actually observe

However, when I looked at the actual contents of /System/Library/Extensions, I discovered to my surprise several files and folders which, despite SIP being active, are perfectly writable and deletable:

$ csrutil status
System Integrity Protection status: enabled.
$ ls -lAO /System/Library/Extensions | tail -16
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 corecrypto.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 exfat.kext
drwxr-xr-x  3 root  wheel  -            102 19 Aug  2013 hp_Inkjet9_io_enabler.kext
drwxr-xr-x  3 root  wheel  -            102 27 Apr  2013 hp_fax_io.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 iPodDriver.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 mcxalr.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 msdosfs.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 ntfs.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 pmtelemetry.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 pthread.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 smbfs.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 triggers.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 udf.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 vecLib.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 webcontentfilter.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 webdav_fs.kext

Note that hp_Inkjet9_io_enabler.kext and hp_fax_io.kext are third-party kernel extensions which were already present at the time I updated to El Capitan (which I did in May 2016).

When I search the list of SIP exceptions at /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths, I don’t see those 3rd-party extensions listed there either:

$ defaults read /System/Library/Sandbox/Compatibility.bundle/Contents/Info.plist CFBundleVersion
12.0
$ grep Extensions /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths
/System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleRTL815XComposite109.kext
/System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleRTL815XEthernet109.kext

I found over a dozen more kernel extensions that also lack the restricted flag and the com.apple.rootless attribute; all affected kernel extensions appear to be 3rd-party extensions I installed over the course of the last decade, and apparently have survived the update to El Capitan.

Which leaves me wondering about the following conundrums:

What I’d love to know

Q1. Missing flags

How come that no 3rd-party kernel extension – and in fact no file I create manually inside /System/Library/Extensions – ever receives a restricted flag or a com.apple.rootless attribute, even though the rootless.conf rule seems to mandate the contrary?

For example, a ls -dlO along the path chain of hp_fax_io.kext reveals:

$ ruby -rpathname -e 'puts Pathname.new("/System/Library/Extensions/hp_fax_io.kext").enum_for(:ascend).to_a' | xargs ls -dlO
drwxr-xr-x   39 root  wheel  -           1394 19 Jan 11:36 /
drwxr-xr-x@   4 root  wheel  restricted   136 19 Jan 11:29 /System
drwxr-xr-x   80 root  wheel  restricted  2720 10 Jan 19:19 /System/Library
drwxr-xr-x  297 root  wheel  sunlnk     10098 22 Jan 00:57 /System/Library/Extensions
drwxr-xr-x    3 root  wheel  -            102 27 Apr  2013 /System/Library/Extensions/hp_fax_io.kext

I also remember that at the time I upgraded from Yosemite, the El Capitan installer chose to move basically everything and their grandma into SIP quarantine in many instances.

Q2. Time of enforcement

If I were to:

  • boot into a recovery volume,

  • then add to rootless.conf (on the original volume) a line:

    /usr/local/*
    
  • and then reboot again into the original volume,

would macOS then douse all files under /usr/local/ with restricted flags on the next reboot?

If not, then this brings me to my final question:

Q3. Actual purpose

What purpose does rootless.conf actually serve?

3
  • 5
    Sure wish someone in the community had a few answers or even hints. I've got similar questions.
    – CXJ
    Mar 16, 2018 at 15:34
  • 5
    In line with this, shouldn't editing rootless.conf (disable SIP, edit file, re-enable SIP) change which directories are protected? This doesn't appear to actually happen... so is the file getting read at all? Oct 16, 2018 at 19:08
  • 1
    I would also like to know that if this file controls SIP, then couldn't you just make it blank to disable SIP without booting into recovery mode? This doesn't make sense. Maybe the file isn't used anymore.
    – Nicholas
    May 1 at 18:23

0

You must log in to answer this question.

Browse other questions tagged .