Lo que dicen las fuentes

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

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

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

1. Dentro de la /Systemjerarquía , 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. adentro/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 en su interior /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 SIP está activo, son perfectamente editables y eliminables:

$ 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.kexty hp_fax_io.kextson extensiones de kernel de terceros que ya estaban presentes en el momento en que actualicé a El Capitan (que hice en mayo de 2016).

Cuando busco en la lista de excepciones SIP en /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths, tampoco veo esas extensiones de terceros enumeradas 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 más que también carecen de la restrictedbandera y el com.apple.rootlessatributo; 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 Capitan.

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

Lo que me encantaría saber

Q1. Banderas faltantes

¿Cómo es que ninguna extensión de kernel de terceros, y de hecho ningún archivo que creo manualmente en el interior /System/Library/Extensions, recibe una restrictedbandera o un com.apple.rootlessatributo, aunque la rootless.confregla parece indicar lo contrario?

Por ejemplo, una ls -dlOcadena de hp_fax_io.kextrevelaciones a lo largo del camino :

$ 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 actualicé desde Yosemite, el instalador de El Capitan eligió mover básicamente todo y su abuela a la cuarentena SIP en muchos casos.

Q2 Tiempo de ejecución

Si yo fuera a:

• arrancar en un volumen de recuperación,

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

  /usr/local/*
  

• y luego reiniciar nuevamente en el volumen original,

¿MacOS entonces apagaría todos los archivos /usr/local/con restrictedbanderas en el próximo reinicio?

Si no, entonces esto me lleva a mi última pregunta:

Q3. Propósito real

¿Para qué sirve rootless.conf realmente ?