Crie um perfil AppArmor personalizado no SUSE Linux.

A SUSE anunciou o SLES 16.0 em 4 de novembro de 2025, com o SELinux substituindo o AppArmor como a estrutura de controle de acesso obrigatória padrão. Se o seu servidor estiver executando o SLES 16, não presuma que o AppArmor esteja instalado ou ativo: confirme a estrutura suportada por essa implementação antes de usar estes comandos. O procedimento abaixo segue a documentação do AppArmor para o SLES 15 SP7 da SUSE, onde o AppArmor está instalado e em execução por padrão.

No SLES 15 SP7, o caminho prático para um aplicativo personalizado é permitir que o sistema aa-genprofcrie um perfil inicial, execute o aplicativo no modo de reclamação, revise cada solicitação registrada e, em seguida, confirme se o perfil está sendo aplicado. O exemplo usa um executável hipotético em /usr/local/bin/report-worker; substitua-o pelo caminho real do executável do seu aplicativo.

Antes de começar

Os perfis do AppArmor são políticas de texto armazenadas em /etc/apparmor.d. O apparmor-utilspacote fornece as ferramentas de criação de perfil. Verifique o host e identifique o executável real, incluindo se uma unidade do systemd inicia um processo wrapper ou filho:

sudo aa-status
command -v aa-genprof
systemctl status apparmor
readlink -f /usr/local/bin/report-worker

A SUSE lista o AppArmor como habilitado por padrão nas instalações do SLES 15. Se as ferramentas ou o padrão completo do AppArmor estiverem faltando, instale o padrão com [comando de instalação] sudo zypper in -t pattern apparmor. Se o AppArmor não estiver ativo, resolva o problema antes de criar o perfil, em vez de presumir que apenas um arquivo de perfil oferece proteção. Um perfil é associado a um caminho executável; criar um perfil de um wrapper quando a carga de trabalho real é executada como outro binário pode deixar o processo importante sem proteção.

Criar e refinar o perfil

1. Inicie o gerador. Se o aplicativo já estiver em execução, pare-o e, em seguida, inicie a geração do perfil:

   sudo systemctl stop report-worker
   sudo aa-genprof /usr/local/bin/report-worker

   

   O nome do serviço é um exemplo. Use o nome real da unidade ou omita o comando de parada se o programa não estiver em execução. aa-genprofCria um perfil aproximado quando não existe um, coloca-o em modo de reclamação (aprendizagem), recarrega-o e marca o log. O modo de reclamação registra solicitações fora da política, mas as permite; é um estado de aprendizagem temporário, não de imposição.

2. Simule o comportamento real da aplicação. Mantenha o gerador aberto. Em outro terminal, inicie o serviço e execute tarefas ou funcionalidades representativas:

   sudo systemctl start report-worker
   sudo journalctl -f

   

   O perfil abrange a inicialização normal, os caminhos de entrada e saída esperados, as tarefas agendadas, o tratamento de erros e quaisquer programas auxiliares que o aplicativo execute. Um perfil só pode aprender as solicitações geradas durante o teste. Não use cargas de trabalho sensíveis à produção apenas para gerar eventos; um ambiente de teste seguro e dados de teste representativos são preferíveis.

3. Analise cada solicitação de acesso. Retorne aa-genprofe pressione Spara examinar o intervalo de log marcado. Para cada solicitação, decida se o aplicativo realmente precisa daquele arquivo, recurso ou transição de programa filho. Permita o caminho e a permissão úteis mais restritos. Aceite uma abstração quando ela abranger com precisão uma tarefa comum; use um padrão global somente quando os arquivos correspondentes compartilharem os mesmos requisitos de confiança e acesso. Negue ou ignore solicitações que sejam incidentais ou inexplicáveis.

   

   Preste atenção especial às solicitações de execução. Uma transição irrestrita pode permitir que um processo filho escape da política do processo pai; use-a somente quando houver uma necessidade de projeto justificada. Repita o exercício e o ciclo de verificação após adicionar regras legítimas. Quando o perfil abranger o comportamento testado, finalize o gerador. A SUSE observa que a conclusão de um novo aa-genprofciclo de aprendizado normalmente coloca seu perfil em modo de imposição.

4. Inspecione a política gerada. Para este caminho de exemplo, a convenção de nomenclatura do SUSE converte as barras no caminho do executável em pontos, produzindo /etc/apparmor.d/usr.local.bin.report-worker. Analise o resultado em vez de considerar as regras geradas como automaticamente seguras:

   sudo less /etc/apparmor.d/usr.local.bin.report-worker

   

   Verifique se o perfil nomeia o executável pretendido, usa os includes necessários e concede acesso apenas à configuração, aos dados, aos logs, aos sockets e aos programas auxiliares que o aplicativo realmente precisa. Evite regras amplas, como acesso irrestrito a um diretório específico /ou a toda uma árvore de diretórios graváveis, apenas para evitar uma negação. O aplicativo ainda depende da propriedade e das permissões comuns do Unix; o AppArmor adiciona uma camada de restrição separada.

5. Defina explicitamente o modo desejado. Após a revisão, aplique o perfil ao programa personalizado:

   sudo aa-enforce /usr/local/bin/report-worker

   

   Se você editou o perfil manualmente após o gerador ser encerrado, recarregue o conjunto de perfis com sudo systemctl reload apparmor. Os documentos do SUSE são recarregados como perfis de reescaneamento sem liberar os processos em execução. Reinicie o serviço do aplicativo para que a nova política se aplique ao seu processo.

Verifique o pedido em vigor.

Execute novamente as mesmas tarefas representativas enquanto o perfil estiver no modo de imposição. Confirme se o serviço inicia, lê as entradas pretendidas, grava a saída esperada e consegue executar as operações auxiliares ou de rede necessárias. Em seguida, inspecione o estado do perfil e as mensagens recentes do kernel:

sudo aa-status
sudo journalctl -k -g apparmor --since today

O executável personalizado deve aparecer como carregado e em modo de imposição. As negações do AppArmor no registro do kernel identificam solicitações que a política bloqueou; use-as para diagnosticar uma falha real do aplicativo, não como motivo para permitir todos os caminhos registrados. Para uma permissão ausente legítima, execute o comando sudo aa-logprof, revise a sugestão, atualize a regra de forma restrita, recarregue o sistema se você editou manualmente e execute novamente o caminho do aplicativo afetado.

Para um serviço em execução contínua cujo perfilamento deve abranger reinicializações ou períodos de observação mais longos, a SUSE documenta um fluxo de trabalho sistêmico separado usando `sudo` aa-autodep, aa-complain`sudo` e aa-logprofvarreduras repetidas. O método independente aa-genprofé mais simples quando a execução de aprendizado pode permanecer aberta durante todo o teste. Nenhum dos fluxos de trabalho consegue inferir o comportamento de um aplicativo que nunca foi testado, portanto, mantenha o perfil sob revisão sempre que houver alterações de software ou configuração.

Fontes

• SUSE: O que há de novo no SUSE Linux Enterprise Server 16.0
• SUSE SLES 15 SP7: Primeiros passos com o AppArmor
• SUSE SLES 15 SP7: Criando perfis a partir da linha de comando
• SUSE SLES 15 SP7: Componentes de perfil e sintaxe