Линус Торвальдс утвердил новый регламент обработки уязвимостей в ядре Linux. Документ, составленный ветераном разработки и автором HAProxy Вилли Тарро, четко определяет модель угроз, критерии классификации ошибок и правила работы с отчетами, сгенерированными с помощью нейросетей. Регламент был создан на основе опыта анализа критических сбоев, детали которых просочились в сеть до выхода исправлений из-за возможности автоматического создания эксплоитов через AI.
Правила обработки отчетов об уязвимостях
Согласно новым правилам, большая часть сообщений о безопасности должна обрабатываться в публичном поле. Это необходимо для привлечения экспертного сообщества и поиска наиболее эффективных решений. Приватный список рассылки теперь предназначен исключительно для экстренных ситуаций: критических уязвимостей, которые легко эксплуатируются, несут угрозу широкому кругу пользователей и позволяют злоумышленнику получить расширенные привилегии.
Особое внимание уделено инцидентам, выявленным при помощи AI. Разработчики настаивают на публичном обсуждении таких находок, так как их часто обнаруживают сразу несколько исследователей. Важно не публиковать готовый эксплоит: достаточно факта его существования, а сам код следует передать сопровождающему лично по запросу.
Требования к качеству AI-отчетов
Поскольку сопровождающие получают массу неточных отчетов от нейросетей, к ним выдвинуты строгие требования:
- Краткость: суть проблемы должна быть понятна с первого абзаца.
- Текстовый формат: только «голый» текст без Markdown и лишнего оформления.
- Конкретика: описание проверяемых фактов (например, повышение прав через конкретный CAP_NET_ADMIN) вместо теоретических размышлений.
- Тестирование: перед отправкой отчет обязан быть верифицирован — отправитель должен убедиться, что проблема реально воспроизводится.
- AI как инструмент: использование нейросетей поощряется не только для поиска ошибок, но и для разработки и тестирования самих исправлений.
Модель угроз ядра Linux
Не все ошибки, присылаемые под видом «дыр в безопасности», являются таковыми. Разработчики ядра выделили четкий перечень параметров, нарушение которых считается реальной уязвимостью:
- Изоляция пользователей: доступ к файлам только для владельца, защита памяти процессов, запрет ptrace для чужих задач, изоляция IPC и сети.
- Механизм Capabilities: защита функций ядра (изменение конфигурации, сетевые настройки, трассировка) без наличия необходимых прав (SYS_ADMIN, NET_ADMIN и т.д.).
- Пространства имен (CONFIG_USER_NS): защита глобальной системы от действий непривилегированных пользователей внутри их изолированных окружений.
- Отладочные интерфейсы: доступ к /proc/kmsg, perf и debugfs должен требовать явных прав администратора.
Что НЕ считается уязвимостью
Ряд ситуаций исключен из категории критических проблем:
- Использование устаревших версий ядра.
- Сборка с опциями разработчика (например, CONFIG_NOMMU).
- Небезопасные конфигурации системных параметров (sysctl, права доступа, параметры командной строки).
- Ошибки в коде для отладки, которые не предназначены для рабочих конфигураций (KASAN, LOCKDEP).
- Проблемы в экспериментальных драйверах из секции STAGING.
- Использование сторонних модулей и неофициальных сборок.
- Требование избыточных прав: если для атаки уже нужны полномочия root или CAP_SYS_ADMIN, такая угроза не считается критической.
- Теоретические векторы атак, требующие эмуляции, модификации «железа» или миллиардов попыток.
- Обход ASLR без демонстрации рабочего эксплоита.
- Утечки данных (например, указателей), не имеющие возможности прямой эксплуатации.
- Проблемы при монтировании поврежденных дисковых образов (требуется fsck).
- Атаки, требующие физического доступа к оборудованию, если не был настроен IOMMU.
- Регрессии производительности, исправляемые лимитами ресурсов.
