Подсистема аудита ядра Linux

https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
https://github.com/linux-audit/audit-kernel

Подсистема аудита Linux предоставляет безопасную платформу журналирования, которая используется для сбора и записи событий, связанных с безопасностью. Она состоит из компонента ядра, который генерирует записи аудита на основе активности системы, демона пользовательского пространства, который записывает эти записи в локальный файл или на удалённый сервер агрегации, и набора инструментов пользовательского пространства для просмотра и постобработки журналов аудита.

Основной README ядра Linux можно найти по адресу Documentation/admin-guide/README.rst

Онлайн-ресурсы

Канонический репозиторий ядра аудита размещается на kernel.org:

• https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
• git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git

Также существует официально поддерживаемое зеркало на GitHub:

• https://github.com/linux-audit/audit-kernel

Ветки исходного кода ядра и процесс разработки

Ветки исходного кода ядра

В процессе разработки используются четыре основные ветки git: stable-X.Y, dev, dev-staging и next. Помимо этих четырёх основных веток существуют также тематические ветки незавершённой работы, которые начинаются с префикса «working-»; эти ветки, как правило, можно игнорировать, если только вы не участвуете в разработке этой конкретной темы. Управление этими тематическими ветками может варьироваться в зависимости от ряда факторов, однако подробности по каждой ветке будут сообщаться в соответствующих обсуждениях в upstream-списке рассылки.

Ветка stable-X.Y

Ветка stable-X.Y предназначена для стабильных патчей ядра и основана на теге X.Y-rc1 Линуса или, при необходимости, на более позднем теге стабильного релиза ядра X.Y.Z. Если в течение цикла кандидатов в релиз ядра выявляются серьёзные проблемы и разрабатывается патч, он может стать кандидатом на маркировку как стабильный патч ядра и включение в ветку stable-X.Y. В основной документации ядра Linux о стабильных патчах содержится дополнительная информация как о том, какие патчи могут быть кандидатами в стабильное ядро, так и о том, как правильно помечать такие патчи; также следует ожидать обсуждений в upstream-списке рассылки относительно целесообразности пометки патча для стабильного ядра. После того как патч объединён в ветку stable-X.Y и провёл день-два в ветке next (см. примечания о ветке next), он будет отправлен Линусу для включения в следующий кандидат в релиз или финальный релиз ядра (см. примечания о pull request в этом документе). Если патч был должным образом помечен для стабильного ядра, другие стабильные деревья ядра попытаются выполнить бэкпорт патча, как только он появится в дереве Линуса; подробнее см. основную документацию ядра Linux.

Если это не было специально запрошено, разработчикам не следует основывать свои патчи на ветке stable-X.Y. Любые конфликты слияния, возникающие при объединении патчей, отправленных в upstream, будут устраняться мейнтейнером, хотя в крайних случаях может быть запрошена помощь и/или.

Ветка dev

Ветка dev предназначена для разрабатываемых патчей, нацеленных на предстоящее окно слияния, и основана на последнем теге X.Y-rc1 Линуса или, при необходимости, на более позднем rc-теге, чтобы избежать серьёзных ошибок, конфликтов слияния или других значительных проблем. Эта ветка является основной веткой разработки, в которую объединяется большинство патчей в ходе обычного цикла разработки ядра. Патчи, объединённые в ветку dev, будут присутствовать в ветке next (см. примечания о ветке next) и будут отправлены Линусу во время следующего окна слияния.

Разработчикам следует использовать ветку dev как стабильную основу для собственной работы; только в исключительных обстоятельствах ветка dev будет перебазирована в течение цикла X.Y-rc, и мейнтейнер будет нести ответственность за разрешение любых конфликтов слияния, хотя в крайних случаях может быть запрошена помощь и/или.

Ветка dev-staging

Ветка dev-staging предназначена для разрабатываемых патчей, которые не нацелены на конкретное окно слияния. Ветка dev-staging существует как промежуточная область для основной ветки dev, и поэтому её использование будет непредсказуемым, а перебазирование будет выполняться по мере необходимости. Патчи, объединённые в ветку dev-staging, в какой-то момент в будущем должны попасть в основную ветку dev, хотя это не гарантируется.

Если это не было специально запрошено, разработчикам не следует использовать ветку dev-staging в качестве основы для любой работы.

Ветка next

Ветка next является составной веткой, создаваемой путём слияния последних веток stable-X.Y и dev в указанном порядке. Основная цель ветки next — предоставить единую ветку для интеграционного тестирования linux-next, содержащую все коммиты из составляющих веток. Ветка next будет обновляться при любом изменении любой из составляющих веток, но останется замороженной во время окна слияния, чтобы соответствовать пожеланиям команды linux-next.

Хотя разработчики могут использовать ветку next в качестве основы для разработки, ветка dev, вероятно, была бы более подходящей и стабильной основой.

Процесс разработки ядра

После того как Линус закроет окно слияния ядра в upstream, ветка stable-X.Y, связанная с текущим кандидатом в релиз ядра, ветка dev и, возможно, ветка dev-staging (см. примечания о ветке dev-staging) будут сброшены в соответствии с последним тегом vX.Y-rc1 в дереве Линуса. Ветка next как составная ветка, формируемая из этих веток, будет обновлена соответствующим образом.

В течение цикла разработки, который начинается с закрытия окна слияния ядра и заканчивается помеченным релизом ядра, патчи будут приниматься в ветки stable-X.Y и dev, как описано в соответствующих разделах этого документа. Хотя патчи будут приниматься в ветку stable-X.Y в любой момент времени, значительные изменения, скорее всего, не будут приниматься в ветку dev, когда до конца цикла разработки останется две недели или меньше; это обычно означает, что после выпуска ядра vX.Y-rc6 принимаются только критические исправления ошибок. В течение этого времени ветка next будет перегенерироваться по мере необходимости на основе изменений в составляющих ветках, а Линусу будут по мере необходимости отправляться pull request для патчей в ветке stable-X.Y.

Как только Линус выпустит финальное ядро vX.Y и откроется окно слияния, произойдут две вещи. Во-первых, ветка dev будет продублирована в новую ветку stable-X'.Y', представляющую новый предстоящий релиз ядра, а во-вторых, из этой ветки будет отправлен pull request для включения в текущее окно слияния. В процессе окна слияния ветки dev и next должны быть заморожены, хотя существует вероятность, что некоторые патчи могут быть объединены в dev-staging по причинам, связанным с тестированием или процессом.

Pull request для Линуса

Чтобы отправить pull request Линусу — либо для критического исправления ошибки, либо в рамках окна слияния — необходимо создать подписанный git-тег, указывающий на точку pull request. Тег должен называться по формату «{subsystem}-pr-{date}» и может быть создан с помощью следующей git-команды:

% git tag -s -m "{subsystem}/stable-X'.Y' PR {date}" {subsystem}-pr-{date}

После создания подписанного тега он должен использоваться в качестве основы для pull request.

Инструменты пользовательского пространства и тестовые наборы

Инструменты аудита пользовательского пространства и тестовые наборы размещаются на GitHub:

• https://github.com/linux-audit