Controle de Acesso: AppArmor

Este post é destinado a pessoas técnicas que tenham interesse em conhecer um pouco mais sobre a ferramenta AppArmor, que oferece uma camada complementar de segurança em controle de acesso. Entretanto, antes de abordar o tema principal, algumas fundamentações precisam tomar forma para o melhor proveito do leitor.

Alguns Fundamentos de Controle de Acesso

Quando o assunto é controle de acesso, papers, bibliografias e outras fontes científicas abordam o tema utilizando jargões como “Sujeito”, “Objetos”.
Sem nos aprofundarmos muito neste assunto, o senhor Buttler Lampson em 1974 [1] propôs um sistema elementar de proteção de acesso, e este se baseia em uma matriz de acesso:

“Uma matriz de acesso consiste em um conjunto de sujeitos, um conjunto de objetos e um conjunto de operações, colocadas de tal forma que determina quais operações determinado sujeito pode realizar em um objeto.”

Onde, um sujeito pode ser interpretado como um programa, um objeto como um arquivo no sistema de arquivos, existe ainda outros termos, porém nos focaremos apenas nestes dois.
A matriz de acesso abaixo demonstra o conceito e mapeia as operações permitidas para os sujeitos Alice, Bob e Charles, que podem ser de leitura, escrita, execução, propriedade ou nenhuma:

Arquivo 1

Arquivo 2

Arquivo 3

Alice

R

R

RWXO

Bob

RWO

RW

Charles

R

RWO

Onde:

R – Permissão de Leitura
W – Permissão de Escrita
X – Permissão de execução
O – Propriedade sobre o objeto

Então pode-se dizer que o sujeito Alice, tem capacidades de leitura no arquivo 1 e arquivo 2, enquanto tem propriedade, leitura, escrita e execução do arquivo 3.
O sujeito Bob, possui capacidades de leitura, escrita e propriedade sob o objeto arquivo 1, leitura e escrita sob arquivo 2 e não possui nenhuma capacidade sobre o arquivo 3.

DAC – Discretionary Access Control

O sistema de controle de acesso DAC funciona aplicando o conceito de matriz de acesso, descrito anteriormente. Detalhes técnicos mais aprofundados não serão abordados, apenas citaremos que a representação visual deste sistema pode ser vista ao utilizar o comando “ls -l” em um sistema linux, onde as permissões de acesso aos arquivos e diretórios podem ser vistas na primeira coluna do output do comando.

DAC e MAC em Conjunto

De fato, o sistema MAC pode se tornar complementar ao sistema DAC e é visto regularmente em algumas distribuições Linux, como o Ubuntu, por exemplo.
Abaixo, um fluxo processual muito simplista, que visa contextualizar as verificações para a concessão de acesso a um requisitante (sujeito).

dac-mac

Como é possível constatar, caso uma das condições não seja satisfeita, o acesso é negado.

Mais sobre o AppArmor

O AppArmor tem o objetivo de oferecer de forma simples as vantagens do Mandatory Access Control ao usuário com conhecimento básico e também uma alternativa ao RBAC.

Nasceu em meados do ano de 1998 como um projeto de complemento de segurança aos sistemas Linux desenvolvido pela Immunix, que posteriormente foi adquirida pela Novell que mantém o SuSe Linux. O AppArmor foi incorporado ao kernel a partir da versão 2.6.36. Atualmente a Canonical, empresa mantenedora do Ubuntu contribui para o projeto.

O objetivo traçado pelo AppArmor é de estabelecer um conjunto de capacidades possíveis para um determinado serviço, evitando o comportamento não esperado, ou seja, uma possível violação de acesso oriunda de uma exploração maliciosa. E este conjunto de capacidades precisa obrigatoriamente estar explícito nas configurações. Algumas diretivas já são fornecidas pelo pacote completo do AppArmor, para serviços adicionais, regras manuais devem ser criadas.

Proposta de Estudo de Caso

Como é possível imaginar, caso uma das condições não seja satisfeita, o acesso é negado.

Um conjunto simples de regras de um serviço, por exemplo, determina que ele possui capacidade de leitura de 3 arquivos em disco, de comunicação com outros 2 serviços (um sujeito pode se tornar um objeto), entretanto não consta uma regra explícita que ele pode escrever um arquivo temporário dentro do diretório “/tmp”, então, ele não conseguirá escrever este arquivo, mesmo tendo permissões DAC (rwx) para tal.

Este estudo de caso se propõe a testar este fator característico do AppArmor.

Testes

 Em nosso estudo de caso temos o seguinte cenário:

