Lo que dicen las fuentes

Como todos los demás, mi archivo /System/Library/Sandbox/rootless.conf contiene las siguientes entradas:

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

Todas las fuentes sobre el tema I ' encontrado (ejemplo 1 2 3 ) parece sugerir que de acuerdo con las reglas de rootless.conf , esas entradas se aplicarán en el momento del arranque, y se pueden interpretar de la siguiente manera:

1. Dentro de la jerarquía /System , no se permite que ningún proceso escriba en ningún archivo o carpeta, excepto cuando una regla más específica otorga dicho acceso;

2. dentro de /System/Library/Extensions , cualquier proceso que tenga privilegios de root puede crear nuevos archivos y subcarpetas;

3. sin embargo, no se permite ningún proceso para modificar o eliminar archivos o subcarpetas existentes dentro de /System/Library/Extensions .

Lo que realmente observo

Sin embargo, cuando miré el contenido real de /System/Library/Extensions , descubrí para mi sorpresa varios archivos y carpetas que, a pesar de que el SIP está activo, se pueden escribir y eliminar perfectamente:

$ 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

Tenga en cuenta que hp_Inkjet9_io_enabler.kext y hp_fax_io.kext son extensiones de kernel de terceros que ya estaban presentes cuando actualicé a El Capitán (que hice en mayo de 2016).

Cuando busco en la lista de excepciones de SIP en /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths , tampoco veo las extensiones de terceros que figuran allí:

$ 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

Encontré más de una docena de extensiones de kernel que también carecen de la bandera restricted y el atributo com.apple.rootless ; todas las extensiones de kernel afectadas parecen ser extensiones de terceros que instalé en el transcurso de la última década, y aparentemente han sobrevivido a la actualización de El Capitán.

Lo que me deja preguntándome sobre los siguientes enigmas:

Lo que me encantaría saber

Q1. Banderas que faltan

¿Por qué ninguna extensión de kernel de terceros, y de hecho ningún archivo que creo manualmente dentro de /System/Library/Extensions , recibe una marca restricted o un atributo com.apple.rootless , aunque la regla rootless.conf parece exigir ¿Al contrario?

Por ejemplo, un ls -dlO a lo largo de la cadena de ruta de hp_fax_io.kext revela:

$ 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

También recuerdo que en el momento en que realicé una actualización de Yosemite, el instalador de El Capitan optó por mover básicamente a todo ya su abuela a la cuarentena SIP en muchos casos.

Q2. Tiempo de ejecución

Si tuviera que:

• inicia en un volumen de recuperación,

• luego agregue a rootless.conf (en el volumen original) una línea:

  /usr/local/*
  

• y luego reinicie de nuevo en el volumen original,

¿macOS apaga todos los archivos bajo /usr/local/ con restricted flags en el próximo reinicio?

Si no, entonces esto me lleva a mi pregunta final:

Q3. Propósito real

¿Para qué sirve rootless.conf en realidad ?