Como mais de 7.000 testes moldaram o novo perfil AppArmor do MariaDB

Os módulos de segurança do kernel Linux fornecem uma boa camada adicional de segurança em torno de programas individuais, restringindo o que eles podem fazer e, na melhor das hipóteses, bloqueando e detectando vulnerabilidades de segurança de dia zero assim que alguém tentar explorá-las, muito antes de serem amplamente conhecidas e relatadas. Contudo, o desafio é como criar esses perfis de segurança sem bloquear acidentalmente ações legítimas. Para MariaDB no Debian e Ubuntu, um novo perfil AppArmor foi criado recentemente aproveitando o extenso conjunto de testes com mais de 7.000 testes, dando boa confiança de que é improvável que o AppArmor produza alertas falsos positivos com ele.

AppArmor é um sistema de controle de acesso obrigatório (MAC), o que significa que cada processo controlado pelo AppArmor possui uma espécie de “lista de permissões” chamada perfil que define todos os recursos e caminhos de arquivo que um programa pode acessar. Se um programa tentar fazer algo não coberto pelas regras em seu perfil AppArmor, a ação será negada no nível do kernel Linux e um aviso será registrado no diário do sistema. Essa camada de segurança adicional é valiosa porque, mesmo que um usuário mal-intencionado encontre uma vulnerabilidade de segurança algum dia no futuro, o perfil do AppArmor restringe severamente a capacidade de explorá-la e obter acesso ao sistema operacional.

O AppArmor foi originalmente desenvolvido pela Novell para uso em SUSELinuxmas hoje em dia o driver principal é a Canonical e o AppArmor é amplamente utilizado em Ubuntu e Debiane muitos de seus derivados (por exemplo, Linux Mint, Pop!_OS, Zorin OS) e em Arco. O benefício do AppArmor em comparação com a principal alternativa SELinux (usada principalmente no ecossistema RedHat/Fedora) é que o AppArmor é mais fácil de gerenciar. O AppArmor continua a ser desenvolvido ativamente, com a nova versão principal 5.0 prevista para chegar em breve.

Também tenho um histórico pessoal contribuindo com alguns scripts de tratamento de notificação em Python e também criei o site que AppArmor.net ainda corre.

É necessária revisão regular de negações no log do sistema

Qualquer administrador de sistema que use Debian/Ubuntu precisa saber como verificar negações do AppArmor. O objetivo de usar o AppArmor é meio discutível se ninguém estiver verificando as negações. Quando o AppArmor bloqueia uma ação, ele registra o evento na auditoria do sistema ou nos logs do kernel. Compreender esses logs é crucial para solucionar problemas de configurações personalizadas ou identificar possíveis incidentes de segurança.

Para visualizar negações recentes, verifique /var/log/audit/audit.log ou correr journalctl -ke --grep=apparmor.

Uma entrada de negação típica para MariaDB será semelhante a esta (dividida em várias linhas para maior legibilidade):

msg=audit(1700000000.123:456): apparmor="DENIED" operation="open"
profile="/usr/sbin/mariadbd" name="/custom/data/path/test.ibd" pid=1234
comm="mariadbd" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Como interpretar esta saída:

• msg=audit(…): O carimbo de data/hora da auditoria e o número de série do evento.
• apparmor=“NEGADO”: Indica que o AppArmor bloqueou a ação.
• operação: A ação que está sendo tentada (por exemplo, open, mknod, file_mmap, file_perm).
• perfil: O perfil específico do AppArmor que acionou a negação (neste caso, o /usr/sbin/mariadbd perfil).
• nome: o caminho do arquivo ou recurso que foi bloqueado. No exemplo acima, um caminho de dados personalizado teve acesso negado porque não foi definido nas abstrações permitidas do perfil.
• comm: O nome do comando que acionou a negação (aqui mariadbd).
• request_mask / negado_mask: Mostra as permissões solicitadas (por exemplo, r para ler, w para escrever).
• pid: o ID do processo.
• fsuid: O ID do usuário do processo que está tentando executar a ação.
• ouid: O ID do usuário proprietário do arquivo de destino.

Se uma ação parece legítima e não deve ser negada, o administrador do sistema precisa atualizar as regras existentes em /etc/apparmor.d/ ou coloque um arquivo de personalização local em /etc/apparmor.d/local/. Se a ação negada parecer maliciosa, o administrador do sistema deve iniciar uma investigação de segurança e, se necessário, relatar uma suspeita de vulnerabilidade de dia zero ao fornecedor de software upstream (por exemplo, clientes Ubuntu para Canonical ou clientes MariaDB para MariaDB).

AppArmor no MariaDB – não é uma coisa nova e não é fácil de implementar bem

Baseado em relatórios de bugs antigosjá existia um perfil AppArmor em 2011, mas ele foi removido no MariaDB 5.1.56 devido à reação de usuários que enfrentaram vários problemas. Um novo perfil foi criado em 2015mas manteve a adesão apenas devido ao risco de efeitos colaterais. Provavelmente tinha poucos usuários e recebia manutenção mínima, recebendo apenas algumas atualizações nos últimos 10 anos.

O principal desafio em usar sistemas de controle de acesso obrigatórios com MariaDB reside em a grande amplitude da pegada operacional do MariaDB com diversos mecanismos de armazenamento e plug-ins. Além disso, a base de código no MariaDB pressupõe que as chamadas de sistema para Linux sempre funcionam – o que acontece em circunstâncias normais – e não lidam bem com erros se o AppArmor negar repentinamente uma chamada de sistema. MariaDB também é um software grande e complexo para executar e operar, e pode ser muito desafiador para os administradores de sistema descobrirem que um mau comportamento em seu sistema foi devido ao bloqueio do AppArmor de uma única chamada de sistema.

