AppArmor - aprimoramento do kernel para restringir programas a um conjunto limitado de recursos.
DESCRIÇÃO
AppArmor é um aprimoramento do kernel para restringir programas a um conjunto limitado de recursos. O modelo de segurança exclusivo do AppArmor é vincular atributos de controle de acesso a programas, em vez de usuários.
O confinamento do AppArmor é fornecido por meio de perfis carregados no kernel por meio do apparmor_parser(8), normalmente por meio da unidade systemd apparmor.service, que é usada da seguinte forma:
# systemctl start apparmor
# systemctl reload apparmor
O AppArmor pode operar em dois modos: aplicação e notificação ou aprendizado:
aplicação - Perfis carregados no modo de aplicação resultarão na aplicação da política definida no perfil, bem como no relatório de tentativas de violação de política para o syslogd.
notificação - Perfis carregados no modo "notificação" não aplicarão a política. Em vez disso, relatará tentativas de violação de política. Este modo é conveniente para o desenvolvimento de perfis. Para gerenciar o modo de notificação para perfis individuais, os utilitários aa-complain(8) e aa-enforce(8) podem ser usados. Esses utilitários recebem o nome do programa como argumento.
Os perfis são tradicionalmente armazenados em arquivos em /etc/apparmor.d/ com nomes que seguem a convenção de substituir a / nos nomes de caminhos por . (exceto para a raiz /) para que os perfis sejam mais fáceis de gerenciar (por exemplo, o perfil /usr/sbin/nscd seria nomeado usr.sbin.nscd).
Os perfis são aplicados a um processo no momento de exec(3) (conforme visto na chamada de sistema execve(2)): uma vez que um perfil é carregado para um programa, esse programa será restrito na próxima execução(3). Se um processo já estiver em execução sob um perfil, quando um novo perfil for substituído no kernel, o perfil atualizado será aplicado imediatamente a esse processo. Por outro lado, um processo que já está em execução sem restrições não pode ser restrito.
O AppArmor oferece suporte ao sistema de arquivos securityfs do kernel Linux e disponibiliza a lista de perfis atualmente carregados; para montar o sistema de arquivos:
# mount -tsecurityfs securityfs /sys/kernel/security
$ cat /sys/kernel/security/apparmor/profiles
/usr/bin/mutt
/usr/bin/gpg
...
Normalmente, o script de inicialização montará o securityfs se ele ainda não tiver sido feito.
O AppArmor também restringe as operações privilegiadas que um processo confinado pode executar, mesmo que o processo esteja em execução como root. Um processo confinado não pode chamar as seguintes chamadas de sistema:
create_module(2) delete_module(2) init_module(2) ioperm(2)
iopl(2) ptrace(2) [reboot](filename:reboot.md)(2) setdomainname(2)
sethostname(2) swapoff(2) swapon(2) [sysctl](filename:sysctl.md)(2)
Modo de reclamação
Em vez de negar o acesso aos recursos para os quais o perfil não possui uma regra, o AppArmor pode "permitir" o acesso e registrar uma mensagem para a operação que o aciona. Isso é chamado de modo de reclamação. É importante observar que as regras que estão presentes no perfil ainda são aplicadas, portanto, as regras de permissão ainda silenciarão ou forçarão mensagens de auditoria, e as regras de negação ainda resultarão em negações e silenciamento das mensagens de negação (veja Desativar o silenciamento de auditoria de negação se isso for um problema).
O modo de reclamação pode ser usado para desenvolver perfis de forma incremental, à medida que um aplicativo é executado. Os acessos registrados podem ser adicionados ao perfil e, em seguida, o aplicativo pode ser executado ainda mais para descobrir adições adicionais que são necessárias. Como o AppArmor permite os acessos, o aplicativo se comportará como se o AppArmor não o estivesse restringindo.
Aviso: o modo de reclamação não oferece nenhuma segurança, apenas auditoria, enquanto estiver habilitado. Não deve ser usado em um ambiente hostil ou comportamentos ruins podem ser registrados e adicionados ao perfil como se fossem acessos a recursos que devem ser usados pelo aplicativo.
Observação: o modo de reclamação pode ser muito barulhento com perfis novos ou vazios, mas com perfis desenvolvidos, pode não registrar nada se o perfil cobrir bem o comportamento do aplicativo. Veja Limitação da taxa de auditoria se o modo de reclamação estiver gerando muitas mensagens de log.
Para definir um perfil e quaisquer perfis filhos ou perfis de "chapéu" que o perfil possa conter no modo de reclamação, use
aa-complain /etc/apparmor.d/<o-aplicativo>
Para definir manualmente um perfil específico no modo de reclamação, adicione a flag "complain" e, em seguida, recarregue manualmente o perfil:
profile foo flags=(complain) { ... }
Observe que a flag "complain" também deve ser adicionada manualmente a quaisquer "chapéus" ou perfis filhos do perfil ou eles continuarão a usar o modo anterior.
Para habilitar o modo de reclamação globalmente, execute:
echo -n complain > /sys/module/apparmor/parameters/mode
ou para defini-lo na inicialização, adicione:
apparmor.mode=complain
como um parâmetro de inicialização do kernel.
Aviso: definir o modo de reclamação globalmente desabilita todas as proteções de segurança do AppArmor. Pode ser útil durante a depuração ou desenvolvimento de perfil, mas defini-lo seletivamente em uma base por perfil é mais seguro.
ERROS
Quando um processo restrito tenta acessar um arquivo ao qual não tem permissão para acessar, o kernel relatará uma mensagem por meio da auditoria, semelhante a:
audit(1386511672.612:238): apparmor="DENIED" operation="exec"
parent=7589 profile="/tmp/sh" name="/bin/uname" pid=7605
comm="sh" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
audit(1386511672.613:239): apparmor="DENIED" operation="open"
parent=7589 profile="/tmp/sh" name="/bin/uname" pid=7605
comm="sh" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
audit(1386511772.804:246): apparmor="DENIED" operation="capable"
parent=7246 profile="/tmp/sh" pid=7589 comm="sh" pid=7589
comm="sh" capability=2 capname="dac_override"
As permissões solicitadas pelo processo são descritas na operação= e denied_mask= (para arquivos - capacidades, etc., use um formato de registro ligeiramente diferente). O "nome" e o ID do processo do programa em execução são relatados, bem como o nome do perfil, incluindo qualquer "chapéu" que possa estar ativo, separados por "//". ("Nome" está entre aspas, porque o nome do processo é limitado a 15 bytes; é o mesmo que é relatado por meio da contabilidade de processos Berkeley.)
Para processos confinados executados sob um perfil que foi carregado no modo de reclamação, o enforcement não será aplicado e as mensagens de log relatadas ao audit terão o seguinte formato:
audit(1386512577.017:275): apparmor="PERMITIDO" operation="open"
parent=8012 profile="/usr/bin/du" name="/etc/apparmor.d/tunables/"
pid=8049 comm="du" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
audit(1386512577.017:276): apparmor="PERMITIDO" operation="open"
parent=8012 profile="/usr/bin/du" name="/etc/apparmor.d/tunables/"
pid=8049 comm="du" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Se o auditd do espaço do usuário não estiver em execução, o kernel enviará eventos de auditoria para o klogd; o klogd enviará as mensagens para o syslog, que registrará as mensagens com a instalação KERN. Assim, as mensagens REJEITADAS e PERMITIDAS podem ir para /var/log/audit/audit.log ou /var/log/messages, dependendo da configuração local.
DEPURAÇÃO
O AppArmor fornece algumas ferramentas para registrar mais informações, o que pode ajudar na depuração de perfis.
Habilitar o modo de depuração
Quando o modo de depuração é habilitado, o AppArmor registrará algumas mensagens extras no dmesg (não por meio do subsistema de auditoria). Por exemplo, os logs indicarão se o "scrubbing" do ambiente foi aplicado.
Para habilitar o modo de depuração, execute:
echo 1 > /sys/module/apparmor/parameters/debug
ou, para definir na inicialização, adicione:
apparmor.debug=1
como um parâmetro de inicialização do kernel.
Desativar o silenciamento da auditoria de negação
Por padrão, as operações que acionam regras de "negação" não são registradas. Isso é chamado de silenciamento da auditoria de negação.
Para desativar o silenciamento da auditoria de negação, execute:
echo -n noquiet >/sys/module/apparmor/parameters/audit
ou, para definir na inicialização, adicione:
apparmor.audit=noquiet
como um parâmetro de inicialização do kernel.
Forçar o modo de auditoria
O AppArmor pode registrar uma mensagem para cada operação que aciona uma regra configurada na política. Isso é chamado de modo de auditoria forçada.
Atenção! O modo de auditoria forçada pode ser extremamente barulhento, mesmo para um único perfil, muito menos quando habilitado globalmente.
Para definir um perfil específico no modo de auditoria forçada, adicione a flag "audit":
profile foo flags=(audit) { ... }
Para habilitar o modo de auditoria forçada globalmente, execute:
echo -n all > /sys/module/apparmor/parameters/audit
ou, para definir na inicialização, adicione:
apparmor.audit=all
como um parâmetro de inicialização do kernel.
Limitação da taxa de auditoria
Se o auditd não estiver em execução, para evitar perder muitas das mensagens de log extras, você provavelmente terá que desativar a limitação de taxa executando:
echo 0 > /proc/sys/kernel/printk_ratelimit
Mas mesmo assim, o buffer de anel do kernel pode transbordar e você poderá perder mensagens.
Caso contrário, se o auditd estiver em execução, consulte auditd(8) e auditd.conf(5).
ARQUIVOS
/etc/apparmor.d/
/var/cache/apparmor/
/var/log/audit/audit.log
/var/log/messages
VER TAMBÉM
apparmor_parser(8), aa_change_hat(2), apparmor.d(5), aa-autodep(1), clean(1), auditd(8),
aa-unconfined(8), aa-enforce(1), aa-complain(1) e [https://wiki.apparmor.net].