Что такое «безродная» функция в El Capitan на самом деле?

Во-первых: название «без root» вводит в заблуждение, поскольку учетная запись root все еще существует, и вы все еще можете получить к ней доступ (официальное название «Защита целостности системы» является более точным). На самом деле это ограничивает возможности учетной записи root, так что даже если вы станете root, у вас не будет полного контроля над системой. По сути, идея состоит в том, что вредоносным программам слишком просто получить root-доступ (например, предоставив пользователю диалоговое окно авторизации, которое заставит пользователя рефлекторно вводить пароль администратора). SIP добавляет еще один уровень защиты, через который вредоносное ПО не сможет проникнуть, даже получив root-права. Плохая часть этого, конечно, в том, что это также должно относиться к вещам, которые вы делаете намеренно. Но ограничения, которые он накладывает на root, не так уж плохи; они не мешают большинству «нормальных»

Вот что он ограничивает, даже от root:

• Вы не можете ничего изменить в /System, /bin, /sbinили /usr(кроме /usr/local); или любое из встроенных приложений и утилит. Только установщик и обновление программного обеспечения могут изменить эти области, и даже они делают это только при установке пакетов, подписанных Apple. Но поскольку обычные настройки в стиле OS X входят /Library(или ~/Library, или /Applications), а настройки в стиле Unix (например, Homebrew) входят /usr/local(или иногда /etcили /opt), это не должно иметь большого значения. Он также предотвращает запись на уровне блоков на загрузочный диск, поэтому вы не можете обойти его таким образом.

  Полный список каталогов с ограниченным доступом (и таких исключений, как /usr/localи некоторые другие) находится в /System/Library/Sandbox/rootless.conf. Конечно, этот файл сам находится в зоне ограниченного доступа.

  При обновлении до El Capitan все «неавторизованные» файлы перемещаются из областей с ограниченным доступом в файлы /Library/SystemMigration/History/Migration-(some UUID)/QuarantineRoot/.

• Вы не можете подключаться к системным процессам (например, тем, которые выполняются из этих системных местоположений) для таких вещей, как отладка (или изменение загружаемых динамических библиотек, или некоторые другие вещи). Опять же, не так уж и много; разработчики по-прежнему могут отлаживать свои собственные программы.

  Это блокирует некоторые важные вещи, такие как внедрение кода во встроенные приложения Apple (в частности, в Finder). Это также означает, что dtraceинструменты для системного мониторинга (например opensnoop, ) не смогут отслеживать и сообщать о многих системных процессах.

• Вы не можете загружать расширения ядра (kexts), если они не подписаны должным образом (т. е. Apple или одобренным Apple разработчиком). Обратите внимание, что это заменяет старую систему принудительной подписи kext (и старые способы ее обхода). Но начиная с версии 10.10.4 у Apple появился способ включить поддержку обрезки для сторонних твердотельных накопителей , причина № 1 для использования неподписанных кекстов исчезла.

• Начиная с Sierra (10.12), некоторые параметры конфигурации launchd нельзя изменить (например, некоторые демоны запуска нельзя выгрузить).

• Начиная с Мохаве (10.14), доступ к личной информации пользователей (электронная почта, контакты и т. д.) ограничен приложениями, которым пользователь разрешил доступ к этой информации. Обычно это считается отдельной функцией (называемой защитой личной информации или TCC), но она основана на SIP, и отключение SIP также отключает ее. См. «Что и как реализует macOS Mojave для ограничения доступа приложений к персональным данным?»

• Начиная с Catalina (10.15), защита большинства системных файлов усилена за счет их хранения на отдельном томе только для чтения. Это не является строго частью SIP и не отключается путем отключения SIP. См.: Презентация WWDC «Что нового в файловых системах Apple [Catalina]» и «Что такое /System/Volumes/Data?» .

• Начиная с Big Sur (11.x), доступный только для чтения системный том теперь является «запечатанным системным томом» (смонтированным моментальным снимком, а не обычным томом), поэтому вносить в него изменения еще сложнее. См.: статья компании Eclectic Light Company «Схема загрузочного тома Big Sur» .

Если вам не нужны эти ограничения — либо потому, что вы хотите изменить свою систему сверх того, что это позволяет, либо потому, что вы разрабатываете и отлаживаете что-то вроде кекстов, которые нецелесообразны при этих ограничениях, вы можете отключить SIP. В настоящее время для этого требуется перезагрузка в режиме восстановления и запуск команды csrutil disable(и вы можете аналогичным образом снова включить ее с помощью csrutil enable).

Изменение системного тома в Catalina требует отключения SIP, затем монтирования тома с доступом для записи (рекомендуется перезагрузка и повторное включение SIP). В Big Sur требуются дополнительные действия, чтобы отключить аутентификацию системного тома перед внесением изменений, а затем создать новый снапшот .

Вы также можете выборочно отключить части SIP. Например, csrutil enable --without kextотключит ограничение расширения ядра SIP, но оставит остальные средства защиты.

