Início
» LINUX
»
Como configurar perfis do AppArmor para aplicativos personalizados no SUSE SLES 15
Como configurar perfis do AppArmor para aplicativos personalizados no SUSE SLES 15
Nota de versão, verificada em 6 de outubro de 2026: Este procedimento se aplica ao SUSE Linux Enterprise Server (SLES) 15 SP7 e sistemas SLE 15 compatíveis que utilizam o AppArmor. A SUSE documenta o AppArmor como instalado e em execução por padrão no SLES 15 SP7. O SUSE Linux 16.0 remove o AppArmor e utiliza o SELinux em seu lugar; portanto, não aplique os comandos abaixo à versão 16.0; utilize o guia de comparação do SUSE Linux 16.0 e a documentação do SELinux para essa versão.
O AppArmor é um módulo de segurança do Linux que restringe o acesso de um programa a determinados arquivos. Um perfil é a política associada a um executável: ele pode permitir ou negar o acesso a arquivos, funcionalidades e outros recursos. Este guia orienta você desde a confirmação da plataforma até a aplicação de um perfil testado, com uma fase de aprendizado cautelosa para que uma aplicação personalizada tenha menos probabilidade de apresentar falhas inesperadas.
O que você deve preparar antes de criar um perfil?
Use uma janela de teste ou manutenção se o aplicativo for importante. Você precisa de uma conta de administrador com privilégios de administrador sudo, o caminho real do executável do aplicativo e uma lista das tarefas normais que ele executa. Inclua tarefas em segundo plano, inicialização e desligamento, recarregamento de configurações, uploads ou exportações, tarefas agendadas e quaisquer funções conectadas à rede. Um perfil aprendido a partir de uma única execução não pode inferir recursos que você nunca utiliza.
Saiba onde o aplicativo lê e grava dados, qual conta o executa e se ele inicia processos auxiliares. Evite testar com dados de produção sensíveis sempre que possível. Registre o estado atual do serviço e mantenha uma cópia de qualquer perfil existente antes de fazer alterações.
Como posso confirmar se o AppArmor está disponível nesta versão do SUSE?
Primeiro, verifique a versão do sistema operacional e o estado atual do AppArmor:
cat /etc/os-release
sudo aa-status
Verifique primeiro a versão do SUSE; o comando mostrado lê o arquivo de identificação do sistema operacional.Use o comando aa-status para verificar se o AppArmor está ativo e quais perfis estão carregados.
Confirme se o sistema reporta o SLES 15 SP7 ou outra versão cuja documentação suporte o AppArmor. No SLES 15 SP7, o guia da SUSE afirma que o AppArmor está instalado e em execução por padrão. Caso não esteja instalado, a SUSE documenta a instalação com o comando ` sudo zypper in -t pattern apparmorsudo apt install apparmor`. Se o serviço estiver instalado, mas não em execução, verifique a política de inicialização do sistema e o status do serviço antes de habilitá-lo; não desabilite o módulo de segurança para contornar um problema de aplicativo. Consulte o guia de primeiros passos do AppArmor para SLES 15 SP7 e o guia de ferramentas de linha de comando do AppArmor para SLES 15 SP7 para obter detalhes específicos da versão.
Como identificar o executável que o AppArmor deve analisar?
Os perfis do AppArmor estão associados a caminhos de programas, portanto, identifique o executável real em vez de presumir que o comando digitado pelo usuário seja o binário. Para um comando disponível no caminho do shell, execute:
command -v myapp
Substitua `myapp` pelo comando do aplicativo e confirme o caminho do executável resolvido antes de gerar o perfil.
Para um serviço, inspecione sua definição de unidade e detalhes do processo usando as ferramentas disponíveis em seu sistema. Um script de inicialização, link simbólico ou interpretador pode levar a um executável diferente do esperado. Resolva um caminho conhecido quando readlink -f /path/to/myappapropriado. Substitua o caminho absoluto verificado em cada comando abaixo; /usr/local/bin/myappé apenas um exemplo.
Antes de criar um perfil, verifique se já existe um perfil em `/profiles` /etc/apparmor.d. O SUSE armazena perfis lá, e o nome do arquivo geralmente substitui as barras no caminho do executável por pontos. Por exemplo, ` /usr/local/bin/myapp/profiles` corresponde a um nome de arquivo como ` usr.local.bin.myapp/profiles`. Não sobrescreva um perfil existente de fornecedor ou mantido localmente sem revisá-lo. O SUSE também lista perfis adicionais em `/profiles` /usr/share/apparmor/extra-profiles; um perfil adequado pode servir como ponto de partida, mas ainda precisa ser revisado para sua aplicação e versão ( documentação do repositório de perfis do SUSE ).
Como gerar um perfil inicial de forma segura?
Execute a ferramenta de geração de perfil como administrador, usando o caminho completo do executável:
sudo aa-genprof /usr/local/bin/myapp
Inicie o aa-genprof com o caminho do executável verificado; o caminho aqui é um exemplo a ser substituído.
aa-genprofCria um perfil inicial e coloca o programa em modo de reclamação enquanto você o utiliza. O modo de reclamação registra violações de política, mas não bloqueia a operação negada, o que permite observar o comportamento antes da aplicação das regras. Siga as instruções da ferramenta; após utilizar o aplicativo, use a opção de verificação para revisar os eventos registrados. A SUSE descreve isso como um processo iterativo, não uma garantia de que o perfil sugerido automaticamente esteja completo.
Quais ações você deve testar e onde encontra as negativas?
Enquanto o perfil estiver em modo de reclamação, use o aplicativo como um usuário normal faria. Teste fluxos de trabalho comuns e tarefas menos frequentes, porém suportadas, incluindo leituras, gravações, uploads, geração de relatórios, reinicializações de serviços e tarefas auxiliares. Mantenha o teste realista: um programa pode usar arquivos ou processos filhos diferentes para uma exportação do que para sua tela inicial.
Analise as mensagens do kernel e o log de auditoria em busca de eventos do AppArmor:
sudo journalctl -k | grep -i apparmor
Após executar o programa, inspecione as mensagens do kernel em busca de eventos do AppArmor; este comando exibe as entradas correspondentes, se presentes.
Dependendo da configuração de registro do sistema, o SUSE também aponta para /var/log/audit/audit.log`log_file`, journalctl | grep -i apparmor`log_file` e ` dmesg -Tlog_file`. A ausência de correspondência em uma visualização de log não comprova que o perfil esteja correto: verifique se o aplicativo foi executado e consulte o serviço de registro e outros locais de log documentados. Não considere um perfil gerado como testado apenas porque o aplicativo foi iniciado uma vez.
Como você deve revisar e aprimorar o perfil?
Como usuário root, utilize aa-logprofo comando para processar eventos registrados e responder às solicitações:
sudo aa-logprof
Use o aa-logprof para examinar os acessos observados e decidir quais pertencem à política do aplicativo.
Para cada evento, verifique se o acesso é necessário para uma tarefa documentada do aplicativo. Permita apenas o caminho restrito, o modo de acesso ou a capacidade que o programa exige. A leitura de um arquivo de configuração pode ser esperada; uma gravação não planejada em um diretório não relacionado pode sinalizar um erro ou um componente separado que precisa ser investigado. Regras muito amplas enfraquecem o confinamento, enquanto regras muito restritas podem interromper tarefas válidas.
Não aceite automaticamente todas as solicitações nem conceda acesso irrestrito a todos os arquivos.
Evite o uso de curingas genéricos e capacidades desnecessárias; prefira um caminho preciso e as permissões mínimas necessárias.
Repita o ciclo de carga de trabalho e revisão de logs após edições de perfil. Inclua operações de serviço e tarefas em segundo plano separadas.
Mantenha as alterações restritas ao aplicativo de destino; não faça edições de perfil não relacionadas para eliminar ruídos.
O perfil é um limite de controle de acesso, portanto, uma solicitação deve ser respondida com base no comportamento do aplicativo e nos requisitos operacionais, e não simplesmente porque apareceu em um log. O guia de ferramentas de linha de comando do SUSE SLES 15 SP7 AppArmor explica as ferramentas de linha de comando, e a referência de suporte do SUSE AppArmor fornece links para páginas de manual relevantes, incluindo `apparmor.man` aa-genprof, aa-logprof`apparmor.man` e ` apparmor.man` apparmor_parser.
Quando você deve ativar o modo de imposição no perfil?
Passe para a aplicação da política somente após a conclusão bem-sucedida dos fluxos de trabalho representativos e a revisão dos eventos legítimos. Aplique o perfil de aplicativo específico, recarregue o conjunto de perfis do AppArmor e reinicie o aplicativo ou serviço para que o processo em execução utilize a política atualizada.
Aplique as restrições ao perfil de destino e, em seguida, recarregue o AppArmor; substitua o caminho de exemplo pelo executável verificado.
A SUSE observa que a recarga relê os perfis /etc/apparmor.d; um programa já em execução pode precisar ser reiniciado para que o perfil atualizado entre em vigor. Coordene essa reinicialização com o proprietário do serviço e use o comando de gerenciamento de serviços correto para o aplicativo. Em seguida, repita os fluxos de trabalho principais em modo de imposição, em vez de presumir que o sucesso no modo de reclamação comprova que eles funcionarão sem alterações.
Como verificar o resultado e se recuperar de uma regressão?
Verifique o estado do perfil e procure por novas rejeições após o teste:
Verifique o perfil carregado e revise as novas mensagens do AppArmor após executar o aplicativo no modo de imposição.
Confirme se o perfil desejado está carregado e em modo de imposição, se o serviço permanece íntegro e se cada tarefa necessária ainda funciona. Se a imposição bloquear uma operação legítima, colete o evento relevante, verifique se o acesso é realmente necessário e refine o perfil de forma precisa. Para um diagnóstico rápido e controlado, sudo aa-complain /usr/local/bin/myappvocê pode colocar o perfil do programa em modo de reclamação; investigue, atualize e teste novamente antes de retornar ao modo de imposição aa-enforce. Recarregue e reinicie conforme necessário. Evite desativar o AppArmor globalmente ou conceder permissões amplas como uma solução rápida.
Que erros comuns você deve evitar?
Instruções de instalação incorretas: o fluxo de trabalho aqui descrito é para o AppArmor do SLES 15. O SUSE Linux 16.0 utiliza o SELinux, de acordo com o guia de comparação da SUSE.
Analisar o desempenho de um wrapper em vez do programa real: verifique o executável que realmente é executado, especialmente para serviços e scripts.
Aprender muito pouco: recursos não testados não geram acessos observados, portanto, um perfil incompleto pode falhar posteriormente.
Aprovar solicitações sem contexto: cada permissão adicionada deve servir a uma tarefa necessária do aplicativo.
Esquecendo a reinicialização: recarregue os perfis e, em seguida, reinicie o aplicativo em execução quando necessário para que o processo adote a política.
Edição sem caminho de reversão: faça backup dos perfis mantidos localmente e acompanhe as alterações no controle de versão ou no processo de gerenciamento de configuração do seu sistema.
Estas referências foram verificadas em 6 de outubro de 2026. Os comandos e detalhes do pacote podem variar conforme a versão do produto; confirme a documentação do pacote de serviços SLES instalado antes de fazer alterações.