Lo que dicen las fuentes
Como todos los demás, mi /System/Library/Sandbox/rootless.conf
archivo 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:
Dentro de la
/System
jerarquí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;adentro
/System/Library/Extensions
, cualquier proceso que tenga privilegios de root puede crear nuevos archivos y subcarpetas;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.kext
y hp_fax_io.kext
son 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 restricted
bandera y el com.apple.rootless
atributo; 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 restricted
bandera o un com.apple.rootless
atributo, aunque la rootless.conf
regla parece indicar lo contrario?
Por ejemplo, una ls -dlO
cadena de hp_fax_io.kext
revelaciones 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 restricted
banderas 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 ?
fuente