macOS Launch/Environment Constraints & Trust Cache
Основна інформація
Обмеження запуску в macOS були введені для підвищення безпеки шляхом регулювання того, як, хто і звідки може бути ініційований процес. Запроваджені в macOS Ventura, вони надають фреймворк, який категоризує кожний системний бінарний файл у різні категорії обмежень, які визначені в кеші довіри, список, що містить системні бінарні файли та їх відповідні хеші. Ці обмеження поширюються на кожний виконуваний бінарний файл у системі, включаючи набір правил, які визначають вимоги для запуску певного бінарного файлу. Правила охоплюють власні обмеження, які повинен задовольняти бінарний файл, обмеження батьків, які повинні бути виконані батьківським процесом, та обмеження відповідальності, які повинні дотримуватися іншими відповідними сутностями.
Механізм поширюється на сторонні додатки через Обмеження середовища, починаючи з macOS Sonoma, що дозволяє розробникам захищати свої додатки, вказуючи набір ключів та значень для обмежень середовища.
Ви визначаєте обмеження запуску та бібліотек в словниках обмежень, які ви зберігаєте в файлах властивостей launchd
, або в окремих файлах властивостей, які ви використовуєте при підписанні коду.
Існує 4 типи обмежень:
Власні обмеження: Обмеження, які застосовуються до виконуваного бінарного файлу.
Батьківський процес: Обмеження, які застосовуються до батька процесу (наприклад
launchd
, який запускає службу XP)Обмеження відповідальності: Обмеження, які застосовуються до процесу, який викликає службу у комунікації XPC
Обмеження завантаження бібліотек: Використовуйте обмеження завантаження бібліотек для селективного опису коду, який може бути завантажений
Таким чином, коли процес намагається запустити інший процес — викликаючи execve(_:_:_:)
або posix_spawn(_:_:_:_:_:_:)
— операційна система перевіряє, що виконуваний файл задовольняє своє власне обмеження. Вона також перевіряє, що виконуваний файл батьківського процесу задовольняє обмеження батьківського процесу, і що виконуваний файл відповідального процесу задовольняє обмеження відповідального процесу. Якщо будь-які з цих обмежень запуску не виконуються, операційна система не запускає програму.
Якщо при завантаженні бібліотеки будь-яка частина обмеження бібліотеки не виконується, ваш процес не завантажує бібліотеку.
Категорії LC
LC складається з фактів та логічних операцій (і, або..), які комбінують факти.
Факти, які може використовувати LC, задокументовані. Наприклад:
is-init-proc: Булеве значення, яке вказує, чи має виконуваний файл бути процесом ініціалізації операційної системи (
launchd
).is-sip-protected: Булеве значення, яке вказує, чи має виконуваний файл бути файлом, захищеним Системою Цілісності (SIP).
on-authorized-authapfs-volume:
Булеве значення, яке вказує, чи операційна система завантажила виконуваний файл з авторизованого, аутентифікованого тому APFS.on-authorized-authapfs-volume
: Булеве значення, яке вказує, чи операційна система завантажила виконуваний файл з авторизованого, аутентифікованого тому APFS.Cryptexes volume
on-system-volume:
Булеве значення, яке вказує, чи операційна система завантажила виконуваний файл з поточного завантаженого тому системи.Всередині /System...
...
Коли Apple бінарний файл підписаний, він призначає його категорії LC всередині кешу довіри.
16 категорій LC для iOS були розгорнуті та задокументовані тут.
Поточні категорії LC (macOS 14 - Somona) були розгорнуті, і їх опис можна знайти тут.
Наприклад, Категорія 1:
(on-authorized-authapfs-volume || on-system-volume)
: Повинно бути у томі System або Cryptexes.launch-type == 1
: Повинно бути системним сервісом (plist у LaunchDaemons).validation-category == 1
: Виконуваний файл операційної системи.is-init-proc
: Launchd
Реверсінг LC Категорій
Ви можете отримати більше інформації тут, але в основному вони визначені в AMFI (AppleMobileFileIntegrity), тому вам потрібно завантажити Набір розробки ядра, щоб отримати KEXT. Символи, що починаються з kConstraintCategory
, є цікавими. Видобуваючи їх, ви отримаєте закодований потік DER (ASN.1), який потрібно розкодувати за допомогою ASN.1 Decoder або бібліотеки python-asn1 та її сценарію dump.py
, andrivet/python-asn1, яка надасть вам більш зрозумілий рядок.
Обмеження середовища
Це обмеження запуску, налаштоване в додатках сторонніх розробників. Розробник може вибрати факти та логічні операнди для використання у своєму додатку для обмеження доступу до нього.
Можливо перерахувати Обмеження середовища додатка за допомогою:
Кеш довіри
У macOS є кілька кешів довіри:
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/BaseSystemTrustCache.img4
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/StaticTrustCache.img4
/System/Library/Security/OSLaunchPolicyData
А в iOS виглядає, що він знаходиться в /usr/standalone/firmware/FUD/StaticTrustCache.img4
.
На macOS, що працює на пристроях Apple Silicon, якщо підписаний Apple бінарний файл не знаходиться в кеші довіри, AMFI відмовиться його завантажувати.
Перелік кешів довіри
Попередні файли кешу довіри мають формат IMG4 та IM4P, де IM4P - це розділ навантаження формату IMG4.
Ви можете використовувати pyimg4, щоб видобути навантаження баз даних:
(Іншою опцією може бути використання інструменту img4tool, який буде працювати навіть в M1, навіть якщо версія застаріла, і для x86_64, якщо ви встановите його в відповідні місця).
Тепер ви можете використовувати інструмент trustcache, щоб отримати інформацію у зручному форматі:
Довірний кеш має наступну структуру, тому категорія LC є четвертим стовпцем
Потім ви можете використати скрипт, такий як цей, щоб витягти дані.
З цих даних ви можете перевірити додатки з значенням обмежень запуску 0
, які не обмежені (перевірте тут для кожного значення).
Заходи проти атак
Обмеження запуску б врегулювало кілька старих атак, переконуючись, що процес не буде виконаний в неочікуваних умовах: наприклад, з неочікуваних місць або викликаний неочікуваним батьківським процесом (якщо лише launchd має запускати його).
Більше того, обмеження запуску також перешкоджає атакам на зниження рівня.
Однак вони не захищають від поширених зловживань XPC, внедрень коду Electron або внедрень dylib без перевірки бібліотек (якщо не відомі ідентифікатори команд, які можуть завантажувати бібліотеки).
Захист від служб XPC Daemon
У випуску Sonoma помітним пунктом є конфігурація відповідальності служби XPC демона. Служба XPC відповідає за себе, на відміну від клієнта, який підключається. Це документовано в звіті про зворотній зв'язок FB13206884. Ця настройка може здатися недосконалою, оскільки вона дозволяє певні взаємодії зі службою XPC:
Запуск служби XPC: Якщо припустити, що це помилка, ця настройка не дозволяє ініціювати службу XPC через код атакувальника.
Підключення до активної служби: Якщо служба XPC вже працює (можливо, активована її початковим додатком), немає перешкод для підключення до неї.
Хоча впровадження обмежень на службу XPC може бути корисним, звужуючи вікно для потенційних атак, це не вирішує основну проблему. Забезпечення безпеки служби XPC фундаментально вимагає ефективної перевірки підключеного клієнта. Це залишається єдиним методом зміцнення безпеки служби. Також варто зазначити, що згадана конфігурація відповідальності наразі працює, що може не відповідати задуманому дизайну.
Захист від Electron
Навіть якщо вимагається, щоб додаток був відкритий за допомогою LaunchService (в обмеженнях батьків). Це можна досягти за допомогою open
(який може встановлювати змінні середовища) або використовуючи API служб запуску (де можна вказати змінні середовища).
Посилання
Last updated