Почему мой `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 самом деле служит?


2
Конечно, хотелось бы, чтобы у кого-то в сообществе было несколько ответов или даже подсказок. У меня есть похожие вопросы.
CXJ

2
В соответствии с этим, не следует ли редактировать rootless.conf (отключить SIP, редактировать файл, повторно включить SIP) изменить какие каталоги защищены? На самом деле этого не происходит ... так что файл вообще читается?
Wowfunhappy
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.