Cosa dicono le fonti

Come tutti gli altri, il mio /System/Library/Sandbox/rootless.conffile contiene le seguenti voci:

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

Tutte le fonti sull'argomento che ho trovato (esempio 1 2 3 ) sembrano suggerire che, secondo le regole di rootless.conf, tali voci verranno applicate all'avvio e possono essere interpretate approssimativamente come segue:

1. All'interno della /Systemgerarchia , nessun processo è autorizzato a scrivere su alcun file o cartella, tranne quando una regola più specifica concede tale accesso;

2. all'interno/System/Library/Extensions , qualsiasi processo che ha i privilegi di root è autorizzato a creare nuovi file e sottocartelle;

3. tuttavia, nessun processo è autorizzato a modificare o eliminare eventuali file o sottocartelle esistenti all'interno /System/Library/Extensions.

Quello che effettivamente osservo

Tuttavia, quando ho guardato il contenuto reale di /System/Library/Extensions, ho scoperto con mia sorpresa diversi file e cartelle che, nonostante SIP fosse attivo, sono perfettamente scrivibili ed eliminabili:

$ 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

Si noti che hp_Inkjet9_io_enabler.kexte hp_fax_io.kextsono estensioni del kernel di terze parti che erano già presenti al momento ho aggiornato a El Capitan (che ho fatto maggio 2016).

Quando cerco l'elenco delle eccezioni SIP su /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths, non vedo neanche quelle estensioni di terze parti elencate lì:

$ 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

Ho trovato oltre una dozzina di estensioni del kernel che mancano anche della restrictedbandiera e com.apple.rootlessdell'attributo; tutte le estensioni del kernel interessate sembrano essere estensioni di terze parti che ho installato nel corso dell'ultimo decennio e apparentemente sono sopravvissute all'aggiornamento di El Capitan.

Il che mi lascia interrogandomi sui seguenti enigmi:

Cosa mi piacerebbe sapere

Q1. Bandiere mancanti

Come mai nessuna estensione del kernel di terze parti - e in realtà nessun file che creo manualmente all'interno /System/Library/Extensions- riceve mai un restrictedflag o un com.apple.rootlessattributo, anche se la rootless.confregola sembra imporre il contrario?

Ad esempio, un ls -dlOlungo la catena del percorso di hp_fax_io.kextrivela:

$ 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

Ricordo anche che al momento dell'aggiornamento da Yosemite, l'installer di El Capitan ha scelto di spostare praticamente tutto e la nonna in quarantena SIP in molti casi.

Q2. Tempo di esecuzione

Se dovessi:

• avviare in un volume di recupero,

• quindi aggiungi a rootless.conf(sul volume originale) una riga:

  /usr/local/*
  

• e quindi riavviare nuovamente nel volume originale,

macOS eliminerebbe quindi tutti i file sotto /usr/local/con restrictedflag al prossimo riavvio?

Altrimenti, questo mi porta alla mia ultima domanda:

Q3. Scopo reale

A quale scopo serve rootless.conf effettivamente ?