Но, пожалуйста, остановитесь и подумайте, прежде чем отключать SIP, даже временно или частично: действительно ли вам нужно отключить его или есть лучший (совместимый с SIP) способ сделать то, что вы хотите? Вам действительно нужно что-то изменить /System/Libraryили /binчто-то еще, или это может быть лучше, например /Libraryили и /usr/local/binт. Д.? SIP может «чувствовать» ограничение, если вы к нему не привыкли, и есть несколько законных причин для его отключения, но многое из того, что он применяет, в любом случае является просто лучшей практикой.

Чтобы подчеркнуть важность того, чтобы SIP оставался включенным как можно дольше, рассмотрим события 23 сентября 2019 года. Google выпустил обновление для Chrome, которое пыталось заменить символическую ссылку с /varна /private/var. В большинстве систем SIP заблокировал это, и никаких негативных последствий не возникло. В системах с отключенным SIP это приводило к поломке и невозможности загрузки macOS. Наиболее распространенной причиной отключения SIP была загрузка неутвержденных (/неправильно подписанных) расширений ядра (в частности, видеодрайверов); если бы они только отключили ограничение kext, они бы не пострадали. См . официальную ветку поддержки Google , вопросы и ответы суперпользователя и статью Ars Technica .

Ссылки и дополнительная информация: презентация WWDC на тему «Безопасность и ваши приложения» , хорошее объяснение Эльдада Эйлама на quora.com , обзор Ars Technica El Capitan и статья службы поддержки Apple о SIP , а также подробное описание Рича Траутона ( Rich Trouton ). который также разместил ответ на этот вопрос ).

Для меня это означает, что DTrace больше не работает.

DTrace похож на ptrace/strace в Linux тем, что позволяет вам видеть, что процесс говорит ядру. Каждый раз, когда процесс хочет открыть файл, записать файл или открыть порт и т. д., он должен обратиться к ядру. В Linux этот процесс мониторинга происходит за пределами ядра в «пространстве пользователя», поэтому права доступа достаточно детализированы. Пользователь может отслеживать свои собственные приложения (чтобы исправлять ошибки, находить утечки памяти и т. д.), но для наблюдения за процессом другого пользователя ему необходимо иметь права root.

Однако DTrace в OSX работает на уровне ядра, что делает его гораздо более производительным и мощным, однако ему требуется root-доступ, чтобы добавлять свои зонды в ядро ​​и, таким образом, делать что-либо. Пользователь не может отслеживать свои собственные процессы, не будучи root, но как root он может наблюдать не только за своими собственными процессами, но фактически за ВСЕМИ процессами в системе одновременно. Например, вы можете просмотреть файл (с помощью iosnoop) и посмотреть, какой процесс его читает. Это одна из самых полезных функций для обнаружения вредоносных программ. Поскольку ядро ​​также имеет дело с сетевым вводом-выводом, здесь то же самое. Wireshark обнаруживает необычную сетевую активность, DTrace сообщает вам процесс, отправляющий данные, даже если он так же встроен в систему, как и само ядро.

Однако, что касается El Capitan, Apple намеренно предотвратила работу DTrace, поскольку он был специально нацелен и выделен как что-то, что ограничивает SIP. Зачем им это делать? Что ж, ранее Apple модифицировала свое ядро ​​и DTrace, чтобы позволить некоторым процессам отказаться от мониторинга через DTrace (что расстроило многих исследователей безопасности в то время, поскольку некоторые процессы теперь были недоступны даже для root, включая вредоносные программы). Их причиной этого была защита DRM в таких приложениях, как iTunes, поскольку теоретически кто-то может использовать DTrace и извлекать данные без DRM из памяти процессов.

Тем не менее, был важный обходной путь, который позволил исследователям продолжать выполнять свою работу, и заключался в том, чтобы изменить ядро, чтобы оно игнорировало этот флаг отказа, поэтому DTrace все еще можно было использовать в этих процессах. На самом деле это было действительно здорово, потому что программы, пытающиеся избежать обнаружения, теперь загорались этим флагом отсутствия DTrace. Все, что Apple или плохие парни хотели скрыть, теперь было на виду...

Но сейчас это не работает, так как это влияет на вас? Ну, это повлияет на вас как прямо, так и косвенно. Напрямую, это ограничит вашу способность контролировать вашу систему. Большое количество низкоуровневых инструментов системного администрирования и мониторинга (на которых основаны инструменты более высокого уровня) больше не будут работать. Однако косвенный эффект будет намного больше — специалисты по безопасности полагаются на глубокий доступ к системе для обнаружения самых серьезных угроз. Мы просто больше не можем этого делать. При анализе вредоносных программ очень важно, чтобы они не знали, что работают в отладчике или приманке. Отключение SIP сообщает всему программному обеспечению, как от злоумышленников, так и от Apple, что за этой системой наблюдают. Больше не нужно смотреть на наблюдателей. Если бы SIP был связан с безопасностью, они могли бы информировать пользователей о root — вместо этого они удалили его. В конечном итоге это означает, что Apple заменила барьер безопасности «все и все» в корневом пароле на механизм защиты SIP «все и все». Или, если вы хорошо разбираетесь в социальной инженерии, пароль root с перезагрузкой...

