Quali fonti dicono

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

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

Tutte le fonti sull'argomento I ' trovato (esempio 1 2 3 ) sembra suggerire che in base alle regole di rootless.conf , tali voci verranno applicate al momento dell'avvio e possono essere interpretate in modo approssimativo come segue:

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

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

3. tuttavia, nessun processo è autorizzato a modificare o eliminare alcun file o sottocartella esistente all'interno di /System/Library/Extensions .

Ciò che effettivamente osservo

Tuttavia, quando ho visto i contenuti effettivi di /System/Library/Extensions , ho scoperto con mia sorpresa diversi file e cartelle che, nonostante SIP sia attivo, sono perfettamente scrivibili e cancellabili:

$ 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

Tieni presente che hp_Inkjet9_io_enabler.kext e hp_fax_io.kext sono estensioni del kernel di terze parti che erano già presenti al momento dell'aggiornamento a El Capitan (cosa che ho fatto a maggio 2016).

Quando cerco l'elenco delle eccezioni SIP a /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths , non vedo le estensioni di terze parti elencate qui:

$ 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 altre estensioni del kernel che mancano anche del flag restricted e dell'attributo com.apple.rootless ; tutte le estensioni del kernel interessate sembrano estensioni di terze parti che ho installato nel corso dell'ultimo decennio e apparentemente sono sopravvissute all'aggiornamento di El Capitan.

Il che mi fa riflettere sui seguenti enigmi:

Cosa mi piacerebbe sapere

Q1. Bandiere mancanti

Come mai nessuna estensione del kernel di terze parti - e di fatto nessun file che creo manualmente all'interno di /System/Library/Extensions - riceve mai un restricted flag o un com.apple.rootless attributo, anche se la regola rootless.conf sembra richiedere Al contrario?

Ad esempio, un ls -dlO lungo la catena del percorso di hp_fax_io.kext rivela:

$ 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 El Capitan ha scelto di spostare praticamente tutto e la loro nonna in quarantena SIP in molti casi.

Q2. Tempo di applicazione

Se dovessi:

• avvia in un volume di recupero,

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

  /usr/local/*
  

• e quindi riavvia nuovamente nel volume originale,

i macOS poi metterebbero tutti i file sotto /usr/local/ con restricted flags al prossimo riavvio?

In caso contrario, questo mi porta alla mia ultima domanda:

Q3. Scopo effettivo

Che scopo ha rootless.conf in realtà servire?