Subsistema de Auditoria do Kernel Linux

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

O subsistema de auditoria do Linux fornece uma estrutura segura de registro de logs usada para capturar e gravar eventos relevantes à segurança. Ele consiste em um componente do kernel que gera registros de auditoria com base na atividade do sistema, um daemon em espaço de usuário que registra esses registros em um arquivo local ou em um servidor remoto de agregação, e um conjunto de ferramentas de espaço de usuário para inspeção e pós-processamento dos logs de auditoria.

O README principal do kernel Linux pode ser encontrado em Documentation/admin-guide/README.rst

Recursos Online

O repositório canônico do kernel de auditoria é hospedado pelo 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

Há também um espelho do GitHub mantido oficialmente:

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

Branches do Código Fonte do Kernel e Processo de Desenvolvimento

Branches do Código Fonte do Kernel

Há quatro branches git principais associados ao processo de desenvolvimento: stable-X.Y, dev, dev-staging e next. Além desses quatro branches principais, também existem branches específicos de tópicos, trabalhos em andamento que começam com um prefixo "working-"; esses branches geralmente podem ser ignorados, a menos que você esteja envolvido no desenvolvimento daquele tópico específico. A gestão desses branches de tópicos pode variar dependendo de vários fatores, mas os detalhes de cada branch serão comunicados nas discussões relevantes na lista de discussão upstream.

Branch stable-X.Y

O branch stable-X.Y se destina a patches estáveis do kernel e é baseado no tag X.Y-rc1 do Linus, ou em um tag de lançamento de kernel estável X.Y.Z posterior, conforme necessário. Se problemas sérios forem identificados e um patch for desenvolvido durante o ciclo de candidatos a lançamento do kernel, ele poderá ser candidato à marcação de kernel estável e inclusão no branch stable-X.Y. A documentação principal do kernel Linux sobre patches estáveis do kernel tem mais informações tanto sobre quais patches podem ser candidatos a kernel estável, quanto sobre como marcá-los adequadamente; discussões na lista de discussão upstream sobre os méritos de marcar o patch para estável também podem ser esperadas. Uma vez que um patch tenha sido mesclado no branch stable-X.Y e passado um dia ou dois no branch next (veja as notas do branch next), ele será enviado ao Linus para mesclagem no próximo candidato a lançamento ou lançamento final do kernel (veja as notas sobre pull requests neste documento). Se o patch foi marcado adequadamente para estável, as outras árvores de kernel estável tentarão fazer o backport do patch assim que ele estiver presente na árvore do Linus, consulte a documentação principal do kernel Linux para mais detalhes.

A menos que solicitado especificamente, os desenvolvedores não devem basear seus patches no branch stable-X.Y. Quaisquer conflitos de merge que surgirem da mesclagem de patches enviados upstream serão tratados pelo mantenedor, embora ajuda e/ou possa ser solicitada em casos extremos.

Branch dev

O branch dev se destina a patches de desenvolvimento direcionados à próxima janela de merge, e é baseado no tag X.Y-rc1 mais recente do Linus, ou em um tag rc posterior, conforme necessário, para evitar bugs graves, conflitos de merge ou outros problemas significativos. Este branch é o branch de desenvolvimento principal, onde a maioria dos patches é mesclada durante o ciclo normal de desenvolvimento do kernel. Os patches mesclados no branch dev estarão presentes no branch next (veja as notas do branch next) e serão enviados ao Linus durante a próxima janela de merge.

Os desenvolvedores devem usar o branch dev como base estável para seu próprio trabalho de desenvolvimento; somente em circunstâncias extremas o branch dev será rebaseado durante o ciclo X.Y-rc, e o mantenedor será responsável por resolver quaisquer conflitos de merge, embora ajuda e/ou possa ser solicitada em casos extremos.

Branch dev-staging

O branch dev-staging se destina a patches de desenvolvimento que não têm como alvo uma janela de merge específica. O branch dev-staging existe como uma área de staging para o branch dev principal e, como tal, seu uso será imprevisível e ele será rebaseado conforme necessário. Os patches mesclados no branch dev-staging devem chegar ao branch dev principal em algum momento no futuro, embora isso não seja garantido.

A menos que solicitado especificamente, os desenvolvedores não devem usar o branch dev-staging como base para qualquer trabalho de desenvolvimento.

Branch next

O branch next é um branch composto construído pela mesclagem dos branches stable-X.Y e dev mais recentes, nessa ordem. O foco principal do branch next é fornecer um único branch para testes de integração com linux-next que contenha todos os commits dos branches componentes. O branch next será atualizado sempre que houver uma mudança em qualquer um dos branches componentes, mas permanecerá congelado durante a janela de merge para cooperar com os desejos da equipe do linux-next.

Embora os desenvolvedores possam usar o branch next como base para desenvolvimento, o branch dev provavelmente seria uma base mais adequada e estável.

Processo de Desenvolvimento do Kernel

Depois que o Linus fecha a janela de merge do kernel upstream, o branch stable-X.Y associado ao atual candidato a lançamento do kernel, o branch dev e potencialmente o branch dev-staging (veja as notas do branch dev-staging) serão redefinidos para corresponder ao tag vX.Y-rc1 mais recente na árvore do Linus. O branch next, como um branch composto a partir desses branches, será atualizado como resultado.

Durante o ciclo de desenvolvimento que começa com o fechamento da janela de merge do kernel e termina com o lançamento do kernel etiquetado, patches serão aceitos nos branches stable-X.Y e dev, conforme descrito em suas respectivas seções neste documento. Embora patches sejam aceitos no branch stable-X.Y a qualquer momento, mudanças significativas provavelmente não serão aceitas no branch dev quando faltarem duas semanas ou menos no ciclo de desenvolvimento; isso normalmente significa que apenas correções críticas de bugs são aceitas quando o kernel vX.Y-rc6 é lançado. Durante esse período, o branch next será regenerado conforme a necessidade, com base nas mudanças nos branches componentes, e pull requests serão enviadas conforme necessário ao Linus para patches no branch stable-X.Y.

Quando o Linus lança o kernel final vX.Y e a janela de merge se abre, duas coisas acontecerão. A primeira é que o branch dev será duplicado em um novo branch stable-X'.Y', representando o novo lançamento iminente do kernel, e a segunda é que um pull request será enviado a partir desse branch para inclusão na janela de merge atual. Durante o processo da janela de merge, os branches dev e next devem permanecer congelados, embora exista a possibilidade de que alguns patches sejam mesclados no dev-staging por motivos relacionados a testes ou ao processo.

Pull Requests para o Linus

Para enviar um pull request ao Linus, seja para uma correção crítica de bug ou como parte da janela de merge, um git tag assinado deve ser criado apontando para o ponto do pull request. O tag deve ser nomeado usando o formato "{subsystem}-pr-{date}" e pode ser gerado com o seguinte comando git:

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

Depois que o tag assinado for criado, ele deve ser usado como base para o pull request.

Ferramentas de Userspace e Suítes de Testes

As ferramentas de userspace do audit e as suítes de testes são hospedadas pelo GitHub:

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