Модель безопасности macOS: SIP и целостность системы

[Artem_MacAdmin]

Зачем root, который не всемогущ

В мире Unix есть аксиома, к которой ты привык за годы: root может все. Перезаписать /bin/ls, подложить свой код в системную службу, снести защиту - root есть root. На macOS эта аксиома сломана намеренно. Даже если ты залогинился под uid 0, ты НЕ можешь записать в /System, не можешь подгрузить непроверенный код в чужой процесс, не можешь отключить защиту прямо из работающей системы. Это и есть System Integrity Protection - SIP, в народе "rootless". Если ты приходишь с Linux, первая встреча с SIP выглядит как баг: sudo дал, а "Operation not permitted" все равно прилетает. Это не баг. Это фундамент безопасности macOS, и в этом уроке мы разберем его механику до винтика - что такое sip mac на самом деле, как им управлять через csrutil, почему его опасно отключать и где проходит граница между "админ может" и "админ не должен".

Боль, которую SIP решает, простая и кровавая. До 2015 года любой троян, дорвавшийся до root (через дыру, через социалку, через кривой инсталлятор), получал полный контроль: прописывался в системные демоны, подменял системные бинарники, прятался так, что вычистить его можно было только переустановкой. SIP отрезал этот сценарий. Теперь компрометация root - это плохо, но это уже НЕ конец: системный том и системные процессы остаются неприкосновенными.



Как устроена многослойная защита: от кремния до файла

Безопасность macOS - это не один флаг, а стопка слоев, где каждый верхний опирается на нижний. Снизу вверх:

• Аппаратный корень доверия - на Apple Silicon это Secure Enclave и Boot ROM, прошитые в кремний на заводе. Их подменить нельзя физически.
• Secure Boot - цепочка проверки подписей при загрузке (LLB -> iBoot -> ядро). Каждое звено проверяет подпись следующего.
• Signed System Volume (SSV) - криптографическая печать системного тома: любой измененный байт системы ловится на лету.
• SIP - рантайм-ограничения для УЖЕ загруженной системы: что нельзя трогать, кому нельзя инжектить код.
• TCC, Gatekeeper, App Sandbox, System Extensions - слои уровня пользователя и приложений (про TCC и Gatekeeper - отдельные уроки).

Важно не путать SSV и SIP, их постоянно мешают. SSV защищает систему В ПОКОЕ и при загрузке - чтобы на диск нельзя было незаметно подсунуть модифицированную систему. SIP защищает систему В РАБОТЕ - чтобы запущенный процесс (даже от root) не смог нашкодить. Это разные механизмы, и отключаются они тоже по-разному, хотя на Apple Silicon связаны.

Signed System Volume: запечатанная система

Начиная с macOS Big Sur (11) система живет на отдельном томе, который смонтирован только на чтение. Но read-only - это слабая защита: примонтировал заново на запись и пиши. Поэтому Apple добавила сверху криптографию.

Каждый блок данных системного тома (включая метаданные файловой системы) хешируется SHA-256. Эти хеши собраны в дерево Меркла: хеш родителя зависит от хешей детей, и так до корня. Корневой хеш называется seal (печать) - он покрывает каждый байт системного тома. При чтении любого системного файла ядро на лету считает хеш прочитанного блока и сверяет с эталоном в метаданных. Не совпало - данные считаются подделанными и просто не отдаются процессу. Это и есть "запечатанная система": не просто read-only, а математически доказуемая неизменность.

Проверить состояние печати можно так:

Код: Выделить всё

csrutil authenticated-root status

Типичный вывод на штатной системе:

Код: Выделить всё

Authenticated Root status: enabled

Слово "enabled" тут значит, что печать активна и проверяется. Посмотреть саму печать тома и снапшот, с которого ты реально загружен:

Код: Выделить всё

diskutil apfs list | grep -A2 "Snapshot"