Есть еще вот это:

Защита целостности системы (SIP) — это общая политика безопасности, целью которой является предотвращение изменения системных файлов и процессов третьими лицами. Для этого в нем используются следующие концепции:

• Защита файловой системы
• Защита расширения ядра
• Защита во время работы

Защита файловой системы

SIP запрещает сторонам, кроме Apple, добавлять, удалять или изменять каталоги и файлы, хранящиеся в определенных каталогах:

/bin
/sbin
/usr
/System

Apple указала, что разработчикам доступен доступ к следующим каталогам:

/usr/local
/Applications
/Library
~/Library

Все каталоги в /usrкроме /usr/localзащищены SIP.

Можно добавлять, удалять или изменять файлы и каталоги, защищенные SIP, с помощью установочного пакета, подписанного собственным центром сертификации Apple. Это позволяет Apple вносить изменения в части ОС, защищенные SIP, без необходимости изменять существующие средства защиты SIP.

Рассматриваемый центр сертификации зарезервирован Apple для собственного использования; Установочные пакеты, подписанные идентификатором разработчика, не могут изменять файлы или каталоги, защищенные SIP.

Чтобы определить, какие каталоги защищены, Apple в настоящее время определила два файла конфигурации в файловой системе. Первичный находится в следующем месте:

/System/Library/Sandbox/rootless.conf

где rootless.confперечислены все приложения и каталоги верхнего уровня, которые защищает SIP.

Приложения

SIP защищает основные приложения, которые OS X устанавливает в Applications and Application Utilities. Это означает, что больше нельзя будет удалить приложения, которые устанавливает OS X, даже из командной строки при использовании привилегий root.

Каталоги

SIP также защищает ряд каталогов и символических ссылок снаружи, /Applicationsа верхний уровень этих каталогов также указан в rootless.conf.

В дополнение к средствам защиты Apple также определила некоторые исключения для защиты SIP в файле rootless.conf, и эти исключения отмечены звездочками. Эти исключения из защиты SIP означают, что в этих местах можно добавлять, удалять или изменять файлы и каталоги.

Среди этих исключений следующие:

• /System/Library/User Template- где OS X хранит каталоги шаблонов, которые она использует при создании домашних папок для новых учетных записей.
• /usr/libexec/cups- где OS X хранит информацию о конфигурации принтера

Apple считает этот файл своим и любые изменения в нем третьих лиц будут перезаписаны Apple.

Чтобы увидеть, какие файлы были защищены SIP, используйте lsкоманду с заглавной O в Терминале:

ls -O

Файлы, защищенные SIP, будут помечены как ограниченные .

Важно знать, что даже если символическая ссылка защищена SIP, это не обязательно означает, что каталог, на который они ссылаются, защищен SIP. На корневом уровне загрузочного диска OS X El Capitan есть несколько защищенных SIP символических ссылок, указывающих на каталоги, хранящиеся внутри корневого каталога с именем private.

Однако при проверке содержимого privateкаталога каталоги, на которые указывают эти символические ссылки, не защищены SIP, и как они, так и их содержимое могут быть перемещены, отредактированы или изменены процессами, использующими привилегии root.

В дополнение к списку исключений SIP, установленному Apple rootless.conf, существует второй список исключений SIP. Этот список включает ряд каталогов и имен приложений для сторонних продуктов. Как и в случае rootless.conf, этот список исключений принадлежит Apple, и любые изменения в нем третьих сторон будут перезаписаны Apple.

/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

Защита во время работы

Средства защиты SIP не ограничиваются защитой системы от изменений файловой системы. Есть также системные вызовы, функциональность которых теперь ограничена.

• Ошибка task_for_pid()/processor_set_tasks() с EPERM
• Специальные порты Mach сбрасываются в exec(2)
• переменные среды dyld игнорируются
• Зонды DTrace недоступны

Однако SIP не блокирует проверку разработчиком собственных приложений во время их разработки. Инструменты Xcode по-прежнему позволят проверять и отлаживать приложения в процессе разработки.

Для получения более подробной информации об этом я бы порекомендовал взглянуть на документацию Apple для разработчиков по SIP .

Защита расширения ядра

SIP блокирует установку неподписанных расширений ядра. Чтобы установить расширение ядра в OS X El Capitan с включенным SIP, расширение ядра должно:

1. Быть подписанным с идентификатором разработчика для сертификата Signing Kexts
2. Установить в /Library/Extensions

При установке неподписанного расширения ядра сначала необходимо отключить SIP.

Для получения дополнительной информации об управлении SIP перейдите по ссылке ниже:

Защита целостности системы — добавление еще одного уровня в модель безопасности Apple.