Линус Торвальдс принял в ядро документ, который формализует обработку багов безопасности. Он определяет модель угроз, объясняет, какие баги считаются уязвимостями, и вводит правила для AI-отчётов.
Почему сейчас
На приватную рассылку безопасности хлынул поток AI-отчётов. Два года назад приходило 2–3 в неделю, сейчас 5–10 в день. Большинство — обычные баги, ошибочно поданные как уязвимости. Авторы просто не знакомы с моделью угроз ядра.
Правила для AI-репортов
Баг, найденный через AI, считается публичным. Одни и те же модели находят одни и те же проблемы, часто в один день. Требования к отчётам:
• Plain text, без Markdown
• Проверяемые факты («баг даёт
CAP_NET_ADMIN»), а не спекуляции• Рабочий reproducer, протестированный вручную
• Патч с тегом
Fixes: на проблемный коммитМодель угроз
Новый
threat-model.rst фиксирует границы. Уязвимость — нарушение изоляции пользователей, обход capabilities (CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_PTRACE), выход из user namespaces в глобальное пространство, доступ к отладочным интерфейсам (/proc/kmsg, perf, debugfs) без прав.Не уязвимость: баги в устаревших ветках, небезопасные конфигурации сборки, LOCKDEP/KASAN/
FAULT_INJECTION, модули STAGING, проблемы, требующие root, утечки по побочным каналам, обход ASLR, повреждения от аппаратных сбоев.Документ не запрещает AI. Но требует от репортеров тот же уровень подготовки, что и от всех. Торвальдс сказал прямо: читайте документацию, пишите патч, берите ответственность.
➡️ Полный текст в коммите ядра Linux
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека devops'a
#пульс_индустрии