Стороннее расширение ядра мешало успешной загрузке системы mac os

Итак, одна из новинок High Sierra – это некий SKEL (Secure Kernel Extension Loading), он же UAKEL (User Approved Kernel Extension Loading).

Что это такое и почему это важно для системных администраторов?
Кратко, – новый механизм предназначен для защиты системы (и в конечном счете пользователя и его данных).
Он может слегка усложнить установку ряда приложений в компаниях, так как многие компании все еще не используют MDM (а зря).

UAKEL добавился к набору других инструментов безопасности, встроенных в систему – SIP (System Integrity Protection), Gatekeeper, XProtect и MRT.
Вот что о нем рассказывает Apple (я даю ссылку на русскую документацию, но на момент написания она еще не переведена).

Как это работает?
При установке расширений ядра, они не заработают сами по себе, а потребуют участия пользователя.
При обычной установке ПО об этом будет честно сообщено пользователю (как на картинке выше).
Как правило, обычный пользователь просто кликнет в этом сообщении на ОК, не прочитав его. Соответственно ПО или какой-то его функционал не будет работать, оборудование не будет видеться и т.д.. А пользователь будет недоумевать и/или негодовать.

Если же пользователь внимательно прочитает сообщение на экране, он откроет System Preferences (Системные настройки) / Security (Защита и безопасность) и щелкнет по появившейся кнопке Allow в нижней части экрана.

Кнопка тут же исчезнет. Так как нам платят за объем в статьи в килобайтах, я проиллюстрирую этот момент:

Все очень просто. И, как мы видим, для этого вовсе не нужны админские права.
Это сообщение (System software from developer was blocked from loading) и кнопка Allow будут показываться в контрольной панели в течение 30 минут или при следущей попытке загрузить это расширение ядра, например в течение 30 минут после загрузки Мака. Если вы так и не нажмете Allow за эти полчаса, они исчезнут (до следующей перезагрузки).

Важно отметить, что это не касается расширений, которые уже стояли на Маке при обновлении до macOS High Sierra. То что работало – продолжить работать (если само ПО совместимо с 10.13, конечно).
И это не касается обновления (замены) уже установленных расширений. То есть, если вы обновили драйверы ATTO, то кликать нигде не придется.

Что же тут страшного?
Страшного нет ничего, но возможно, что это будет неудобного господам админам. Представьте, что вы поддерживаете школу и вам нужно установить ПО для виртуализации на 400 Макбуков. Или вы устанавливаете в архитектурной студии драйвер Wacom на пятьдесят Маков, что мы и делаем на наших картинках. Или у вас видеопроизводство, вы используете Fiber-Channel карты ATTO и вам нужно установить для них драйверы.
Во всех этих случаях расширения ядра (kext), которые при установке ПО вами тем или иным способом (например, с помощью munki или хотя бы Apple Remote Desktop) окажутся в /Library/Extensions просто-напросто не заработают. ПО будет установлено. Компьютер перезагрузится. Кнопка Allow сиротливо повисит 30 минут молча в System Preferences. А пользователь будет просто недоумевать и/или негодовать.

Что делать?
Есть несколько вариантов. Во-первых, мы можем тем или иным способом пробежаться по 400 Макам и нажать Allow.
Во-вторых, мы можем проинструктировать пользователей.
В-третьих, если Мак введен в MDM, этот механизм отключается (“видимо у меня есть админы и они знают, что делают” думает Мак). Кстати, в ближайших обновлениях High Sierra планируется добавить функционал для управления списком разрешенных расширений ядра с помощью MDM.
В-четвертых, мы можем отключить этот механизм.
Для отключения UAKEL, как и в случае с отключением SIP, нужно загрузиться с раздела восстановления и использовать команду spctl (System Protection control).

Теперь заглянем чуть-чуть под капот.
Во-первых, кое-какая информация есть на developer.apple.com.
Когда пользователь разрешает расширению ядра работать, нажимая на кнопочку Allow, информация об этом добавляется в базу sqlite /var/db/SystemPolicyConfiguration/KextPolicy
Мы можем посмотреть в базе на TeamID (идентификаторы разработчика).

