Почему мой `rootless.conf` не всегда влияет на выбор SIP того, какие файлы обрабатываются флагом` limited`?

8

Что говорят источники

Как и все остальные, мой /System/Library/Sandbox/rootless.confфайл содержит следующие записи:

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

Все источники по теме, которую я нашел (пример 1 2 3 ), по-видимому, предполагают, что в соответствии с правилами rootless.conf, эти записи будут принудительно применяться во время загрузки, и их можно приблизительно интерпретировать следующим образом:

  1. Внутри /Systemиерархии никакому процессу не разрешено писать в любой файл или папку, кроме случаев, когда более конкретное правило предоставляет такой доступ;

  2. внутри/System/Library/Extensions любой процесс, имеющий права root, может создавать новые файлы и подпапки;

  3. однако никакому процессу не разрешается изменять или удалять любые существующие файлы или подпапки внутри /System/Library/Extensions.

Что я на самом деле наблюдаю

Однако, когда я посмотрел на фактическое содержимое /System/Library/Extensions, я с удивлением обнаружил несколько файлов и папок, которые, несмотря на активность SIP, прекрасно записываются и удаляются:

$ 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

Обратите внимание, что hp_Inkjet9_io_enabler.kextи hp_fax_io.kextявляются сторонними расширениями ядра, которые уже присутствовали в то время, когда я обновлялся до El Capitan (что я и сделал в мае 2016 года).

Когда я /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/pathsвыполняю поиск в списке исключений SIP по адресу , я также не вижу перечисленных там сторонних расширений:

$ 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

Я нашел более десятка расширений ядра, в которых также нет restrictedфлага и com.apple.rootlessатрибута; все затронутые расширения ядра, по-видимому, являются сторонними расширениями, которые я установил в течение последнего десятилетия, и, очевидно, пережили обновление El Capitan.

Что заставляет меня задуматься о следующих головоломках:

Что бы я хотел знать

Q1. Недостающие флаги

Как получилось, что никакое стороннее расширение ядра - и фактически ни один файл, который я создаю внутри, /System/Library/Extensions- никогда не получало restrictedфлаг или com.apple.rootlessатрибут, даже если rootless.confправило предписывает обратное?

Например, ls -dlOвдоль цепочки пути hp_fax_io.kextраскрывается:

$ 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

Я также помню, что в то время, когда я обновлял с Yosemite, установщик El Capitan во многих случаях решил переместить в основном все и их бабушку в карантин SIP.

Q2. Время исполнения

Если бы я был:

  • загрузиться в том для восстановления,

  • затем добавьте rootless.conf(к исходному объему) строку:

    /usr/local/*
    
  • и затем перезагрузите снова в исходный том,

Будет ли MacOS затенять все файлы /usr/local/с restrictedфлагами при следующей перезагрузке?

Если нет, то это подводит меня к моему последнему вопросу:

Q3. Фактическая цель

Какая цель на rootless.conf самом деле служит?

Synoli
источник
2
Конечно, хотелось бы, чтобы у кого-то в сообществе было несколько ответов или даже подсказок. У меня есть похожие вопросы.
CXJ
2
В соответствии с этим, не следует ли редактировать rootless.conf (отключить SIP, редактировать файл, повторно включить SIP) изменить какие каталоги защищены? На самом деле этого не происходит ... так что файл вообще читается?
Wowfunhappy