Ironicamente, o AppArmor é mais benéfico exatamente pelos mesmos motivos do MariaDB. Quanto maior e mais complexo for um software, maiores serão as chances de surgir uma vulnerabilidade de segurança entre os vários componentes. E o perfil AppArmor ajuda a reduzir essa complexidade para uma única lista de acesso.

Ao longo dos anos, houve usuários solicitando a recuperação do perfil do AppArmor, como Bug Debian#875890 desde 2017. A necessidade foi levantada recentemente novamente pela equipe de segurança do Ubuntu durante o Revisão de inclusão ‘principal’ do MariaDB Ubuntu em 2025, o que gerou um esforço renovado por parte dos desenvolvedores Debian/Ubuntu, principalmente eu mesmo e Áquila Macedocom assistência upstream do MariaDB de Daniel Negro.

Uma nova abordagem: aproveite o conjunto de testes MariaDB para testes automatizados e a comunidade de código aberto para análises

A chave para criar um perfil robusto do AppArmor é a capacidade de saber em detalhes o que é esperado e normal comportamento do sistema. Em teoria, seria possível ler todo o código-fonte no MariaDB, mas com mais de dois milhões de linhas, é claro que isso não é viável na prática. No entanto, o MariaDB tem um conjunto de testes muito extenso com mais de 7.000 testes e executá-lo deve acionar a maioria dos caminhos de código no MariaDB. Utilizando o suíte de testes foi fundamental na criação do novo perfil AppArmor para MariaDB: instalamos o MariaDB em um sistema Ubuntu, habilitamos o AppArmor em complain modo e iterado no lista de permissões executando o completo mariadb-test-run com todos os plug-ins e recursos do MariaDB habilitados até termos uma lista de regras abrangente, porém limpa.

Para sermos ainda mais diligentes, também reformulamos o carpkgtest para que o MariaDB em sistemas CI Debian e Ubuntu seja executado com o perfil AppArmor habilitado e imprima todos os avisos do AppArmor no final da execução, facilitando a detecção agora e no futuro se o conjunto de testes MariaDB acionar alguma negação do AppArmor. Se algum teste falhar, o lançamento não será mais promovido, protegendo os usuários de regressões.

Ao desenvolver e acionar execuções de testes manuais, usamos o conjunto de testes máximo alcançável com 7.177 testes. No entanto, o teste é tão extenso que leva mais de duas horas para ser executado e também possui alguns testes frágeis, portanto, o teste padrão executado no Debian e no Ubuntu autopkgtest é limitado apenas ao conjunto principal do MariaDB com cerca de 1000 testes. Ter alguns testes falhando ao testar o perfil do AppArmor não foi um problema, porque não precisávamos que todos os testes fossem aprovados – apenas precisávamos que eles executassem o maior número possível de caminhos de código para ver se executavam alguma chamada de sistema não contabilizada no perfil do AppArmor.

Observe que estender o perfil não foi apenas uma cópia mecânica de mensagens de log para o perfil. Por exemplo, mesmo que alguns testes envolvam a execução do escudo de traçodecidimos não permitir isso, pois abre muito caminho para que uma possível exploração acesse o sistema operacional.

O resultado deste esforço é um perfil modernizado e robusto que agora está pronto para produção. Os interessados ​​nos detalhes técnicos exatos podem ler o Bug Debian#1130272 e o Discussões sobre solicitação de mesclagem em salsa.debian.orgque hospeda o código-fonte do pacote Debian.

Agora disponível no Debian instável, em breve no Ubuntu – feedback bem-vindo!

Mesmo que o arquivo tem apenas 200 linhaso trabalho para elaborá-lo durou várias semanas. Para minimizar o risco, também fizemos uma implementação gradual, lançando a primeira nova versão do perfil em complain modo, então o AppArmor registra apenas possíveis negações sem bloquear nada. O perfil do AppArmor foi alterado para enforce modo apenas na última revisão 1:11.8.6-4 do MariaDB no Debian, e um item NEWS foi emitido para ajudar a aumentar a conscientização do usuário sobre esta mudança. Também está previsto para o próximo lançamento do Ubuntu 26.04 “Resolute Raccoon” no próximo mês, fornecendo proteção pronta para uso para o ecossistema mais amplo.

Embora os testes automatizados sejam extensos, eles não podem simular tudo. Mais notavelmente, várias topologias de replicação complicadas e todas as configurações do Galera provavelmente não serão abordadas. Portanto, estou convocando a comunidade para implantar este perfil e monitorar quaisquer negações de auditoria nos logs do kernel. Se você encontrar comportamento inesperado ou negações legítimas, envie um relatório de bug através do Sistema de rastreamento de bugs do Debian.

Para garantir que você está executando a versão mais recente do MariaDB, execute apt install --update --yes mariadb-server. Para visualizar as regras de perfil mais recentes, execute cat /etc/apparmor.d/mariadbd e para ver se é aplicado, revise a saída de aa-status. Para verificar rapidamente se houve alguma negação do AppArmor, basta executar journalctl -k | grep -i apparmor | grep -i mariadb.

O fortalecimento do Systemd também foi adotado à medida que os recursos de segurança continuam evoluindo

Para aqueles interessados ​​no fortalecimento da segurança do MariaDB, observe que também novas opções de proteção do systemd foram lançados no Debian/Ubuntu recentemente. Observe que o Debian e o Ubuntu são principalmente comunidades de desenvolvedores de código aberto dirigidas por voluntários, e se você achar este tópico interessante e achar que possui as habilidades necessárias, sinta-se à vontade para enviar suas ideias de melhoria como solicitações de mesclagem em salsa.debian.org/mariadb-team. Se suas sugestões de melhorias não forem específicas do Debian/Ubuntu, envie-as diretamente para o upstream em GitHub.com/MariaDB.