Кроме того, мы можем заранее разрешить нужные TeamID.
Это можно сделать в терминале при загрузке в режим восстановления используя ту же spctl. Добавим идентификатор Wacom:

Изменения будут записаны в NVRAM и мы можем их посмотреть с помощью команды nvram.
Я не буду перезагружаться, чтобы добавить идентификатор, а затем сделать снимок экрана и напишу пример по памяти:

Слабое место – эти настройки будут сброшены при сбросе NVRAM (знаменитое “показать Маку козу” – Command-Option-P-R).

Почему Apple добавили такую защиту? Ведь нам неизвестны malware в виде расширений ядра. Но это нам они неизвестны…
А кроме того, магистральное направление движения Apple указывает на то, что…
Ладно, магистральное направление – это вопрос для долгого чаепития, а впереди у нас еще зима с ее длинными темными вечерами.

Источник

Расширения ядра в macOS

Начиная с macOS 11 , если сторонние расширения ядра разрешены, их невозможно загрузить в ядро по запросу. Вместо этого они объединяются во вспомогательную коллекцию ядра (AuxKC), которая загружается в процессе загрузки компьютера. На компьютере Mac с чипом Apple измерение AuxKC прописывается в политике LocalPolicy (на оборудовании предыдущих поколений измерение AuxKC хранилось в томе данных). Перестроение AuxKC требует подтверждения пользователя и перезапуска macOS для загрузки внесенных изменений в ядро. Кроме того, для параметра безопасной загрузки должен быть выбран сниженный уровень безопасности.

Важно! В macOS больше не рекомендуется использовать расширения ядра. Расширения ядра подвергают риску целостность и надежность операционной системы, поэтому Apple рекомендует отдать предпочтение решениям, которые не требуют расширений.

Расширения ядра на компьютере Mac с чипом Apple

На компьютере Mac с чипом Apple расширения ядра должны быть разрешены явным образом с помощью длительного нажатия кнопки питания при запуске для перехода в режим одной истинной среды восстановления (1TR), последующего перехода на сниженный уровень безопасности и установки соответствующего флажка для активации расширений ядра. Для этого также требуется ввести пароль администратора для авторизации перехода в режим сниженной безопасности. Использование 1TR в сочетании с паролем усложняет для проникшего в macOS злоумышленника, использующего только программное обеспечение, внедрение расширений ядра в macOS, которые затем можно было бы использовать для получения прав уровня ядра.

После авторизации пользователем загрузки расширений ядра применяется поток утвержденной пользователем загрузки расширений ядра. Он предназначен для авторизации установки расширений ядра. Авторизация, используемая для указанного выше потока, также применяется для перехвата хэша SHA384 списка авторизованных пользователем расширений ядра (UAKL) в политике LocalPolicy. Затем процесс управления ядром ( kmd ) подтверждает включение в AuxKC только тех расширений ядра, которые указаны в списке UAKL.

Если включена функция защиты целостности системы (SIP), выполняется проверка подписи каждого расширения ядра, прежде чем оно будет включено в AuxKC.

Если функция SIP выключена, подпись расширения ядра не проверяется.

Этот подход позволяет выполнять потоки низкого уровня безопасности, с помощью которых разработчики или пользователи, не участвующие в программе Apple Developer Program, тестируют расширения ядра перед их подписью.

