Why does my `rootless.conf` not always affect SIP’s choice of which files get the `restricted` flag treatment?

Question

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?