Co mówią źródła

Jak każdy inny, mój /System/Library/Sandbox/rootless.confplik zawiera następujące wpisy:

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

Wszystkie źródła na temat, który znalazłem (przykład 1 2 3 ) wydają się sugerować, że zgodnie z zasadami rootless.conf, wpisy te będą egzekwowane w czasie uruchamiania i można je z grubsza interpretować w następujący sposób:

1. W /Systemhierarchii żaden proces nie może zapisywać do żadnego pliku lub folderu, z wyjątkiem sytuacji, gdy bardziej szczegółowa reguła zapewnia taki dostęp;

2. wewnątrz/System/Library/Extensions każdy proces mający uprawnienia administratora może tworzyć nowe pliki i podfoldery;

3. Jednak proces nie może modyfikować lub usunąć istniejące pliki lub podfoldery wewnątrz /System/Library/Extensions.

Co właściwie obserwuję

Jednak gdy spojrzałem na rzeczywistą zawartość /System/Library/Extensions, z zaskoczeniem odkryłem kilka plików i folderów, które pomimo aktywnego SIP są doskonale zapisywalne i usuwalne:

$ 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

Należy pamiętać, że hp_Inkjet9_io_enabler.kexti hp_fax_io.kextto osób trzecich rozszerzenia jądra, które były już obecne w czasie I uaktualniony do El Capitan (które ja w maju 2016).

Gdy przeszukuję listę wyjątków SIP w /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths, nie widzę tam wymienionych tutaj rozszerzeń innych firm:

$ 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

Znalazłem kilkanaście dodatkowych rozszerzeń jądra, które również nie mają restrictedflagi i com.apple.rootlessatrybutu; wszystkie rozszerzenia jądra, których dotyczy problem, wydają się być rozszerzeniami innych firm, które zainstalowałem w ciągu ostatniej dekady i prawdopodobnie przetrwały aktualizację El Capitan.

Co sprawia, że ​​zastanawiam się nad następującymi zagadkami:

Co chciałbym wiedzieć

Pytanie 1 Brakujące flagi

Jak to się dzieje, że żadne rozszerzenie jądra innej firmy - a właściwie żaden plik, który nie tworzę ręcznie w środku /System/Library/Extensions- nigdy nie otrzymuje restrictedflagi ani com.apple.rootlessatrybutu, nawet jeśli rootless.confreguła wydaje się wymagać inaczej?

Na przykład ls -dlOłańcuch ścieżki hp_fax_io.kextujawnia:

$ 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

Pamiętam również, że w momencie aktualizacji z Yosemite instalator El Capitan postanowił przenieść praktycznie wszystko i swoją babcię do kwarantanny SIP w wielu przypadkach.

Q2 Czas wykonania

Gdybym miał:

• uruchomić się w woluminie odzyskiwania,

• następnie dodaj rootless.conf(w oryginalnym wolumenie) wiersz:

  /usr/local/*
  

• a następnie ponownie uruchom komputer do oryginalnego woluminu,

czy system macOS odrzuciłby następnie wszystkie pliki /usr/local/z restrictedflagami przy następnym ponownym uruchomieniu?

Jeśli nie, to prowadzi mnie do mojego ostatniego pytania:

Pytanie 3 Rzeczywisty cel

Jaki cel rootless.conf faktycznie służy?