AppArmor
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
AppArmor — це покращення ядра, призначене для обмеження ресурсів, доступних програмам, через профілі для кожної програми, ефективно реалізуючи обов'язковий контроль доступу (MAC), прив'язуючи атрибути контролю доступу безпосередньо до програм, а не до користувачів. Ця система працює шляхом завантаження профілів у ядро, зазвичай під час завантаження, і ці профілі визначають, до яких ресурсів програма може отримати доступ, таких як мережеві з'єднання, доступ до сирих сокетів і дозволи на файли.
Існує два робочих режими для профілів AppArmor:
Режим виконання: Цей режим активно забезпечує виконання політик, визначених у профілі, блокуючи дії, які порушують ці політики, і реєструючи будь-які спроби їх порушення через системи, такі як syslog або auditd.
Режим скарги: На відміну від режиму виконання, режим скарги не блокує дії, які суперечать політикам профілю. Натомість він реєструє ці спроби як порушення політики без накладення обмежень.
Модуль ядра: Відповідає за забезпечення виконання політик.
Політики: Визначають правила та обмеження для поведінки програми та доступу до ресурсів.
Парсер: Завантажує політики в ядро для забезпечення виконання або звітування.
Утиліти: Це програми в режимі користувача, які надають інтерфейс для взаємодії з AppArmor та його управління.
Профілі AppArmor зазвичай зберігаються в /etc/apparmor.d/
За допомогою sudo aa-status
ви зможете перерахувати двійкові файли, які обмежені якимось профілем. Якщо ви можете змінити символ "/" на крапку в шляху кожного перерахованого двійкового файлу, ви отримаєте назву профілю apparmor у згаданій папці.
Наприклад, профіль apparmor для /usr/bin/man буде розташований у /etc/apparmor.d/usr.bin.man
Щоб вказати на уражений виконуваний файл, дозволені абсолютні шляхи та шаблони для вказування файлів.
Щоб вказати доступ, який бінарний файл матиме до файлів, можна використовувати такі контролі доступу:
r (читання)
w (запис)
m (відображення пам'яті як виконуваного)
k (блокування файлів)
l (створення жорстких посилань)
ix (виконати іншу програму з новою програмою, що успадковує політику)
Px (виконати під іншим профілем, після очищення середовища)
Cx (виконати під дочірнім профілем, після очищення середовища)
Ux (виконати без обмежень, після очищення середовища)
Змінні можуть бути визначені в профілях і можуть бути змінені ззовні профілю. Наприклад: @{PROC} та @{HOME} (додайте #include <tunables/global> до файлу профілю)
Правила заборони підтримуються для переважання правил дозволу.
Щоб легко почати створення профілю, apparmor може вам допомогти. Можливо, щоб apparmor перевіряв дії, виконувані бінарним файлом, а потім дозволив вам вирішити, які дії ви хочете дозволити або заборонити. Вам просто потрібно виконати:
Тоді в іншій консолі виконайте всі дії, які зазвичай виконує двійковий файл:
Тоді в першій консолі натисніть "s", а потім у записаних діях вкажіть, чи хочете ви ігнорувати, дозволити або щось інше. Коли ви закінчите, натисніть "f", і новий профіль буде створено в /etc/apparmor.d/path.to.binary
Використовуючи клавіші стрілок, ви можете вибрати, що хочете дозволити/заборонити/щось інше
Ви також можете створити шаблон профілю apparmor для бінарного файлу за допомогою:
Зверніть увагу, що за замовчуванням у створеному профілі нічого не дозволено, тому все заборонено. Вам потрібно буде додати рядки, такі як /etc/passwd r,
, щоб дозволити бінарному файлу читати /etc/passwd
, наприклад.
Ви можете потім застосувати новий профіль з
Наступний інструмент прочитає журнали та запитає в користувача, чи хоче він дозволити деякі з виявлених заборонених дій:
Використовуючи клавіші зі стрілками, ви можете вибрати, що ви хочете дозволити/заборонити/що завгодно
Приклад AUDIT та DENIED журналів з /var/log/audit/audit.log виконуваного файлу service_bin
:
Ви також можете отримати цю інформацію, використовуючи:
Зверніть увагу, як профіль docker-profile Docker завантажується за замовчуванням:
За замовчуванням профіль docker-default Apparmor генерується з https://github.com/moby/moby/tree/master/profiles/apparmor
Резюме профілю docker-default:
Доступ до всіх мереж
Жодна можливість не визначена (Однак деякі можливості будуть отримані з включення базових базових правил, тобто #include <abstractions/base>)
Запис у будь-який файл /proc не дозволено
Інші підкаталоги/файли /proc та /sys мають заборонений доступ на читання/запис/блокування/посилання/виконання
Монтування не дозволено
Ptrace може бути виконано лише на процесі, який обмежений тим самим профілем apparmor
Якщо ви запустите контейнер docker, ви повинні побачити наступний вивід:
Зверніть увагу, що apparmor навіть заблокує привілеї можливостей, надані контейнеру за замовчуванням. Наприклад, він зможе заблокувати дозвіл на запис у /proc, навіть якщо можливість SYS_ADMIN надана, оскільки за замовчуванням профіль apparmor docker забороняє цей доступ:
Вам потрібно вимкнути apparmor, щоб обійти його обмеження:
Зверніть увагу, що за замовчуванням AppArmor також заборонить контейнеру монтувати папки зсередини, навіть з можливістю SYS_ADMIN.
Зверніть увагу, що ви можете додати/видалити можливості до контейнера docker (це все ще буде обмежено методами захисту, такими як AppArmor та Seccomp):
--cap-add=SYS_ADMIN
надає можливість SYS_ADMIN
--cap-add=ALL
надає всі можливості
--cap-drop=ALL --cap-add=SYS_PTRACE
скидає всі можливості та надає лише SYS_PTRACE
Зазвичай, коли ви знаходите, що у вас є привілейована можливість доступна всередині контейнера docker, але деяка частина експлуатації не працює, це буде тому, що apparmor docker заважає цьому.
(Приклад з тут)
Щоб проілюструвати функціональність AppArmor, я створив новий профіль Docker “mydocker” з доданим наступним рядком:
Щоб активувати профіль, нам потрібно зробити наступне:
Щоб перерахувати профілі, ми можемо виконати наступну команду. Команда нижче перераховує мій новий профіль AppArmor.
Як показано нижче, ми отримуємо помилку, коли намагаємося змінити “/etc/”, оскільки профіль AppArmor заважає запису в “/etc”.
Ви можете дізнатися, який профіль apparmor виконує контейнер, використовуючи:
Тоді ви можете виконати наступний рядок, щоб знайти точний профіль, що використовується:
У дивному випадку ви можете змінити профіль apparmor docker і перезавантажити його. Ви могли б видалити обмеження і "обійти" їх.
AppArmor базується на шляху, це означає, що навіть якщо він може захищати файли всередині каталогу, як /proc
, якщо ви можете налаштувати, як контейнер буде запущено, ви могли б монтувати каталог proc хоста всередині /host/proc
і він більше не буде захищений AppArmor.
У цьому багу ви можете побачити приклад того, як навіть якщо ви заважаєте perl виконуватись з певними ресурсами, якщо ви просто створите shell-скрипт вказуючи в першому рядку #!/usr/bin/perl
і ви виконаєте файл безпосередньо, ви зможете виконати що завгодно. Наприклад:
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)