После создания AuxKC ее измерение отправляется в Secure Enclave на подпись и включение в структуру данных Image4, которая подлежит проверке загрузчиком iBoot во время загрузки. В процессе формирования AuxKC также создается ответ расширения ядра. Этот ответ содержит список расширений ядра, которые фактически были включены в AuxKC, поскольку набор может оказаться поднабором UAKL, если были обнаружены запрещенные расширения ядра. Хэш SHA384 структуры данных Image4 коллекции AuxKC и ответ расширения ядра включаются в файл LocalPolicy. Хэш Image4 AuxKC используется для дополнительной проверки загрузчиком iBoot во время загрузки, что помогает исключить загрузку старого файла Image4 AuxKC, подписанного Secure Enclave, с новой политикой LocalPolicy. Ответ расширения ядра используется такими подсистемами, как Apple Pay , для определения наличия любых загруженных расширений ядра, которые могут повлиять на достоверность macOS. Если такие расширения обнаруживаются, функциональные возможности Apple Pay могут быть отключены.

Альтернативы расширениям ядра (macOS 10.15 и новее)

Работая с macOS 10.15 , разработчики могут расширять возможности macOS путем установки и использования расширений системы, которые исполняются в пользовательском пространстве, а не на уровне ядра. Благодаря работе в пользовательском пространстве расширения системы повышают стабильность и безопасность macOS. Несмотря на то, что расширения ядра по определению имеют полный доступ ко всей операционной системе, расширениям, работающим в пользовательском пространстве, предоставляются только те права, которые необходимы для выполнения их конкретной функции.

Разработчики могут использовать доступные программные среды, включая DriverKit, EndpointSecurity и NetworkExtension, для создания драйверов USB и драйверов интерфейса пользователя, инструментов защиты конечных точек (например, агентов предотвращения потери данных и других агентов конечных точек), а также инструментов VPN и сетевых средств, причем для этого не потребуются расширения ядра. Сторонние агенты безопасности должны использоваться только в том случае, если они используют эти API или имеют продуманную схему перехода к ним от расширений ядра.

Загрузка расширений ядра, утвержденных пользователем

Для повышения безопасности перед загрузкой расширений ядра, устанавливаемых во время или после установки macOS 10.13 , требуется согласие пользователя. Этот процесс называется утвержденной пользователем загрузкой расширений ядра. Для утверждения расширения ядра требуются права администратора. Расширения ядра не требуют утверждения в следующих случаях:

расширения были установлены на Mac macOS 10.12 или более ранней версии;

расширения заменяют ранее утвержденные расширения;

их загрузка без согласия пользователя разрешена при помощи инструмента командной строки spctl , доступного при загрузке Mac в режиме recoveryOS;

Начиная с macOS 10.13.2 через систему MDM можно задать список расширений ядра, загружаемых без разрешения пользователя. Для этого Mac с macOS 10.13.2 должен быть зарегистрирован в MDM непосредственно пользователем либо через Apple School Manager или Apple Business Manager,

Источник

Как защищать процессы и расширения ядра в macOS

Привет, Хабр! Сегодня мне хотелось бы поговорить о том, как можно защитить процессы от посягательств злоумышленников в macOS. Например, это полезно для антивируса или системы резервного копирования, особенно в свете того что под macOS существует сразу несколько способов “убить” процесс. Об этом и о методах защиты читайте под катом.

Классический способ “убить” процесс

Всем известный способ “убить” процесс — послать сигнал об SIGKILL процессу. Через bash можно вызвать стандартные “kill -SIGKILL PID” или “pkill -9 NAME” для убийства. Команда “kill” известна еще со времен UNIX и доступна не только в macOS, но и на других UNIX-like системах.

Также как и в UNIX-like системах, macOS позволяет перехватить любые сигналы к процессу кроме двух — SIGKILL и SIGSTOP. В этой статье будет в первую очередь рассматриваться сигнал SIGKILL, как сигнал, порождающий убийство процесса.

Специфика macOS