SO: Ubuntu
Serviço: Daemon NSCD
Usuário owner: Root
Arquivo de regras: usr.sbin.nscd
Regra a ser modificada: Leitura ao arquivo de configuração (/etc/nscd.conf)

Seguindo esta linha de raciocínio, comentamos a linha que garante o acesso de leitura ao arquivo de configuração do NSCD, no arquivo de regras do AppArmor para ele criadas:

—-usr.sbin.nscd—
#/etc/nscd.conf r,
—/usr.sbin.nscd—-

Reiniciamos o apparmor, aplicamos a regra modificada e rodamos o NSCD:

root@labvm:/etc/apparmor.d# /etc/init.d/apparmor reload && aa-enforce /usr/sbin/nscd 
* Reloading AppArmor profiles
Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox                           	[ OK ] 
Setting /usr/sbin/nscd to enforce mode.							[ OK ] 
root@labvm:/etc/apparmor.d# /etc/init.d/nscd start
* Starting Name Service Cache Daemon nscd /usr/sbin/nscd: failure while reading configuration file; this is fatal
* (failed to start).
root@labvm:/etc/apparmor.d#

Utilizando a ferramenta strace, podemos depurar quais foram as chamadas de sistema executadas e quais arquivos o NSCD tenta abrir:

root@labvm:/etc/apparmor.d# strace nscd
execve("/usr/sbin/nscd", ["nscd"], [/* 19 vars */]) = 0
 brk(0)                                  = 0x8346000
...linhas suprimidas...
 fstat64(3, {st_mode=S_IFREG|0644, st_size=30684, ...}) = 0
mmap2(NULL, 33364, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x283000
mmap2(0x28a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0x28a000
...linhas suprimidas...
close(3)                                = 0
open("/etc/nscd.conf", O_RDONLY)        = -1 EACCES (Permission denied)
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
...linhas suprimidas...
root@labvm:/etc/apparmor.d#

Faremos um novo teste, para simular um ataque onde um agressor utiliza uma vulnerabilidade no serviço para executar comandos arbitrários no sistema, realizamos a troca do binário do serviço por um outro específico. Este binário tentará criar e escrever em um arquivo localizado no diretório “/tmp”, o AppArmor deverá bloquear esta tentativa pois não existe a capacidade explícita de acesso ao “/tmp” nas regras.Como podemos ver na linha destacada, o acesso ao arquivo de configuração foi negado pelo AppArmor.

Após restaurar o arquivo de regras do NSCD original e recarregar o AppArmor, rodamos o binário utilizando a ferramenta strace e verificamos a saída:

[pid  2548] dup2(3, 2)                  = 2
[pid  2548] open("/tmp/teste-apparmor", O_RDWR|O_CREAT, 057147764) = -1 EACCES (Permission denied)
[pid  2548] write(-1, "OK\n", 3)        = -1 EBADF (Bad file descriptor)
[pid  2548] close(-1)                   = -1 EBADF (Bad file descriptor)

O Binário utilizado neste teste tem o seguinte código-fonte:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

void BGround(); 
int main() { 
 int fd;                
	BGround();                
	fd = open(“/tmp/teste-apparmor”, O_RDWR|O_CREAT);
	if(!fd) exit(-1);
	write(fd,”OK\n”,3);
	close(fd);
	sleep(100)
	return 0;
}

void BGround() {
 int f,bg;

	bg = open(“/dev/null”, O_WRONLY);
	if (bg < 0) {
		printf(“Unable to open \”/dev/null\”\n”);
		exit(-1);
	}
	f = fork( );
	if (!f) {
		printf(“[+] Background process pid: %d\n”, getpid( ));
		dup2(bg, 1);
		dup2(bg, 2);
	} else if (f > 1) {
		sleep(1);
		printf(“[*] Detached\n”);
		exit(0);
	} else {
		printf(“[x] Unable to fork\n”);
		exit(-1);
	}
}

Como podemos ver, o AppArmor faz seu papel tranquilamente, entretanto há discussões sobre sua eficácia uma vez que é possível desabilitá-lo sem necessitar reiniciar o sistema, portanto se um usuário mal intencionado obter acesso administrativo sem comprometer um binário monitorado por ele, acaba se tornando inútil. Por outro lado, customizar suas regras para abranger o maior número de serviços existentes, pode adicionar uma camada interessante de segurança para seu sistema.

 

Referência:

[1] Access Control Matrix – http://en.wikipedia.org/wiki/Access_Control_Matrix

Postado por: Douglas dos Santos

Consultor de segurança da informação.

Leave a Reply