Qualys TRU обнаружила девять уязвимостей в AppArmor, которые позволяют непривилегированному пользователю получить root-права и выйти за пределы контейнера. Для студента это не просто новость из мира кибербеза, а полноценный кейс: реальные CVE, известный вектор атаки, конкретные меры митигирования. Такой инцидент можно разобрать в дипломе от постановки задачи до тестирования защитного механизма. В этой статье покажу, как превратить CrackArmor в структуру ВКР, какие метрики считать и как оформить результаты, чтобы работа прошла нормоконтроль и выглядела выигрышно на защите.
Не обязательно делать диплом целиком про AppArmor. Достаточно взять одну из проблемных областей и построить вокруг неё исследование. Ниже — три темы, которые легко защитить: они привязаны к реальной атаке и дают место для практики.
| № | Тема ВКР | Актуальность | Цель | Задачи | Структура |
|---|---|---|---|---|---|
| 1 | Разработка методики тестирования защищённости контейнеров на базе Linux Security Modules | Уязвимости AppArmor показывают, что стандартная изоляция недостаточна; нужно проверять её до эксплуатации | Создать методику пентеста контейнерной инфраструктуры с учётом LSM | 1. Классифицировать уязвимости AppArmor; 2. Спроектировать тестовый стенд; 3. Разработать сценарии атак; 4. Предложить метрики защиты | Гл.1 — анализ атак и существующих LSM; Гл.2 — архитектура стенда и методика; Гл.3 — результаты тестирования, сравнение до/после |
| 2 | Автоматизация аудита AppArmor-профилей в Kubernetes | Ручная настройка профилей допускает ошибки, которые приводят к root-доступу; требуется автоматический контроль | Разработать инструмент проверки профилей AppArmor на наличие слабых мест | 1. Исследовать CVE CrackArmor; 2. Собрать требования к аудиту; 3. Написать парсер профилей и проверки; 4. Внедрить в CI/CD | Гл.1 — AppArmor и Kubernetes security context; Гл.2 — проектирование аудитора; Гл.3 — внедрение, оценка покрытия |
| 3 | Оценка эффективности изоляции контейнеров при использовании AppArmor, SELinux и seccomp | Инцидент — повод сравнить существующие механизмы защиты и выбрать оптимальный для корпоративной среды | Провести экспериментальное сравнение устойчивости LSM к атакам типа CrackArmor | 1. Определить критерии оценки; 2. Настроить три стенда; 3. Провести атаки и зафиксировать результаты; 4. Выработать рекомендации | Гл.1 — теория изоляции; Гл.2 — экспериментальный стенд; Гл.3 — анализ результатов, показатели защищённости |
Каждая тема позволяет использовать статью как первичный источник в главе «Анализ предметной области» — сошлитесь на Qualys TRU, перечислите CVE, разберите вектор атаки.
Глава 1 (теория). Начните с модели угроз: непривилегированный пользователь, контейнер в Docker или containerd, цель — root на хосте. Опишите архитектуру AppArmor: как работает LSM, что такое профили, почему недостаточно просто наложить ограничения. Разберите технику взлома, не углубляясь в спойлеры полного эксплойта — достаточно описать KeyKook: перехват управления task->cred в обход проверок AppArmor.
# Псевдокод атаки на основе CrackArmor (упрощённо)
if (setxattr + key_change) # использование механизма keyrings
overwrite_cred_pointer() # перезапись указателя на credentials
skip_apparmor_checks() # обход LSM-хуков
spawn_root_shell()Глава 2 (практика). Постройте стенд: ядро с уязвимым AppArmor, контейнер с непривилегированным пользователем. Спроектируйте архитектуру атаки на UML или C4 — это сразу добавляет работе инженерный вид. Нарисуйте диаграмму последовательности: запрос от пользователя → обработка через keyring → перезапись cred → вызов setuid(0). Если тема — защита, то вместо атаки проектируйте профиль AppArmor, который блокирует потенциально опасные операции.
# Пример профиля AppArmor для контейнера
profile container-deny flags=(attach_disconnected) {
/bin/{sh,bash} ix,
denylist /proc/sys/kernel/core_pattern w,
capable setuid, # оставили только нужные capabilities
deny /etc/passwd w,
}Глава 3 (тестирование). Внедрите метрики. Для ВКР достаточно рассчитать:
| Метрика | Что показывает | Как считать |
|---|---|---|
| Время до получения root (TTRO) | Скорость эксплуатации уязвимости | От запуска атаки до получения euid=0 |
| Покрытие профиля (%) | Какой объём системных вызовов ограничен | (разрешённые вызовы / все используемые) * 100 |
| Количество CVE-точек | Число векторов, которые переживают защиту | Результат тестов до и после митигирования |
Опишите жизненный цикл уязвимости: обнаружение → раскрытие → патч. Ссылайтесь на OWASP для классификации рисков (A1: Broken Access Control). Для текстовой части работы подойдёт требование ГОСТ 19.102 (стадии разработки), для оценки качества — ISO/IEC 25010. Не выдумывайте стандарты — именно эти применимы к ПО.
Использовать код — можно, но нужно оформлять его как цитату с указанием источника, а в главе «Реализация» показать, как вы адаптируете или запускаете его. Лучше не копировать полностью, а воспроизвести ключевую идею — например, написать POC, который демонстрирует обход только одного ограничения AppArmor.
Linux с ядром >=5.15 (где есть уязвимые версии AppArmor), Docker или Podman, gcc для сборки эксплойта, strace для трассировки системных вызовов, bpftrace для динамического анализа. Всё это ставится на виртуальную машину — не обязательно иметь отдельный стенд.
Используйте UML (диаграмма вариантов использования, последовательностей) и C4 (контейнеры и развёртывание). Не рисуйте скриншоты из MS Visio — используйте PlantUML или Draw.io, но с подписями по ЕСПД: «Рисунок 1 — Сценарий атаки». Под каждым рисунком обязательна ссылка в тексте.
Возьмите аспект, который пересекается: например, тема про DevOps — добавьте главу о безопасности CI/CD, где продемонстрируете уязвимость рантайма и предложите автоматизацию защиты. В теме «Разработка ПО» — обоснуйте требования к безопасности приложения. Свяжите CrackArmor с вашим основным направлением через контейнерную доставку.
Ошибка 1: Подробное описание эксплойта без анализа защиты. В ВКР не нужно выкладывать полный код атаки — это допустимо для курсовой, но для диплома важнее показать, как вы предотвращаете атаку. Опишите патчи и конфигурации.
Ошибка 2: Метрики без повторяемости. Студенты пишут «после внедрения стало лучше» — но не приводят протокол тестирования. Зафиксируйте условия: версия ядра, количество запусков, доверительный интервал. Это снижает вопросы на защите.
Ошибка 3: Отсутствие связи с нормативными документами. Один упомянутый ГОСТ в разделе «Актуальность» — это формальность. Сравните требования стандарта с тем, что вы делаете в каждой главе. Пример: ГОСТ 19.102 — стадии «Техническое задание» и «Рабочий проект» у вас должны быть отражены в структуре.
Вы работаете над ВКР и хотите сэкономить 120 часов своего времени? Наша команда помогает с любой темой: от обзора литературы до готового диплома, который пройдёт нормоконтроль и оставит приятное впечатление. Бесплатная консультация — просто напишите нам. Если нужно заказать диплом или частичную помощь с дипломом — обсудим объём и сроки.
Источник: Уязвимости CrackArmor в Linux AppArmor позволяют получить root-права и обойти изоляцию контейнеров (опубликовано 2026-03-18)