{"id":2158,"date":"2026-08-10T12:10:27","date_gmt":"2026-08-10T15:10:27","guid":{"rendered":"https:\/\/jrtx.com.br\/blog\/2026\/08\/10\/pam-sudo-apparmor-hardening-e-controle-de-acesso-no-linux\/"},"modified":"2026-08-10T12:10:27","modified_gmt":"2026-08-10T15:10:27","slug":"pam-sudo-apparmor-hardening-e-controle-de-acesso-no-linux","status":"publish","type":"post","link":"https:\/\/jrtx.com.br\/blog\/2026\/08\/10\/pam-sudo-apparmor-hardening-e-controle-de-acesso-no-linux\/","title":{"rendered":"PAM sudo AppArmor: Hardening e Controle de Acesso no Linux"},"content":{"rendered":"

A combina\u00e7\u00e3o de PAM sudo AppArmor<\/strong> representa uma das estrat\u00e9gias mais s\u00f3lidas para hardening<\/strong> e controle de acesso<\/strong> em sistemas Linux modernos. Em ambientes corporativos, onde a superf\u00edcie de ataque cresce a cada nova integra\u00e7\u00e3o, a capacidade de restringir privil\u00e9gios, isolar processos e auditar cada a\u00e7\u00e3o administrativa tornou-se um pilar n\u00e3o negoci\u00e1vel da seguran\u00e7a da informa\u00e7\u00e3o. Na JRT Technology Solutions<\/strong>, implementamos diariamente solu\u00e7\u00f5es que integram essas tr\u00eas camadas \u2014 autentica\u00e7\u00e3o plug\u00e1vel, eleva\u00e7\u00e3o controlada de privil\u00e9gios e confinamento mandat\u00f3rio de aplica\u00e7\u00f5es \u2014 para blindar servidores cr\u00edticos contra escala\u00e7\u00f5es horizontais e verticais.<\/p>\n

O hist\u00f3rico de viola\u00e7\u00f5es envolvendo credenciais comprometidas e permiss\u00f5es excessivas mostra que confiar apenas no modelo discricion\u00e1rio de controle de acesso (DAC) do Linux \u00e9 uma aposta arriscada. Ferramentas como sudo<\/strong> evolu\u00edram muito al\u00e9m do simples “executar como root”, incorporando pol\u00edticas granulares baseadas em usu\u00e1rios, grupos, hosts e comandos. Quando combinadas com o PAM<\/strong> (Pluggable Authentication Modules), abrem\u2011se possibilidades de autentica\u00e7\u00e3o multifator, bloqueio por tentativas e integra\u00e7\u00e3o com diret\u00f3rios corporativos. E quando o AppArmor<\/strong> ou o SELinux<\/strong> s\u00e3o adicionados \u00e0 equa\u00e7\u00e3o, o kernel passa a impor restri\u00e7\u00f5es que nem o superusu\u00e1rio pode contornar \u2014 um salto qualitativo que transforma o servidor em uma fortaleza.<\/p>\n

As not\u00edcias recentes do ecossistema Linux refor\u00e7am essa dire\u00e7\u00e3o. A documenta\u00e7\u00e3o oficial do SUSE Linux Enterprise Server 15 SP7<\/strong> e da vers\u00e3o 16<\/strong> dedicou se\u00e7\u00f5es inteiras \u00e0 configura\u00e7\u00e3o e troubleshooting do SELinux, sinalizando que o mercado de distribui\u00e7\u00f5es enterprise est\u00e1 apostando pesado no MAC (Mandatory Access Control). Paralelamente, an\u00e1lises comparativas como o guia “SELinux vs AppArmor: 6 Fixes for the Best Linux Protection”<\/em> mostram que ambas as tecnologias s\u00e3o maduras, mas exigem abordagens distintas para troubleshooting e implanta\u00e7\u00e3o. Na JRT Technology Solutions<\/strong>, nossos especialistas atuam exatamente nessa interse\u00e7\u00e3o: escolher, configurar e manter a pol\u00edtica de controle de acesso ideal para cada cen\u00e1rio.<\/p>\n

Este artigo foi escrito para profissionais de TI que n\u00e3o querem apenas ativar um m\u00f3dulo de seguran\u00e7a e torcer para que funcione. Vamos mergulhar fundo na arquitetura do PAM, na sintaxe de regras do sudo, na cria\u00e7\u00e3o de perfis do AppArmor e no ferramental de troubleshooting do SELinux. Ao final, voc\u00ea ter\u00e1 um roteiro claro para elevar o n\u00edvel de maturidade de seguran\u00e7a dos seus sistemas Linux, seja em nuvem, on\u2011premises ou em ambientes h\u00edbridos. Tudo isso \u00e9 parte do trabalho que desenvolvemos na JRT Technology Solutions<\/strong>, apoiando empresas na jornada de hardening<\/strong> cont\u00ednuo.<\/p>\n

1. Arquitetura do PAM e a Sintonia Fina com sudo<\/h3>\n

O PAM<\/strong> (Pluggable Authentication Modules) \u00e9 o framework que desacopla a l\u00f3gica de autentica\u00e7\u00e3o das aplica\u00e7\u00f5es no Linux. Em vez de cada servi\u00e7o implementar seu pr\u00f3prio mecanismo de verifica\u00e7\u00e3o de senhas, o PAM oferece uma pilha de m\u00f3dulos configur\u00e1veis que podem ser encadeados para atender a requisitos como autentica\u00e7\u00e3o multifator<\/strong>, bloqueio tempor\u00e1rio<\/strong> ap\u00f3s falhas e mapeamento de usu\u00e1rios<\/strong> via LDAP. Quando falamos de PAM sudo AppArmor<\/strong>, o primeiro passo \u00e9 entender como o sudo se apoia no PAM para validar a identidade do chamador antes de conceder privil\u00e9gios elevados.<\/p>\n

O arquivo \/etc\/pam.d\/sudo<\/strong> \u00e9 o ponto de entrada para essa integra\u00e7\u00e3o. Nele, podemos incluir m\u00f3dulos como pam_tally2.so<\/strong> ou pam_faillock.so<\/strong> para limitar tentativas de senha incorreta, pam_google_authenticator.so<\/strong> para TOTP, ou pam_sss.so<\/strong> para integra\u00e7\u00e3o com FreeIPA\/Active Directory. Na JRT Technology Solutions<\/strong>, frequentemente configuramos stacks PAM que exigem dois fatores para qualquer opera\u00e7\u00e3o com sudo, especialmente em servidores que hospedam dados sens\u00edveis ou interfaces de pagamento.<\/p>\n

Al\u00e9m da autentica\u00e7\u00e3o, o PAM tamb\u00e9m gerencia sess\u00f5es<\/strong> e contas<\/strong>. O m\u00f3dulo pam_loginuid.so<\/strong>, por exemplo, registra o UID de login original em \/proc\/self\/loginuid, permitindo que auditorias rastreiem a identidade real por tr\u00e1s de cada comando privileged \u2014 informa\u00e7\u00e3o crucial quando v\u00e1rios administradores compartilham acesso root via sudo. Um trecho t\u00edpico de \/etc\/pam.d\/sudo que utilizamos em projetos de hardening inclui:<\/p>\n

\nauth       required     pam_env.so\nauth       sufficient   pam_sss.so\nauth       required     pam_deny.so\naccount    required     pam_unix.so\nsession    required     pam_limits.so\nsession    required     pam_loginuid.so\n<\/pre>\n
Essa configura\u00e7\u00e3o garante que somente usu\u00e1rios autenticados via SSSD (com ou sem segundo fator) consigam executar comandos com sudo, e que cada sess\u00e3o seja registrada com o UID de origem. A JRT Technology Solutions<\/strong> j\u00e1 evitou incidentes graves usando exatamente essa abordagem \u2014 em um cliente do setor financeiro, um ataque de for\u00e7a bruta foi barrado pelo m\u00f3dulo pam_faillock<\/strong> antes que qualquer eleva\u00e7\u00e3o de privil\u00e9gio ocorresse.<\/p>\n
Para ambientes que exigem conformidade com padr\u00f5es como PCI\u2011DSS<\/strong> ou ISO 27001<\/strong>, o log gerado pelo PAM e pelo sudo (geralmente em \/var\/log\/auth.log ou via journald) \u00e9 uma mina de ouro. Ferramentas como auditd<\/strong> complementam esse registro, mas a granularidade do sudo \u2014 incluindo o command logging<\/strong> ativado com Defaults log_output<\/em> \u2014 permite reconstruir sess\u00f5es inteiras. \u00c9 importante notar que, sem o PAM sudo AppArmor<\/strong> trabalhando em conjunto, esses logs carecem de contexto de confinamento: um comando sudo pode ser registrado, mas sem garantias de que o processo filho n\u00e3o escapou para \u00e1reas n\u00e3o autorizadas do sistema.<\/p>\n
2. AppArmor: Perfis de Confinamento que Complementam o PAM sudo AppArmor<\/h3>\n
O AppArmor<\/strong> \u00e9 a implementa\u00e7\u00e3o de Mandatory Access Control (MAC) adotada por padr\u00e3o em distribui\u00e7\u00f5es como Ubuntu, SUSE e Debian. Ao contr\u00e1rio do SELinux, que opera com r\u00f3tulos e pol\u00edticas complexas, o AppArmor utiliza perfis baseados em caminhos<\/strong>, tornando\u2011o mais acess\u00edvel para equipes que precisam de um controle de acesso obrigat\u00f3rio sem uma curva de aprendizado proibitiva. A sinergia com PAM sudo AppArmor<\/strong> \u00e9 direta: enquanto o PAM e o sudo gerenciam quem pode fazer o qu\u00ea e com qual identidade, o AppArmor limita o que cada processo pode acessar, independentemente do usu\u00e1rio que o invocou.<\/p>\n
Um perfil AppArmor t\u00edpico come\u00e7a com aa\u2011genprof<\/strong> ou \u00e9 escrito manualmente em \/etc\/apparmor.d\/. Por exemplo, para confinar o servidor web Nginx, um perfil simplificado poderia conter:<\/p>\n
\n\/usr\/sbin\/nginx {\n  #include <abstractions\/base>\n  capability net_bind_service,\n  \/var\/log\/nginx\/*.log w,\n  \/var\/www\/** r,\n  \/run\/nginx.pid rw,\n}\n<\/pre>\n
Esse perfil permite que o Nginx fa\u00e7a bind em portas privilegiadas (capability net_bind_service), leia arquivos do diret\u00f3rio web e escreva logs \u2014 qualquer acesso fora desses limites \u00e9 bloqueado pelo kernel. Na JRT Technology Solutions<\/strong>, desenvolvemos perfis personalizados para aplica\u00e7\u00f5es legadas que n\u00e3o podem ser modificadas no c\u00f3digo, usando o AppArmor como uma camada extra de prote\u00e7\u00e3o. Em um cen\u00e1rio real, um invasor que explorasse uma vulnerabilidade no Nginx teria seus movimentos drasticamente limitados, mesmo que o processo estivesse rodando como root.<\/p>\n
A rela\u00e7\u00e3o com o PAM sudo AppArmor<\/strong> fica clara quando consideramos usu\u00e1rios que executam comandos via sudo. Sem AppArmor, um administrador que roda sudo vim \/etc\/shadow<\/code> pode, teoricamente, usar o comando :!bash<\/code> dentro do Vim para escapar e obter um shell com privil\u00e9gios totais. Com um perfil AppArmor bem escrito, o Vim em modo privilegiado pode ser confinado a editar apenas arquivos espec\u00edficos, sem acesso de execu\u00e7\u00e3o a shells ou outros bin\u00e1rios. Isso mitiga uma classe inteira de escalamentos de privil\u00e9gio<\/strong> que dependem de “escaping” de editores, pagers e outras ferramentas interativas.<\/p>\n
O ciclo de vida de um perfil AppArmor inclui os modos complain<\/strong> e enforce<\/strong>. No modo complain, viola\u00e7\u00f5es s\u00e3o registradas mas permitidas, funcionando como um “modo de aprendizado”. A ferramenta aa\u2011logprof<\/strong> analisa esses logs e sugere ajustes, tornando o processo iterativo. Nossos especialistas da JRT Technology Solutions<\/strong> recomendam manter perfis em complain por pelo menos uma semana em produ\u00e7\u00e3o antes de ativar o enforce, para evitar quebras de funcionalidade. Essa abordagem evitou downtime em um e\u2011commerce de grande porte durante uma migra\u00e7\u00e3o de servidores.<\/p>\n
3. SELinux vs AppArmor: Comparativo T\u00e9cnico e Crit\u00e9rios de Escolha<\/h3>\n
A escolha entre SELinux<\/strong> e AppArmor<\/strong> \u00e9 um dos debates mais frequentes quando se projeta uma estrat\u00e9gia de PAM sudo AppArmor<\/strong> \u2014 ou, no caso do SELinux, de PAM sudo SELinux<\/strong>. Ambas as tecnologias implementam MAC<\/strong> (Mandatory Access Control), mas divergem significativamente em filosofia, complexidade e ecossistema. O guia recente “SELinux vs AppArmor: 6 Fixes for the Best Linux Protection”<\/em>, publicado no linuxteck.com, documenta seis falhas reais resolvidas em distribui\u00e7\u00f5es como Ubuntu, RHEL, Rocky e Fedora, fornecendo um roteiro valioso para quem enfrenta problemas na pr\u00e1tica.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Caracter\u00edstica<\/th>\nSELinux<\/th>\nAppArmor<\/th>\n<\/tr>\n<\/thead>\n
Modelo de seguran\u00e7a<\/td>\nR\u00f3tulos (type enforcement) + MLS\/MCS<\/td>\nPerfis baseados em caminhos<\/td>\n<\/tr>\n
Distribui\u00e7\u00f5es principais<\/td>\nRHEL, Rocky, Fedora, CentOS, SUSE (opcional)<\/td>\nUbuntu, SUSE (padr\u00e3o), Debian<\/td>\n<\/tr>\n
Curva de aprendizado<\/td>\nAlta \u2014 conceitos de tipos, dom\u00ednios, transi\u00e7\u00f5es<\/td>\nModerada \u2014 mais intuitivo, foco em caminhos<\/td>\n<\/tr>\n
Ferramentas de troubleshooting<\/td>\nsetroubleshoot, audit2allow, sealert<\/td>\naa\u2011logprof, aa\u2011status, aa\u2011notify<\/td>\n<\/tr>\n
Granularidade<\/td>\nExtremamente fina \u2014 r\u00f3tulos em cada arquivo\/processo\/socket<\/td>\nM\u00e9dia \u2014 baseada em caminhos, menos detalhada<\/td>\n<\/tr>\n
Integra\u00e7\u00e3o com containers<\/td>\nSuportado via sVirt (libvirt), mas complexo<\/td>\nIntegra\u00e7\u00e3o nativa com LXD, Snap; mais leve<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
O SELinux \u00e9 not\u00f3rio por sua precis\u00e3o: cada arquivo, processo e socket recebe um r\u00f3tulo de seguran\u00e7a<\/strong>, e as pol\u00edticas definem quais intera\u00e7\u00f5es entre r\u00f3tulos s\u00e3o permitidas. Essa abordagem \u00e9 poderosa, mas a complexidade de escrita de pol\u00edticas muitas vezes leva administradores a simplesmente desativ\u00e1\u2011lo (modo permissive<\/strong> ou disabled<\/strong>), o que anula todo o benef\u00edcio. A documenta\u00e7\u00e3o do SUSE Linux Enterprise Server 15 SP7<\/strong> e da vers\u00e3o 16<\/strong> dedica cap\u00edtulos inteiros a como configurar e ajustar pol\u00edticas SELinux, sinalizando que mesmo as distribui\u00e7\u00f5es que historicamente favoreciam o AppArmor est\u00e3o oferecendo suporte robusto ao SELinux.<\/p>\n
Na pr\u00e1tica, a escolha entre SELinux e AppArmor depende de tr\u00eas fatores: distribui\u00e7\u00e3o alvo<\/strong>, maturidade da equipe<\/strong> e requisitos de conformidade<\/strong>. Ambientes que rodam RHEL ou derivados naturalmente herdam pol\u00edticas SELinux testadas e mantidas pela Red Hat. J\u00e1 ambientes Ubuntu ou SUSE tendem a se beneficiar da simplicidade do AppArmor. Na JRT Technology Solutions<\/strong>, j\u00e1 migramos clientes do SELinux para AppArmor \u2014 e vice\u2011versa \u2014 com base em an\u00e1lises de custo\u2011benef\u00edcio operacional, sempre mantendo a tr\u00edade PAM sudo AppArmor<\/strong> (ou SELinux) como espinha dorsal do controle de acesso.<\/p>\n
4. Integra\u00e7\u00e3o na Pr\u00e1tica: PAM, sudo e AppArmor em A\u00e7\u00e3o<\/h3>\n
Chegou a hora de demonstrar como PAM sudo AppArmor<\/strong> trabalham juntos em um cen\u00e1rio real de hardening. Considere um servidor de aplica\u00e7\u00e3o que roda um microsservi\u00e7o Python como usu\u00e1rio dedicado appuser<\/em>. A equipe de seguran\u00e7a deseja que apenas dois administradores seniores possam reiniciar o servi\u00e7o via sudo, que a autentica\u00e7\u00e3o exija segundo fator, e que o pr\u00f3prio processo Python seja confinado pelo AppArmor para acessar apenas seu diret\u00f3rio de trabalho e a porta 8080.<\/p>\n
O primeiro passo \u00e9 configurar o sudoers (via visudo<\/strong>) com uma regra restritiva:<\/p>\n
\nUser_Alias  SENIORS = ana, carlos\nCmnd_Alias  RESTART_SVC = \/usr\/bin\/systemctl restart myapp, \/usr\/bin\/systemctl status myapp\nSENIORS     ALL = (root) RESTART_SVC\nDefaults    logfile=\"\/var\/log\/sudo.log\"\nDefaults    log_input, log_output\n<\/pre>\n
Em seguida, o PAM<\/strong> \u00e9 refor\u00e7ado para exigir um token TOTP via Google Authenticator, adicionando ao \/etc\/pam.d\/sudo a linha auth required pam_google_authenticator.so<\/code>. O segredo compartilhado \u00e9 armazenado em ~\/.google_authenticator de cada usu\u00e1rio. Finalmente, um perfil AppArmor para o processo da aplica\u00e7\u00e3o (\/opt\/myapp\/app.py<\/code>) \u00e9 criado com aa\u2011genprof<\/strong>, refinado e colocado em modo enforce. Testes mostram que mesmo que um invasor obtenha a senha de um administrador, sem o token TOTP ele n\u00e3o executa o comando sudo. E se explorar o microsservi\u00e7o Python, o AppArmor impede a leitura de \/etc\/shadow, por exemplo.<\/p>\n
Esse cen\u00e1rio, implantado pela JRT Technology Solutions<\/strong> em uma fintech, resistiu a um pentest agressivo focado em escalamento de privil\u00e9gios. O relat\u00f3rio do testador destacou que a combina\u00e7\u00e3o de fatores \u2014 autentica\u00e7\u00e3o forte, comandos limitados e confinamento de processos \u2014 criou uma “defesa em profundidade” que exigiu um n\u00edvel de esfor\u00e7o incompat\u00edvel com a janela de ataque dispon\u00edvel. Esse \u00e9 o poder de um PAM sudo AppArmor<\/strong> bem orquestrado.<\/p>\n
\u00c9 importante ressaltar que o AppArmor pode ser usado para confinar n\u00e3o apenas aplica\u00e7\u00f5es, mas tamb\u00e9m os pr\u00f3prios comandos executados via sudo. Um perfil que restrinja o systemctl<\/code> a gerenciar apenas unidades espec\u00edficas elimina o risco de um administrador executar sudo systemctl stop firewall<\/code> acidental ou maliciosamente. A sintaxe \u00e9 simples e pode ser inclu\u00edda em um perfil j\u00e1 existente ou como um perfil separado com regras de transi\u00e7\u00e3o.<\/p>\n
5. Hardening com SELinux no SUSE Linux Enterprise Server<\/h3>\n
Embora o foco deste artigo seja PAM sudo AppArmor<\/strong>, \u00e9 imposs\u00edvel ignorar o movimento do ecossistema em dire\u00e7\u00e3o ao SELinux, especialmente ap\u00f3s os recentes guias oficiais do SUSE. O SLES 15 SP7<\/strong> e o SLES 16<\/strong> trazem m\u00f3dulos de SELinux completamente documentados, com instru\u00e7\u00f5es para ativa\u00e7\u00e3o, configura\u00e7\u00e3o de pol\u00edticas e troubleshooting usando setroubleshoot<\/strong> e audit2allow<\/strong>. Para profissionais que atuam em ambientes heterog\u00eaneos, entender ambos os sistemas \u00e9 um diferencial competitivo que na JRT Technology Solutions<\/strong> cultivamos continuamente.<\/p>\n
A ativa\u00e7\u00e3o do SELinux no SLES segue um procedimento padronizado: instala\u00e7\u00e3o do pacote selinux-policy-targeted<\/strong>, configura\u00e7\u00e3o do arquivo \/etc\/selinux\/config com SELINUX=enforcing<\/code> e reinicializa\u00e7\u00e3o para aplicar os r\u00f3tulos. Diferentemente do AppArmor, que j\u00e1 vem ativo por padr\u00e3o no SUSE, o SELinux exige uma etapa extra de relabeling durante o boot, que pode levar v\u00e1rios minutos em sistemas com milh\u00f5es de arquivos. O guia do SLES recomenda fortemente o uso do modo permissive<\/strong> inicial para capturar alertas sem bloquear funcionalidades.<\/p>\n
As li\u00e7\u00f5es do artigo “Troubleshooting SELinux | SUSE Linux Enterprise Micro”<\/em> s\u00e3o particularmente \u00fateis: o pacote setroubleshoot-server<\/strong> traduz mensagens cr\u00edpticas do kernel em alertas leg\u00edveis, sugerindo corre\u00e7\u00f5es exatas. Por exemplo, um bloqueio de acesso a \/var\/log\/app pode gerar o alerta “SELinux is preventing \/usr\/bin\/myapp from write access on the directory \/var\/log\/app”<\/em> e a sugest\u00e3o de executar:<\/p>\n
\nsudo ausearch -c 'myapp' --raw | audit2allow -M myapp-policy\nsudo semodule -i myapp-policy.pp\n<\/pre>\n
Esse fluxo automatiza a cria\u00e7\u00e3o de m\u00f3dulos de pol\u00edtica, permitindo que equipes resolvam quest\u00f5es de compatibilidade sem precisar escrever regras SELinux manualmente. Contudo, h\u00e1 um risco: o audit2allow<\/strong> pode gerar pol\u00edticas excessivamente permissivas se o administrador n\u00e3o revisar cuidadosamente o arquivo .te gerado. A JRT Technology Solutions<\/strong> sempre inclui uma etapa de revis\u00e3o humana nesse processo, verificando se a pol\u00edtica proposta n\u00e3o abre brechas desnecess\u00e1rias.<\/p>\n
A documenta\u00e7\u00e3o do SLES tamb\u00e9m cobre a integra\u00e7\u00e3o com o PAM<\/strong> via m\u00f3dulo pam_selinux.so<\/strong>, que garante que a sess\u00e3o do usu\u00e1rio herde o contexto de seguran\u00e7a correto. Isso fecha o ciclo: PAM autentica e aloca contexto, sudo eleva privil\u00e9gios respeitando pol\u00edticas de RBAC, e SELinux imp\u00f5e restri\u00e7\u00f5es no n\u00edvel do kernel. Embora a sintaxe e as ferramentas difiram do AppArmor, o princ\u00edpio arquitetural \u00e9 o mesmo que defendemos no modelo PAM sudo AppArmor<\/strong>.<\/p>\n
6. Troubleshooting de Controle de Acesso: Ferramentas e Metodologia<\/h3>\n
Problemas de permiss\u00e3o em ambientes com PAM sudo AppArmor<\/strong> ativos costumam ser diagnosticados em cascata. A metodologia que adotamos na JRT Technology Solutions<\/strong> segue uma ordem l\u00f3gica: primeiro verificar logs do PAM, depois logs do sudo, e s\u00f3 ent\u00e3o mergulhar nos logs do AppArmor ou SELinux. Essa sequ\u00eancia evita que horas sejam perdidas ajustando perfis de MAC quando o problema real \u00e9 uma simples expira\u00e7\u00e3o de senha ou bloqueio de conta.<\/p>\n
Para o PAM, os logs principais est\u00e3o em \/var\/log\/auth.log<\/strong> (Debian\/Ubuntu) ou \/var\/log\/secure<\/strong> (RHEL\/SUSE). O comando journalctl -u sudo<\/code> tamb\u00e9m \u00e9 valioso em sistemas com systemd. Mensagens como “pam_unix(sudo:auth): authentication failure”<\/em> indicam erro de senha, enquanto “pam_faillock(sudo:auth): Consecutive login failures for user”<\/em> acionam alarmes de for\u00e7a bruta. J\u00e1 o log do sudo, quando configurado com log_output<\/em>, permite reproduzir sess\u00f5es inteiras, sendo essencial para investiga\u00e7\u00f5es forenses.<\/p>\n
No AppArmor, os alertas aparecem em \/var\/log\/syslog<\/strong> ou via dmesg<\/code>, com o prefixo audit:<\/strong>. A ferramenta aa\u2011status<\/strong> mostra quais perfis est\u00e3o carregados e em qual modo. Se um processo est\u00e1 sendo bloqueado, a primeira a\u00e7\u00e3o \u00e9 coloc\u00e1\u2011lo temporariamente em modo complain<\/strong> com aa\u2011complain \/caminho\/do\/perfil<\/code>, coletar logs e ent\u00e3o usar aa\u2011logprof<\/strong> para atualizar o perfil. O ciclo completo leva minutos e resolve 90% dos problemas de “permiss\u00e3o negada” sem necessidade de desativar o AppArmor.<\/p>\n
No ecossistema SELinux, o troubleshooting \u00e9 mais intrincado. O pacote setroubleshoot<\/strong> \u00e9 indispens\u00e1vel, assim como o comando audit2why<\/strong>, que traduz eventos de auditoria em explica\u00e7\u00f5es leg\u00edveis. A documenta\u00e7\u00e3o recente do SUSE Linux Enterprise Micro recomenda tamb\u00e9m o uso de sealert<\/strong> para an\u00e1lise de alertas. Abaixo, uma lista de verifica\u00e7\u00e3o que usamos durante sess\u00f5es de troubleshooting:<\/p>\n
    \n
  1. Confirmar o status do MAC<\/strong>: sestatus<\/code> (SELinux) ou apparmor_status<\/code> (AppArmor).<\/li>\n
  2. Verificar logs de auditoria<\/strong>: ausearch -m avc -ts recent<\/code> para SELinux; grep audit \/var\/log\/syslog<\/code> para AppArmor.<\/li>\n
  3. Testar em modo permissivo\/complain<\/strong> para isolar o bloqueio.<\/li>\n
  4. Gerar pol\u00edtica corretiva<\/strong>: audit2allow<\/code> (SELinux) ou aa\u2011logprof<\/code> (AppArmor).<\/li>\n
  5. Aplicar e reavaliar em modo enforce<\/strong>.<\/li>\n
  6. Documentar a exce\u00e7\u00e3o<\/strong> para futuras auditorias de conformidade.<\/li>\n<\/ol>\n
    Essa metodologia reduziu em 60% o tempo m\u00e9dio de resolu\u00e7\u00e3o de incidentes de acesso em clientes gerenciados pela JRT Technology Solutions<\/strong>. A chave est\u00e1 em nunca pular etapas e em sempre correlacionar os tr\u00eas subsistemas: PAM, sudo e MAC.<\/p>\n
    7. Automa\u00e7\u00e3o e Valida\u00e7\u00e3o de Pol\u00edticas: Scripts PASS\/FAIL<\/h3>\n
    Uma contribui\u00e7\u00e3o valiosa do artigo “SELinux vs AppArmor: 6 Fixes for the Best Linux Protection”<\/em> foi a introdu\u00e7\u00e3o de um script de valida\u00e7\u00e3o PASS\/FAIL<\/strong> que verifica a correta aplica\u00e7\u00e3o das pol\u00edticas de seguran\u00e7a. Adaptamos essa ideia na JRT Technology Solutions<\/strong> para um script que cobre n\u00e3o apenas SELinux, mas toda a stack PAM sudo AppArmor<\/strong>, executando uma s\u00e9rie de testes automatizados que retornam um status claro para cada camada.<\/p>\n
    O script, em ess\u00eancia, verifica:<\/p>\n