📰 IT Дайджест

Объединённые сегодня для ядра Linux 7.1 новые документы касаются того, что считается ошибкой безопасности, а также ответственного использования AI для поиска ошибок ядра.

В связи с недавним наплывом ошибок безопасности в ядро Linux, а также ростом числа отчётов об ошибках и уязвимостях, обнаруженных полностью или частично с помощью AI, потребовалась дополнительная документация. Долгосрочный разработчик Linux Willy Tarreau взялся за подготовку дополнительной документации по ошибкам ядра.

Что касается того, что считается ошибкой безопасности в ядре Linux, новая документация гласит:

"Важно, чтобы большинство ошибок обрабатывались публично, чтобы вовлечь как можно более широкую аудиторию и найти лучшее решение. По своей природе ошибки, которые рассматриваются в закрытых обсуждениях между небольшим числом участников, с меньшей вероятностью приведут к наилучшему возможному исправлению (например, из-за риска упустить допустимые сценарии использования и ограниченных возможностей тестирования).

Оказывается, большинство ошибок, сообщаемых через security team, — это просто обычные ошибки, которые были неверно квалифицированы как ошибки безопасности из-за недостаточного понимания модели угроз ядра Linux, как описано в Documentation/process/threat-model.rst, и вместо этого должны были быть отправлены через обычные каналы, описанные в Documentation/admin-guide/reporting-issues.rst.

Список безопасности существует для срочных ошибок, которые дают атакующему возможность, которой он не должен обладать на правильно настроенной production system, и которые можно легко эксплуатировать, создавая непосредственную угрозу для многих пользователей. Перед отправкой отчёта подумайте, действительно ли проблема пересекает границу доверия на такой системе.

Если вы прибегли к помощи AI, чтобы выявить ошибку, вы должны считать её публичной. Хотя у вас могут быть веские причины полагать, что это не так, опыт security team показывает, что ошибки, обнаруженные таким образом, систематически всплывают одновременно у нескольких исследователей, часто в один и тот же день. В этом случае не публикуйте reproducer, так как это может причинить непреднамеренный вред; просто укажите, что он имеется, и сопровождающие могут запросить его у вас приватно, если он им понадобится.

Если вы не уверены, подпадает ли проблема под критерии, лучше отправить её приватно: security team предпочла бы разобрать пограничный отчёт, чем пропустить реальную уязвимость. Однако отправка обычных ошибок в список безопасности не ускоряет их обработку и расходует ресурсы triage, которые нужны для других отчётов."
И о ответственном использовании AI для поиска ошибок ядра Linux:
"Значительная часть отчётов об ошибках, отправляемых в security team, на самом деле является результатом code review, выполненного с помощью AI tools. Хотя это может быть эффективным способом находить ошибки в редко исследуемых областях, это создаёт перегрузку для сопровождающих, которые иногда вынуждены игнорировать такие отчёты из-за их низкого качества или неточности. Поэтому отправителям следует особенно внимательно относиться к ряду моментов, которые делают такие отчёты неоправданно трудными для обработки:

• Length: AI-generated reports tend to be excessively long, containing multiple sections and excessive detail. This makes it difficult to spot important information such as affected files, versions, and impact. Please ensure that a clear summary of the problem and all critical details are presented first. Do not require triage engineers to scan multiple pages of text. Configure your tools to produce concise, human-style reports.

• Formatting: Most AI-generated reports are littered with Markdown tags. These decorations complicate the search for important information and do not survive the quoting processes involved in forwarding or replying. Please always convert your report to plain text without any formatting decorations before sending it.

• Impact Evaluation: Many AI-generated reports lack an understanding of the kernel's threat model (see Documentation/process/threat-model.rst) and go to great lengths inventing theoretical consequences. This adds noise and complicates triage. Please stick to verifiable facts (e.g., "this bug permits any user to gain CAP_NET_ADMIN") without enumerating speculative implications. Have your tool read this documentation as part of the evaluation process.

• Reproducer: AI-based tools are often capable of generating reproducers. Please always ensure that your tool provides one and test it thoroughly. If the reproducer does not work, or if the tool cannot produce one, the validity of the report should be seriously questioned. Note that since the report will be posted to a public list, the reproducer should only be shared upon maintainers' request.

• Propose a Fix: Many AI tools are actually better at writing code than evaluating it. Please ask your tool to propose a fix and test it before reporting the problem. If the fix cannot be tested because it relies on rare hardware or almost extinct network protocols, the issue is likely not a security bug. In any case, if a fix is proposed, it must adhere to Documentation/process/submitting-patches.rst and include a 'Fixes:' tag designating the commit that introduced the bug.

Failure to consider these points exposes your report to the risk of being ignored.

Use common sense when evaluating the report. If the affected file has not been touched for more than one year and is maintained by a single individual, it is likely that usage has declined and exposed users are virtually non-existent (e.g., drivers for very old hardware, obsolete filesystems). In such cases, there is no need to consume a maintainer's time with an unimportant report. If the issue is clearly trivial and publicly discoverable, you should report it directly to the public mailing lists."
Всю новую документацию по ошибкам ядра Linux от Willy Tarreau можно прочитать через этот commit, который уже находится в Linux Git ahead of Sunday's Linux 7.1-rc4 release.