Загрузка идет НЕ с живого системного тома, а с его подписанного APFS-снапшота. Поэтому, кстати, изменения в /System не переживут перезагрузку, даже если ты их как-то протолкнул: при ребуте берется чистый запечатанный снапшот. Чтобы легитимно поменять систему (а это умеет только установщик обновлений Apple), создается новый снапшот, пересчитывается дерево хешей, новая печать подписывается - и только потом система соглашается с него грузиться. Сломать печать вручную означает, что система откажется загружаться в Full Security.

Secure Boot на Apple Silicon: три уровня и LocalPolicy

На Apple Silicon политика загрузки описывается файлом LocalPolicy. Это ключевое отличие от Intel и от прежних представлений: настройки безопасности загрузки (и SIP в том числе) хранятся НЕ в NVRAM, а в LocalPolicy. Файл подписан ключом, выведенным из уникальной идентичности Secure Enclave конкретной машины. Следствие, которое надо вбить в голову: LocalPolicy криптографически привязан к железу, его нельзя скопировать с одного Mac на другой. Снять диск, перенести в другой Mac и так протащить ослабленную политику - не выйдет.

Три уровня безопасности загрузки (Системные настройки -> в Recovery, утилита Startup Security Utility, либо bputil из Терминала):

• Full Security (полная) - поведение как у iPhone. Грузится только та версия macOS, которая была актуальной на момент установки. Глобальные старые подписи не принимаются. Это дефолт.
• Reduced Security (пониженная) - разрешены "глобальные" подписи, бандлящиеся с ОС. Позволяет грузить старые версии macOS и сторонние kext. У старых версий есть незакрытые дыры - отсюда "пониженная". Именно сюда падает система, когда ты разрешаешь сторонние Kernel Extensions.
• Permissive Security (разрешающая) - как Reduced, плюс iBoot принимает загрузочные объекты, подписанные Secure Enclave тем же ключом, что и LocalPolicy. Это режим для тех, кто собирает и грузит собственное ядро XNU. И именно в этот режим машина проваливается, когда ты отключаешь SIP.

Запомни связку: на Apple Silicon отключение SIP автоматически роняет загрузку до Permissive Security. Ты ослабляешь не одну галку - ты опускаешь весь уровень доверия загрузки до минимального. Посмотреть текущую политику без перезагрузки:

Код: Выделить всё

bputil -d

Команда требует пароль администратора и печатает разбор полей LocalPolicy: какой уровень security, разрешены ли сторонние kext, включен ли MDM-контроль и так далее. На штатной машине ты увидишь, что 3rd Party Kexts отключены, а security - полная.

csrutil: статус, флаги и почему disable - только из Recovery

Главный инструмент управления SIP - csrutil. Самая частая и безопасная команда:

Код: Выделить всё

csrutil status

На нормальной системе:

Код: Выделить всё

System Integrity Protection status: enabled.

Если SIP частично ослаблен, вывод станет подробным - "enabled (Custom Configuration)" с разбивкой по подсистемам:

Код: Выделить всё

System Integrity Protection status: enabled (Custom Configuration).

Configuration:
        Apple Internal: disabled
        Kext Signing: enabled
        Filesystem Protections: enabled
        Debugging Restrictions: enabled
        DTrace Restrictions: enabled
        NVRAM Protections: enabled
        BaseSystem Verification: enabled

Это и есть внутренняя анатомия sip mac: целостность не монолитна, а набор битов в NVRAM (на Intel) или в LocalPolicy (на Apple Silicon). Filesystem Protections запрещают запись в защищенные пути. Kext Signing требует подписи драйверов. Debugging Restrictions запрещают подключаться отладчиком и инжектить код в чужие, особенно системные, процессы - даже от root. DTrace Restrictions ограничивают трассировку системных процессов.

Теперь ключевое: csrutil disable из работающей системы НЕ сработает. Попробуешь - получишь:

Код: Выделить всё

csrutil: failed to modify system integrity protection value.
This tool needs to be executed from Recovery OS.

Это сделано осознанно. Если бы SIP можно было выключить из живой системы, любой эксплойт с root просто выключал бы SIP и делал что хочет - вся защита обнулилась бы. Поэтому единственный путь - загрузиться в Recovery, где требуется ФИЗИЧЕСКОЕ присутствие у машины (на Apple Silicon - зажать кнопку питания до появления опций загрузки), затем Утилиты -> Терминал, и только там:

Код: Выделить всё

csrutil disable

На Apple Silicon эта команда дополнительно потребует пароль администратора (того, кто владелец, holds a Secure Token) и предупредит, что роняет систему в Permissive Security. Это не формальность: ты переписываешь LocalPolicy, подписанную Secure Enclave. Без пароля владельца изменить ее нельзя - даже физический доступ к диску не помогает.

Если sip отключить понадобилось для одной конкретной задачи, используй точечное ослабление вместо полного выключения. Например, разрешить только сторонние kext, оставив остальное:

Код: Выделить всё

csrutil enable --without kext

Так Filesystem Protections, Debugging и прочее остаются включенными. Это куда здоровее, чем голый csrutil disable. Вернуть все на место:

Код: Выделить всё

csrutil enable

После любой манипуляции - перезагрузка и обязательная проверка csrutil status уже из обычной системы.

От kext к System Extensions и EndpointSecurity

Исторически драйверы и антивирусы лезли в ядро через Kernel Extensions (kext) - код в kernelspace. Один кривой kext роняет всю систему в панику, плюс это лакомый вектор для атак. Поэтому Apple вынесла эту функциональность в userspace через System Extensions: тот же функционал (сетевые фильтры, защита эндпоинта, драйверы), но в изолированном процессе пользователя, без права уронить ядро.

Для антивирусов и EDR есть отдельный фреймворк EndpointSecurity: вместо инжекта в ядро решение подписывается специальным entitlement от Apple и через legalную API получает поток событий (запуск процессов, открытие файлов, fork/exec) и может их разрешать или блокировать. Так работают современные защитные продукты на macOS, не ломая SIP.

Когда приложение хочет поставить System Extension, ты видишь то самое окно "Системное расширение заблокировано", и одобрить его надо вручную в Системные настройки -> Основные -> Вход и расширения (или Конфиденциальность и безопасность). Это и есть ответ на вопрос "почему macOS постоянно просит подтверждения": система реализует принцип наименьших привилегий. По умолчанию у кода прав минимум; каждое расширение прав - сетевой фильтр, доступ к диску, загрузка расширения - требует явного осознанного согласия человека у клавиатуры. Не разработчик решает за тебя - решаешь ты.

Список загруженных системных расширений:

Код: Выделить всё

systemextensionsctl list

Вывод покажет категории (например com.apple.system_extension.endpoint_security), team identifier вендора, имя бандла и состояние "activated enabled". Если видишь незнакомый team id в endpoint_security - это повод разобраться, что за софт у тебя слушает все запуски процессов.

Что админу можно, а что нельзя

Граница простая. Можно и нужно: ставить и одобрять System Extensions от доверенных вендоров, управлять политикой загрузки через MDM, читать статус (csrutil status, bputil -d, systemextensionsctl list), точечно ослаблять SIP в Recovery под конкретную задачу с последующим возвратом. Нельзя (и система не даст): писать в /System и в защищенные части /Library из работающей ОС, инжектить код в системные процессы, грузить неподписанные kext в Full Security, ломать печать SSV и рассчитывать, что система загрузится, скопировать ослабленную LocalPolicy с другой машины.

Типичные грабли:

