AppArmor
Basic Information
AppArmor é uma melhoria do kernel projetada para restringir os recursos disponíveis para programas através de perfis por programa, implementando efetivamente o Controle de Acesso Mandatório (MAC) ao vincular atributos de controle de acesso diretamente a programas em vez de usuários. Este sistema opera carregando perfis no kernel, geralmente durante a inicialização, e esses perfis ditam quais recursos um programa pode acessar, como conexões de rede, acesso a soquetes brutos e permissões de arquivo.
Existem dois modos operacionais para os perfis do AppArmor:
Modo de Aplicação: Este modo aplica ativamente as políticas definidas dentro do perfil, bloqueando ações que violam essas políticas e registrando quaisquer tentativas de violá-las através de sistemas como syslog ou auditd.
Modo de Reclamação: Ao contrário do modo de aplicação, o modo de reclamação não bloqueia ações que vão contra as políticas do perfil. Em vez disso, registra essas tentativas como violações de política sem impor restrições.
Components of AppArmor
Módulo do Kernel: Responsável pela aplicação das políticas.
Políticas: Especificam as regras e restrições para o comportamento do programa e acesso a recursos.
Analisador: Carrega políticas no kernel para aplicação ou relatório.
Utilitários: Estes são programas em modo usuário que fornecem uma interface para interagir e gerenciar o AppArmor.
Profiles path
Os perfis do AppArmor geralmente são salvos em /etc/apparmor.d/
Com sudo aa-status
você poderá listar os binários que estão restritos por algum perfil. Se você puder trocar o caractere "/" por um ponto no caminho de cada binário listado, você obterá o nome do perfil do AppArmor dentro da pasta mencionada.
Por exemplo, um perfil do apparmor para /usr/bin/man estará localizado em /etc/apparmor.d/usr.bin.man
Commands
Criando um perfil
Para indicar o executável afetado, caminhos absolutos e curingas são permitidos (para globbing de arquivos) para especificar arquivos.
Para indicar o acesso que o binário terá sobre arquivos, os seguintes controles de acesso podem ser usados:
r (ler)
w (escrever)
m (mapa de memória como executável)
k (bloqueio de arquivo)
l (criação de links duros)
ix (executar outro programa com o novo programa herdando a política)
Px (executar sob outro perfil, após limpar o ambiente)
Cx (executar sob um perfil filho, após limpar o ambiente)
Ux (executar sem restrições, após limpar o ambiente)
Variáveis podem ser definidas nos perfis e podem ser manipuladas de fora do perfil. Por exemplo: @{PROC} e @{HOME} (adicione #include <tunables/global> ao arquivo de perfil)
Regras de negação são suportadas para substituir regras de permissão.
aa-genprof
Para começar a criar um perfil facilmente, o apparmor pode ajudar você. É possível fazer o apparmor inspecionar as ações realizadas por um binário e então deixar você decidir quais ações deseja permitir ou negar. Você só precisa executar:
Então, em um console diferente, execute todas as ações que o binário geralmente realizará:
Então, na primeira console pressione "s" e depois nas ações gravadas indique se você deseja ignorar, permitir ou qualquer outra coisa. Quando terminar, pressione "f" e o novo perfil será criado em /etc/apparmor.d/path.to.binary
Usando as teclas de seta, você pode selecionar o que deseja permitir/negar/qualquer outra coisa
aa-easyprof
Você também pode criar um template de um perfil apparmor de um binário com:
Observe que, por padrão, em um perfil criado, nada é permitido, então tudo é negado. Você precisará adicionar linhas como /etc/passwd r,
para permitir a leitura do binário /etc/passwd
, por exemplo.
Você pode então impor o novo perfil com
Modificando um perfil a partir de logs
A ferramenta a seguir irá ler os logs e perguntar ao usuário se ele deseja permitir algumas das ações proibidas detectadas:
Usando as teclas de seta, você pode selecionar o que deseja permitir/negar/o que for
Gerenciando um Perfil
Logs
Exemplo de logs AUDIT e DENIED de /var/log/audit/audit.log do executável service_bin
:
Você também pode obter essas informações usando:
Apparmor no Docker
Note como o perfil docker-profile do docker é carregado por padrão:
Por padrão, o perfil docker-default do Apparmor é gerado a partir de https://github.com/moby/moby/tree/master/profiles/apparmor
Resumo do perfil docker-default:
Acesso a toda a rede
Nenhuma capacidade é definida (No entanto, algumas capacidades virão da inclusão de regras básicas, ou seja, #include <abstractions/base>)
Escrita em qualquer arquivo /proc não é permitida
Outros subdiretórios/arquivos de /proc e /sys têm acesso de leitura/escrita/bloqueio/link/executar negado
Montagem não é permitida
Ptrace só pode ser executado em um processo que está confinado pelo mesmo perfil apparmor
Uma vez que você execute um contêiner docker, você deve ver a seguinte saída:
Note que o apparmor até bloqueará privilégios de capacidades concedidos ao contêiner por padrão. Por exemplo, ele será capaz de bloquear a permissão para escrever dentro de /proc mesmo que a capacidade SYS_ADMIN seja concedida porque, por padrão, o perfil do apparmor do docker nega esse acesso:
Você precisa desativar o apparmor para contornar suas restrições:
Note que por padrão AppArmor também proibirá o contêiner de montar pastas de dentro, mesmo com a capacidade SYS_ADMIN.
Note que você pode adicionar/remover capacidades ao contêiner docker (isso ainda será restrito por métodos de proteção como AppArmor e Seccomp):
--cap-add=SYS_ADMIN
dá a capacidadeSYS_ADMIN
--cap-add=ALL
dá todas as capacidades--cap-drop=ALL --cap-add=SYS_PTRACE
remove todas as capacidades e dá apenasSYS_PTRACE
Geralmente, quando você descobre que tem uma capacidade privilegiada disponível dentro de um contêiner docker, mas alguma parte do exploit não está funcionando, isso será porque o apparmor do docker estará impedindo.
Exemplo
(Exemplo de aqui)
Para ilustrar a funcionalidade do AppArmor, criei um novo perfil Docker “mydocker” com a seguinte linha adicionada:
Para ativar o perfil, precisamos fazer o seguinte:
Para listar os perfis, podemos executar o seguinte comando. O comando abaixo está listando meu novo perfil do AppArmor.
Como mostrado abaixo, recebemos um erro ao tentar mudar “/etc/” já que o perfil do AppArmor está impedindo o acesso de escrita a “/etc”.
AppArmor Docker Bypass1
Você pode descobrir qual perfil apparmor está executando um contêiner usando:
Então, você pode executar a seguinte linha para encontrar o perfil exato que está sendo usado:
No caso estranho de você poder modificar o perfil do apparmor do docker e recarregá-lo. Você poderia remover as restrições e "contorná-las".
Bypass do AppArmor Docker2
AppArmor é baseado em caminho, isso significa que mesmo que ele possa estar protegendo arquivos dentro de um diretório como /proc
, se você puder configurar como o contêiner será executado, você poderia montar o diretório proc do host dentro de /host/proc
e ele não estará mais protegido pelo AppArmor.
Bypass do Shebang do AppArmor
Em este bug você pode ver um exemplo de como mesmo que você esteja impedindo que o perl seja executado com certos recursos, se você apenas criar um script shell especificando na primeira linha #!/usr/bin/perl
e você executar o arquivo diretamente, você poderá executar o que quiser. Ex.:
Last updated