15 мая Линус Торвальдс официально утвердил документ, регламентирующий процесс обработки угроз безопасности в ядре Linux. Новые правила четко определяют модель угроз, критерии классификации уязвимостей и порядок работы с багами, выявленными с помощью искусственного интеллекта. Автором инициативы выступил Вилли Тарро (Willy Tarreau) — создатель HAProxy и опытный разработчик ядра, курирующий стабильные ветки. Основой для документа стали недавние дискуссии вокруг критических уязвимостей, которые были обнародованы до выхода официальных патчей, причем злоумышленники оперативно создали рабочие эксплоиты с привлечением ИИ.
Согласно принятым правилам, большинство проблем безопасности теперь необходимо разбирать публично, чтобы привлекать независимых экспертов и оперативно находить качественные технические решения. В закрытые приватные списки рассылки разрешено отправлять лишь экстренные сообщения, касающиеся критических дыр, которые легко эксплуатируются, затрагивают широкий круг пользователей и предоставляют злоумышленникам повышенные привилегии.
Все потенциальные уязвимости, обнаруженные с помощью нейросетей и ИИ-ассистентов, подлежат исключительно открытому обсуждению. Подобные проблемы часто фиксируются исследователями параллельно, поэтому скрывать их бессмысленно. Публиковать готовый эксплоит в отчете запрещено — достаточно упомянуть о его наличии и при необходимости переслать код разработчикам в индивидуальном порядке.
Отдельное внимание уделено качеству поступающих отчетов от исследователей, использующих ИИ. Потоки таких сообщений постоянно растут, и хотя они иногда помогают находить дефекты в слабопроверенных участках кода, мейнтейнеры часто игнорируют их из-за обилия ошибок, воды и низкого качества анализа.
Основные требования к отчетам, сформированным с участием искусственного интеллекта:
- Максимальная краткость, отсутствие лишней информации и выжимка сути в самом начале текста.
- Использование исключительно чистого текста без разметки Markdown и декоративных элементов.
- Опора на реальную модель угроз и проверяемые факты (например, четкое указание: «ошибка дает возможность любому пользователю получить CAP_NET_ADMIN»), а не на абстрактные рассуждения о возможных последствиях.
- Обязательное предварительное тестирование эксплойта, созданного ИИ, с целью подтвердить его реальную работоспособность и воспроизводимость.
- Привлечение искусственного интеллекта непосредственно для написания и тестирования патчей, устраняющих найденную проблему.
Как показывает практика разработчиков, большинство присылаемых под видом уязвимостей сообщений на деле ими не являются и подлежат разбору в стандартном порядке как обычные баги. Чтобы исключить путаницу, в документе детально прописана модель угроз ядра Linux. К числу гарантий и возможностей, нарушение которых квалифицируется как полноценная уязвимость, относятся:
- Изоляция учетных записей пользователей: строгий доступ к файлам только для владельцев, недоступность памяти сторонних процессов, запрет ptrace для чужих задач, а также изоляция сетевого взаимодействия и межпроцессорного обмена (IPC).
- Защита на основе capabilities: операции без флага CAP_SYS_ADMIN не позволяют менять конфигурацию ядра, системное состояние или память; без CAP_NET_ADMIN запрещено перенастраивать сеть и перехватывать трафик; без CAP_SYS_PTRACE нельзя мониторить чужие процессы.
- Пространство имён пользовательских идентификаторов (CONFIG_USER_NS), которое дает непривилегированным пользователям возможность создавать изолированные среды без прямого влияния на глобальные пространства имён (например, запрещено менять системные часы, монтировать блочные устройства или загружать модули).
- Специальные отладочные интерфейсы вроде /proc/kmsg, perf и debugfs, предоставляющие конфиденциальные данные исключительно после явного разрешения администратора.
В то же время целый ряд ситуаций и архитектурных особенностей намеренно исключен из числа уязвимостей:
- Эксплуатация давно устаревших и неподдерживаемых веток ядра.
- Применение конфигураций сборки с намеренно сниженным уровнем безопасности или предназначенных исключительно для разработчиков (например, CONFIG_NOMMU).
- Небезопасные пользовательские настройки sysctl, параметров командной строки, прав файловой системы, capabilities или открытие доступа к привилегированным интерфейсам для обычных юзеров (включая запись в procfs и debugfs).
- Сбои в чисто отладочных подсистемах вроде KASAN, LOCKDEP и FAULT_INJECTION, которые никоим образом не рассчитаны на активацию в продакшн-окружении.
- Проблемы в драйверах и модулях, находящихся в экспериментальном каталоге STAGING или имеющих статус небезопасных и нестабильных.
- Применение сторонних модулей сторонних разработчиков или неофициальных неоригинальных форков ядра.
- Ситуации, требующие избыточных прав доступа, таких как изначально имеющиеся привилегии root или владение capabilities вроде CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO и CAP_SYS_MODULE.
- Теоретические векторы атак, выполнимые исключительно в лабораторных условиях, требующие миллиардов попыток, эмуляции железа, модификации оборудования либо несоразмерных вычислительных затрат в нереалистичных конфигурациях (к примеру, на системах с десятками тысяч ядер процессора).
- Обход защитных механизмов вроде ASLR без демонстрации работающего эксплойта, а также отсутствие проверок возвращаемых ошибок и аргументов, не влекущее за собой критических последствий.
- Случайные утечки данных, не подконтрольные злоумышленникам (включая остаточную информацию в системных логах и логах ошибок или утечки указателей памяти ядра без возможности их прямой эксплуатации).
- Ошибки при попытках смонтировать поврежденные образы дисков, если конкретный драйвер изначально не позиционировался как безопасный для работы с недоверенными носителями (подобные проблемы решаются запуском стандартной утилиты fsck).
- Физические атаки на аппаратную часть, требующие прямого доступа к машине, смены компонентов или подключения специализированных устройств (вроде логических анализаторов и плат для атак на DMA), если в системе изначально не задействована защита IOMMU.
- Регрессии производительности или функционала, которые устраняются корректной настройкой лимитов и прав доступа.