• "sudo дал, а Operation not permitted". Это не права POSIX, это SIP. Ищешь способ записать в защищенный путь - почти всегда ты решаешь не ту задачу. Системные файлы трогать не надо; клади свое в /usr/local или /opt/homebrew.
• Забыл, что отключил SIP. Машина месяцами живет в Permissive Security, владелец не в курсе. Возьми за правило: после любой задачи в Recovery сразу csrutil enable и проверка статуса.
• Путают том и снапшот. "Я отредактировал файл в /System, перезагрузился - изменений нет." Конечно: грузишься с запечатанного снапшота, а не с живого тома.
• Отключают SIP "на всякий случай" под старый софт. Почти всегда есть точечный путь: csrutil enable --without kext, или вообще сторонний kext через одобрение в Reduced Security, без полного отключения SIP.
• Думают, что SIP - это про вирусы вообще. SIP не антивирус. Он не мешает малвари работать в твоей домашней папке. Он мешает ей закрепиться в системе и стать невидимой.

Мини-лаба: пощупать SIP руками (без отключения)

Все шаги безопасны и НЕ требуют выключать защиту.

• Глянь общий статус:

  Код: Выделить всё

  csrutil status

  Запиши, что увидел (enabled - норма).
• Проверь печать системного тома:

  Код: Выделить всё

  csrutil authenticated-root status

• Разбери политику загрузки (Apple Silicon, попросит пароль):

  Код: Выделить всё

  bputil -d

  Найди в выводе уровень security и строку про 3rd party kexts.
• Посмотри системные расширения и их вендоров:

  Код: Выделить всё

  systemextensionsctl list

• Убедись, что SIP реально работает. Попробуй (от sudo) создать файл в защищенном пути - команда должна отказать:

  Код: Выделить всё

  sudo touch /System/sip_test 2>&1

  Ожидаемо: "Operation not permitted". Это SIP, а не права. Ничего удалять не надо - файл не создался.
• Сравни с незащищенным путем:

  Код: Выделить всё

  sudo touch /usr/local/sip_test && ls -l /usr/local/sip_test

  Тут запись пройдет. Прибери за собой:

  Код: Выделить всё

  sudo rm /usr/local/sip_test

Контрольные вопросы

• Почему csrutil disable нельзя выполнить из работающей системы и какой ровно отказ ты получишь? Как это связано с моделью угроз "эксплойт получил root"?
• Чем отличается Signed System Volume от SIP - что именно защищает каждый и в какой момент (покой/загрузка против рантайма)?
• На Apple Silicon до какого уровня безопасности загрузки падает машина при полном отключении SIP и почему ослабленную LocalPolicy нельзя перенести на другой Mac?
• Чем System Extensions и EndpointSecurity лучше старых kext с точки зрения целостности системы и принципа наименьших привилегий?

Итог

SIP - это не галка-параноик, а намеренный слом всемогущества root: даже с uid 0 система остается неприкосновенной. Под ним лежит запечатанный криптографией системный том (SSV) и проверенная подписями загрузка (Secure Boot с LocalPolicy на Apple Silicon). Управление - через csrutil, и принципиально только из Recovery, с физическим присутствием и паролем владельца. Отключать sip без острой нужды нельзя: на Apple Silicon это роняет всю загрузку в Permissive Security. Современный путь для драйверов и защиты - System Extensions и EndpointSecurity в userspace, а постоянные запросы подтверждений - это и есть принцип наименьших привилегий в действии. Запомни границу: читать статус и точечно настраивать - можно; ломать целостность системы - нельзя, и система тебе это докажет.

[midnightlurker]

Дошло наконец почему sudo не дает писать в /System - это SIP а не права. Полез менять chmod, а надо было просто не лезть в системный том. Спасибо за разбор csrutil status, теперь читаю вывод осмысленно.

[nixos12]

Вопрос: у нас парк на M2 под MDM, можно ли разрешить сторонний kext одного вендора но не ронять всю машину в Permissive? Правильно понял что это Reduced Security через одобрение, а полный csrutil disable не нужен?