Что такое «безродная» особенность в El Capitan, на самом деле?

Я только что узнал о функции «Rootless» в El Capitan, и я слышу такие вещи, как «Нет пользователя root», «Ничто не может изменить /System» и «Мир закончится, потому что мы не можем получить root».

Что такое «безрукая» особенность El Capitan на техническом уровне? Что это на самом деле означает для пользовательского опыта и опыта разработчика? Будет ли sudo -sработать, и если да, то как изменится опыт использования оболочки root?

Во-первых: название «rootless» вводит в заблуждение, поскольку все еще есть учетная запись 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), некоторые параметры конфигурации запуска не могут быть изменены (например, некоторые демоны запуска не могут быть выгружены).

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

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

Вы также можете выборочно отключить части 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 поддержки , суперпользователь Q & A на нем , и статью Ars Technica .

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

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

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

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

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

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

Но это не работает сейчас, так как это влияет на вас? Ну, это повлияет на вас как прямо, так и косвенно. Напрямую, это ограничит вашу способность контролировать вашу систему. Большое количество низкоуровневых инструментов системного администрирования и мониторинга (на которых основаны высокоуровневые инструменты) больше не будет работать. Однако косвенный эффект будет гораздо более значительным - специалисты по безопасности полагаются на глубокий доступ к системе для обнаружения самых опасных видов угроз. Мы просто больше не можем этого делать. При анализе вредоносных программ крайне важно, чтобы они не знали, что они работают в отладчике или honeypot. Отключение 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 для собственного использования; Пакеты установщика, подписанные ID разработчика, не могут изменять файлы или каталоги, защищенные SIP.

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

/System/Library/Sandbox/rootless.conf

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

Приложения

SIP защищает основные приложения, которые OS X устанавливает в приложения и служебные программы. Это означает, что больше не будет возможности удалять приложения, которые устанавливает 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
• Специальные порты Маха сбрасываются на exec (2)
• переменные окружения dyld игнорируются
• Датчики DTrace недоступны

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

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

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

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

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

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

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

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