В macOS системный вызов kill в ядре XNU вызывает функцию psignal(SIGKILL. ). Попробуем посмотреть, какие еще действия пользователя в userspace может вызвать функцию psignal. Отсеим вызовы функции psignal в внутренних механизмах ядра (хотя и они могут быть нетривиальными, но оставим их для другой статьи 🙂 — проверка подписи, ошибки памяти, обработка exit/terminate, нарушение защиты файлов и т.п.

Начнем обзор с функции и соответствующего системного вызова terminate_with_payload. Видно, что помимо классического вызова kill существуют альтернативный подход, который специфичен для операционной системы macOS и не встречается в BSD. Принципы работы обоих системных вызовов также близки. Они представляют собой прямые вызовы функции ядра psignal. Также обратим внимание, что перед убийством процесса производится проверка “cansignal” – может ли процесс отправить сигнал другому процессу, система не допускает любому приложению убивать системные процессы например.

launchd

Стандартный способ создания демонов на запуске системы и контролировать их время жизни — launchd. Обращу внимание на то, что исходники приведены для старой версии launchctl до macOS 10.10, примеры кода приведены в качестве иллюстрации. Современный launchctl отправляет сигналы launchd через XPC, логика launchctl перенесена в него.

Рассмотрим как именно производится остановка приложений. Перед отправкой сигнала SIGTERM, приложение пытаются остановить при помощи системного вызова “proc_terminate”.

Под капотом proc_terminate, несмотря на свое название, может отправлять не только psignal c SIGTERM, но и SIGKILL.

Косвенное убийство — ограничение на ресурсы

Более интересный случай можно увидеть в другом системном вызове process_policy. Стандартное использование этого системного вызова — ограничения ресурсов приложений, например для индексера ограничение на квоту процессорного времени и памяти, чтобы система не существенно замедлялась от действий кэширования файла. Если приложение достигло ограничения на ресурсы, как можно увидеть из функции proc_apply_resource_actions, то процессу отправляется сигнал SIGKILL.

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

Отсюда если “ограничить” квоту использования CPU приложением (например разрешить выполняться только 1 ns),, то можно произвести убийство любого процесса в системе. Так, зловред может убить любой процесс на системе, в том числе и процесс антивируса. Также интересен эффект, который получается при убийстве процесса с pid 1 (launchctl) — kernel panic при попытке обработать сигнал SIGKILL 🙂

Как решать проблему?

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

Во-первых, символ, который отвечает за положение sysent в памяти, не только является приватным символа ядра XNU, но и не может быть найден в символах ядра. Придется использовать эвристические методы поиска, например динамическое дизассемблирование функции и поиск указателя в ней.

Во-вторых, структура записей в таблице зависит от флагов, с которыми было собрано ядро. Если объявлен флаг CONFIG_REQUIRES_U32_MUNGING, то размер структуры будет изменен — добавлено дополнительное поле sy_arg_munge32. Необходимо производить дополнительную проверку на то, с каким флагом было скомпилировано ядро, как вариант сверять указатели на функции с известными.

К счастью, в современных версиях macOS Apple предоставляет новое API для работы с процессами. Endpoint Security API позволяет клиентами авторизировать многие запросы к другим процессам. Так, можно заблокировать любые сигналы к процессы, в том числе сигнал SIGKILL при помощи вышеупомянутого API.

Аналогично в ядре можно зарегистрировать MAC Policy, который предоставляет метод защиты от сигналов (policy proc_check_signal), однако API не поддерживается официально.

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

Помимо защиты процессов в системе обязательно необходима и защита самого расширения ядра (kext). macOS предоставляет для разработчиков фреймворк для удобной разработки драйверов устройств IOKit. Помимо предоставления средств работы с устройствами, IOKit обеспечивает методы стекирования драйверов (driver stacking) при помощи экземпляров классов C++. Приложение в userspace сможет “найти” зарегистрированный экземпляр класса для установления связи kernel-userspace.

Для обнаружения количества экземпляров классов в системе существует утилита ioclasscount.

Любое расширение ядра, которое желает зарегистрироваться в стеке драйверов, обязано объявить класс, унаследованный от IOService, например, my_kext_ioservice в данном случае.Подключение пользовательских приложений вызывает создание нового экземпляра класса, который наследуется от IOUserClient, в примере my_kext_iouserclient.

При попытке выгрузки драйвера из системы (команда kextunload) вызывается виртуальная функция “bool terminate(IOOptionBits options)”. Достаточно вернуть false на вызове функции terminate при попытке выгрузки, чтобы запретить kextunload.

Флаг IsUnloadAllowed может быть выставлен IOUserClient при загрузке. При ограничении на загрузку команда kextunload вернет следующий вывод:

Аналогичную защиту необходимо произвести и для IOUserClient. Экземпляры классов можно выгрузить при помощи userspace функции IOKitLib “IOCatalogueTerminate(mach_port_t, uint32_t flag, io_name_t description);”. Можно возвращать false на вызове команды “terminate” пока userspace приложение не “умрет”, то есть не будет вызов функции “clientDied”.

Защита файлов

Для защиты файлов достаточно использовать Kauth API, который позволяет ограничивать доступ к файлам. Apple предоставляет разработчикам нотификации о различных событиях в scope, для нас важны операции KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA и KAUTH_VNODE_DELETE_CHILD. Ограничивать доступ к файлам проще всего по пути — используем API “vn_getpath” для получения пути к файлу и производим сравнение префикса пути. Заметим, что для оптимизации переименования путей папок с файлами, система не авторизирует доступ к каждому файлу, но только к самой папке, которую переименовали. Необходимо производить сравнение родительского пути и ограничивать KAUTH_VNODE_DELETE для нее.

Недостатком данного подхода может стать низкая производительность при возрастании количества префиксов. Для того, чтобы сравнение не было равно O(prefix*length), где prefix — количество префиксов, length — длина строки, можно использовать детерминированный конечный автомат (ДКА), построенный по префиксам.

Рассмотрим способ построения ДКА для данного набора префиксов. Инициализируем курсоры на начало каждого префикса. Если все курсоры указывают на один и тот же символ, то увеличим каждый курсор на один символ и запомним, что длина одинаковой строчки больше на единицу. Если существует два курсора, символы под которыми разные, разделим курсоры на группы по символу, на которые они указывают и повторим алгоритм для каждой группы.

В первом случае (все символы под курсорами одинаковые) получаем состояние ДКА, которое имеет только один переход по одинаковой строчке. Во втором случае, получаем таблицу переходов размером 256 (кол-во символов и максимальное количество групп) в последующие состояния, полученные при рекурсивном вызове функции.

Рассмотрим пример. Для набора префиксов (“/foo/bar/tmp/”, “/var/db/foo/”, “/foo/bar/aba/”, “foo/bar/aac/”) можно получить следующий ДКА. На рисунке указаны только переходы, ведущие в другие состояния, другие переходы не будут являться конечными.

При прохождении по состояниям ДКА может оказаться 3 случая.

Было достигнуто финальное состояние — путь является защищенным, ограничиваем операции KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA и KAUTH_VNODE_DELETE_CHILD
Не было достигнуто финальное состояние, но путь “кончился” (был достигнут ноль-терминатор) — путь является родительским, необходимо ограничивать KAUTH_VNODE_DELETE. Заметим, что если vnode является папкой, нужно добавить в конец ‘/’, в противном случае может производиться ограничение к файлу “/foor/bar/t”, что неверно.
Не было достигнуто финальное состояние, путь не кончился. Ни один из префиксов не соответствует данном, не вводим ограничения.

Заключение

Целью разрабатываемых секьюрити-решений является повышение уровня безопасности пользователя и его данных. С одной стороны эта цель обеспечивается разработкой программного продукта Acronis, закрывающего те уязвимости, где «слаба» сама операционная система. С другой стороны не следует пренебрегать и усилением тех аспектов безопасности, которые можно улучшить на стороне OS, тем более что закрытие подобных уязвимостей повышает нашу собственную устойчивость как продукта. Уязвимость была сообщена Apple Product Security Team и была исправлена в macOS 10.14.5 (https://support.apple.com/en-gb/HT210119).

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

Источник

Стороннее расширение ядра мешало успешной загрузке системы mac os

О системных расширениях и macOS

Если вы получили предупреждение о расширении системы