Proteja o servidor web e o banco de dados com mod_selinux e SEPostgreSQL Um muro para a Web

(1)

R E D E S Um muro para a Web

O módulo mod_selinux do Apache ajuda a tapar os buracos que vão além do controle do firewall.

por Thorsten Scherf

A

plicativos web são um vetor de ataque popular na inva- são de sistemas (figura 1).

Sistemas de firewall tradicionais não conseguem proteger contra ataques de injeção SQL e cross-site scripting, o que significa que um erro em um aplicativo web pode ter consequên- cias fatais. Por um lado, os aplicativos web são extremamente dinâmicos e complexos; por outro lado, o desen- volvedor de um aplicativo web não pode adivinhar o futuro para anteci- par e eliminar perigos em potencial antes que eles ocorram.

ModSecurity

O módulo ModSecurity do Apache [1], que usa regras para filtrar con- teúdo suspeito nos dados recebidos, tornou-se uma ferramenta popular para impedir a entrada de intrusos.

Pacotes de dados que não corres- pondem aos padrões permitidos são descartados.

Essa abordagem consegue barrar uma grande porcentagem de pacotes maliciosos antes que cheguem ao aplicativo web, mas o que acontece com aqueles que conseguem passar? Sistemas que dependem

de casamento de padrões detectam apenas os padrões conhecidos e, portanto, falham ao encontrar algo desconhecido. Além disso, uma vez que o intruso já tenha entrado, as possibilidades de estender o ataque são infinitas.

Com relação ao sistema operacio- nal, os administradores conseguem resolver esse problema com a intro- dução de um esquema MAC (Man- datory Access Control – Controle Obrigatório de Acesso), que permite o ajuste das permissões empregadas a recursos específicos. Nos últimos

(2)

anos, o SELinux estabeleceu-se como uma importante ferramenta para implantar MACs em ambientes de alta segurança, mas o problema é que o SE apenas restringe o acesso aos recursos do sistema. Os novos ataques concentram-se em servidores de aplicativos web e bancos de dados.

O SEPostgreSQL (Security Enhan- ced PostgreSQL) [2] e o mod_selinux [3] ampliam a proteção oferecida pelo SELinux a objetos de bancos de dados e aplicativos web.

Como funciona

O SEPostgreSQL é uma extensão do popular sistema de banco de dados PostgreSQL que suporta a atribui- ção de um contexto de segurança SELinux a objetos individuais. Em um banco de dados PostgreSQL clássico, o usuário se conecta usando um nome de usuário e uma senha.

Com isso, ele tem acesso a todos os objetos disponíveis para sua conta.

Com o SEPostgreSQL, o socket do cliente recebe um contexto de segu- rança que pode ser de um usuário buscando acesso ou o contexto do processo que o está acessando.

O administrador do SEPostgreSQL pode atribuir rótulos de segurança a tabelas individuais e a qualquer objeto que elas contenham e, por isso, as regras centralizadas do SELinux

definem qual usuário ou processo pode ou não acessar cada um dos objetos do banco de dados.

Como no caso típico do SELinux, dois controles de acesso devem ser negociados antes que o usuário ou o processo tenha acesso ao objeto solicitado. Primeiro, as credenciais são verificadas pelo sistema de auten- ticação do banco de dados; em um segundo passo, o sistema verifica se o rótulo de segurança do socket de acesso possui privilégios suficientes para o objeto requisitado.

Esses dois testes precisam ser efe- tuados com sucesso para que o banco

de dados sirva o objeto requisitado.

O administrador do banco de dados também só pode acessar um objeto específico caso o administrador de segurança tenha dado autorização explícita a esse acesso por meio de uma regra do SELinux.

Diferentemente de objetos de sistema tradicionais, tais como arquivos e diretórios, onde o contexto de se- gurança é armazenado em seus atri- butos, o SEPostgreSQL armazena o contexto de segurança de um objeto do banco de dados em um catálogo de sistema especial. Catálogos de sistema de bancos de dados relacio- Figura 1 A porcentagem de ataques de rede direcionados a servidores web aumenta a cada ano. (Fonte: Little Earth

Corporation)

Site

2006 2007 2008

Outros

33%

7%

53%

67%

93%

47%

Listagem 1: Arquivo /etc/httpd/conf.d/mod_selinux.conf

01 <Directory “/var/www/html”>

02 # HTTP Basic Authentication 03 AuthType Basic

04 AuthName “Secret Zone”

05 AuthUserFile /var/www/htpasswd 06 Require valid-user 07 </Directory>

Listagem 2: Arquivo /etc/httpd/conf.d/mod_selinux.conf

01 ### O mod_selinux.conf pode acessar um 02 ### arquivo local para mapear usuários 03 ### a contextos de segurança

0405 selinuxDomainMap /var/www/mod_selinux.map 06 selinuxDomainVal anon_webapp_t:s0

07 selinuxDomainEnv SELINUX_DOMAIN

(3)

nais geralmente incluem dados de esquema e outras metainformações.

O SEPostgreSQL introduz um outro catálogo intitulado sg_security e o usa para armazenar o mapeamen- to entre o contexto de segurança de um objeto e o OID (Object Identifier – Identificador do Objeto) corres- pondente. Quando um novo objeto é criado no banco de dados, ele recebe um OID numérico. O próprio banco de dados faz a resolução do OID para uma string convencional necessária ao contexto de segurança.

Módulo mod_selinux

O módulo mod_selinux do Apache permite que o administrador inicie diferentes instâncias do servidor web com um contextos de segurança individuais em vez de usar o mesmo contexto para vários processos. O

contexto de segurança designado a uma instância de um servidor web depende do usuário que a acessa.

O método é semelhante ao login tradicional pelo shell. Após uma au- tenticação bem-sucedida pelo login ou ssh, o usuário do shell recebe um contexto de segurança. Com isso, ele pode trabalhar no sistema dentro das restrições de segurança desse contexto. Caso o usuário ten- te fazer algo que não seja permitido pelo contexto, o SELinux impedirá que isso aconteça.

No caso do mod_selinux, é o Apa- che que age como agente ou proxy de um usuário. Se um usuário se conecta à sua conta, o processo do servidor web aplicará o contexto do usuário.

Para ver os direitos concedidos a um processo, é possível consultar o

servidor de segurança embutido no kernel para conferir os objetos que o usuário pode e não pode acessar.

Quando o SEPostgreSQL é usado como back-end de um aplicativo web, os controles de acesso se esten- dem a objetos individuais dentro do banco de dados.

Configuração do mod_selinux

Antes de começar a configuração, é necessário instalar o pacote do mod_selinux, já presente nos repo- sitórios da maioria das distribuições GNU/Linux; se sua distribuição não contém uma versão do módulo, é possível baixá-lo do repositório do Projeto Fedora [3]. Depois de terminar a instalação em um sistema Fedora 11, o arquivo mod_se- linux.conf estará no diretório /etc/

httpd/conf.d.

Contexto

Após a instalação do mod_selinux, a próxima pergunta é: “como os usuários receberão o contexto de segurança para um aplicativo web?”. O mod_selinux pode atribuir um contexto de várias maneiras, todas descritas no seu arquivo de configuração. Em primeiro lugar, é preciso informar ao Apache qual o diretório ou local onde a autenticação do usuário é necessária. A listagem 1 mostra um exemplo de autenticação que utiliza um arquivo local com os nomes de usuários e hashes MD5 de suas senhas.

Listagem 3: Arquivo /var/www/mod_selinux.map

01 foo *:s0:c0 02 bar *:s0:c1

03 _anonymous__ anon_webapp_t:s0 04 * user_webapp_t:s0

Listagem 4: Comando chcat

01 # chcat -L 02 s0

03 s0-s0:c0.c255 SystemLow-SystemHigh 04 s0:c0.c255 SystemHigh 05 s0:c1 Marketing 06 s0:c2 Payroll 07 s0:c3 IT

0809 chcat +IT /var/www/virtual/www1/index.html 10 ls -lZ /var/www/virtual/www1/index.html

11 -rw-rw-r-- root apache root:object_r:httpd_sys_content_t:IT /var /www/virtual/www1/index.html

Listagem 5: sesearch

01 # sesearch --allow -s user_webapp_t 02 Found 120 semantic av rules:

03 allow user_webapp_t public_content_t : file { ioctl read getattr lock open} ; 04 allow user_webapp_t public_content_t : dir { ioctl read getattr lock search open } ; 05 allow user_webapp_t public_content_t : lnk_file { read getattr } ;

06 allow user_webapp_t sysctl_kernel_t : file { ioctl read getattr lock open } ; 07 allow user_webapp_t sysctl_kernel_t : dir { ioctl read getattr lock search open } ; 08 ...

(4)

O comando a seguir adiciona um usuário ao arquivo de senhas:

# htpasswd -m /var/www/htpasswd foo A listagem 2 contém mais confi- gurações. A instrução selinuxDomain- Map especifica um arquivo local que atribui um contexto de segurança para cada usuário; como alternativa, pode-se usar selinuxDomainVal para estabelecer um contexto padrão.

Um arquivo de mapeamento seria semelhante à listagem 3.

Após a autenticação, os processos do servidor web para as duas requi- sições do usuário encontram-se no domínio do SELinux user_webapp_t , com a MLS (Multi-Level Security – Segurança Multi-Nível) do SELi- nux com sensibilidade de nível s0 e categorias c0 (foo) e c1 (bar) na MCS (Multi-Category Security – Seguran- ça Multi-Categoria). O arquivo dá acesso a objetos que pertencem a essas categorias e que podem acessar o domínio user_webapp_t. As categorias MCS dos objetos de arquivos são determinadas pela ferramenta chcat (listagem 4).

Se um usuário não estiver listado no arquivo de mapeamento, só po- derá ter acesso por meio do domínio user_webapp_t, a menos que a cate- goria MCS esteja definida. A ferramenta sesearch informa se o acesso a objetos no domínio user_webapp_t é permitido (listagem 5). Essas regras são adicionadas à política do SELi- nux através do pacote mod_selinux.

pp. Esse pacote é automaticamente carregado após a instalação do mod_

selinux, como confirma a chamada ao semodule:

# semodule -l |grep mod_selinux mod_selinux 2.2

Logicamente, é possível adicionar suas próprias regras à política, mas elas precisam estar reunidas em um pacote. Qualquer acesso não autenti-

cado ao servidor web é roteado para o domínio anon_webapp_t do SELi- nux, como especificado no arquivo de mapeamento.

Configurando o SEPostgreSQL

Na autenticação de usuários em domí- nios maiores, é preferível armazenar os usuários em um banco de dados, principalmente se o sistema de banco de dados for necessário para hospe-

dar seu aplicativo web. O exemplo a seguir usa o SEPostgreSQL como banco de dados.

A vantagem é que o administrador pode mapear todos os objetos desse banco de dados para um contexto de segurança, o que não seria pos- sível com outros sistemas de bancos relacionais.

Na maioria das distribuições GNU/Linux, é possível usar o re- positório de software padrão para a instalação; caso não seja possível,

Listagem 6: Tabela uaccount

01 # su sepgsql 02 # createdb web 03 # psql web 04 ...

0506 web=# CREATE TABLE uaccount ( 07 web(# uname TEXT PRIMARY KEY, 08 web(# upass TEXT,

09 web(# udomain TEXT 10 web(# );

1112 web=# INSERT INTO uaccount VALUES (‘foo’, ‘pass’, ‘user_

webapp_t:s0:c0’);

13 web=# INSERT INTO uaccount VALUES (‘bar’, ‘pass’, ‘user_

webapp_t:s0:c1’);

Listagem 7: Arquivo /etc/httpd/conf.d/mod_selinux.conf

01 LoadModule dbd_module modules/mod_dbd.so

02 LoadModule authn_dbd_module modules/mod_authn_dbd.so 03 04 # Parâmetros para conexão ao banco de dados

05 06 DBDriver pgsql

07 DBDParams “dbname=web user=apache”

08 09 # Autenticação por digest 10 11 <Directory “/var/www/html”>

12 AuthType Digest 13 AuthName “Secret Zone”

14 AuthDigestProvider dbd 15 AuthDBDUserRealmQuery \

16 “SELECT md5(uname || ‘:’ || $2 || ‘:’ || upass), udomain, \ 17 %s=%s as dummy FROM uaccount WHERE uname = $1”

18 19 # Mapeamento de contexto do SELinux 20 21 selinuxDomainEnv AUTHENTICATE_UDOMAIN 22 selinuxDomainVal anon_webapp_t:s0 23 24 </Directory>

(5)

o código-fonte está disponível no Google Code [4].

Após a instalação, é necessário inicializar o banco de dados com os comandos abaixo:

# /etc/init.d/sepostgresql initdb

# /etc/init.d/sepostgresql start O acesso administrativo ao banco é feito por meio de uma conta padrão (sepgsql) criada pelos comandos aci- ma. Ela permite que o administrador crie um banco de dados inicial para

armazenar os objetos do usuário (listagem 6).

Com isso, é possível usar o arquivo de configuração mod_selinux.conf para acessar esses objetos na autenticação de usuários pelo aplicativo web. O contexto de segurança correspon- dente a cada objeto usuário já existe no banco de dados, o que elimina a necessidade de mapeamento. Os comandos necessários para configurar o mod_selinux estão na listagem 7.

Em primeiro lugar, é preciso car- regar os módulos do Apache neces-

sários para acessar o banco de dados.

Depois, os próximos dois parâmetros especificam os nomes do driver e as credenciais exigidas para acessar o PostgreSQL. Esses parâmetros são seguidos da autenticação do usuário, onde a variável AUTHENTICATE_UDOMAIN é usada para passar os dados de au- tenticação para o mod_selinux. O usuário que não conseguir se conectar ainda pode usar o contexto de segurança anon_webapp_t como segunda opção.

SEPostgreSQL com MAC

Como exemplo, as seções a seguir descrevem a configuração do SELi- nux em um sistema gerenciador de banco de dados relacional usando SEPostgreSQL. A listagem 8 mostra o fluxo esquematizado. Em primeiro lugar, é necessário conectar-se ao SGBD com privilégios de administrador e criar um novo banco de dados – footballdb, neste caso. Depois, use o aplicativo cliente Psql para se conectar ao banco de dados e criar uma nova tabela – clubs neste exemplo. Em seguida, é adicionar uma única entrada à tabela.

A primeira declaração SELECT gera essa entrada. Como se pode ver, já há um contexto de segurança. O tipo deste contexto de segurança padrão é sepgsql_table_t para o acesso a par- tir do domínio unconfined_t. Apenas uma declaração de atualização é necessária para mudar o contexto.

O último comando SELECT verifica se a entrada possui agora um novo contexto de segurança.

O contexto pode ser aplicado individualmente a colunas, assim como a registros no banco de dados (listagem 9). A listagem 9 mostra uma tabela com dados de funcionários; a ideia é aplicar o contexto de segurança sepgsql_secret_table_t a essa coluna.

Os usuários comuns no domínio de usuários do SELinux não têm per-

Listagem 8: Contexto de Segurança para entradas de bancos de dados

01 # su sepgsql

02 # createdb footballdb 03 # psql footballdb

04 Welcome to psql 8.3.7, the PostgreSQL interactive terminal.

0506 Type: \copyright for distribution terms 07 \h for help with SQL commands 08 \? for help with psql commands

09 \g or terminate with semicolon to execute query 10 \q to quit

1112 footballdb=# CREATE TABLE clubs (

13 footballdb(# id integer primary key, 14 footballdb(# nome varchar(32),

15 footballdb(# ranking integer, 16 footballdb(# pontos integer 17 footballdb(# );

1819 footballdb=# INSERT INTO clubs (id, nome, ranking, pontos) 20 footballdb-# VALUES (1, ‘Manchester United’, 1, 72);

2122 footballdb=# SELECT security_context, * FROM clubs;

2324 security_context | id | nome | ranking | pontos 25 ––––––––––––----–+–---+––---–+––---+––---

26 unconfined_u:object_r:sepgsql_table_t:s0 | 1 | Manchester United | 1 |

7227 (1 row)

2829 footballdb=# UPDATE clubs SET security_context =

‘system_u:object_r:public_content_t:s0’ WHERE nome=’Manchester United’;

3031 footballdb=# SELECT security_context, * FROM clubs;

3233 security_context | id | nome | ranking | pontos 34 –––––––––––----––+–---+–---––+–---–-+––---

35 system_u:object_r:public_content_t:s0 | 1 | Manchester United | 1 | 72

36 (1 row)

(6)

missão para acessá-lo, como confir- mam as duas declarações SELECT. O comando SELECT sepgsql_getcon() retorna o contexto de segurança do socket de acesso; neste caso, o do- mínio de usuário user_t. O último SELECT tenta acessar todas as colunas da tabela de funcionários. Isso causa um erro no SELinux, pois o acesso ao tipo de objeto de banco de dados sepgsql_secret_table_t não é permiti- do ao domínio user_t. As regras para isso foram acrescentadas ao pacote de políticas sepostgresql-devel.pp, que contém a regra global do SELinux para instalar o SEPostgreSQL. Assim como no mod_selinux, é possível acrescentar suas próprias regras. A página de manual do sepostgresql lista todos os tipos do SELinux supor- tados e suas respectivas permissões.

Para decidir sobre o acesso a objetos no banco de dados, o SEPostgreS- QL sempre usa o contexto do socket utilizado pelo cliente para acessá-lo.

Esse contexto pode ser o de segurança do processo usado para o acesso (por exemplo, httpd_t) ou o contexto do shell do usuário (user_t, por exemplo).

O psql usa uma declaração SELECT se- pgsql_getcon() para exibir o contexto do socket que o está acessando. Se o acesso for originado em um servidor Apache ou em outra máquina, em vez da máquina local, o SEPostgreS- QL obviamente enxergará somente o contexto do socket de rede usado para acessá-lo. Porém, o uso de rótu- los na rede é uma solução elegante, pois suporta túneis IPSec arbitrários entre vários sistemas para estender o contexto de segurança de um processo além das fronteiras da rede.

Conclusões

Graças ao mod_selinux, agora é pos- sível iniciar processos individuais do servidor web (ou threads individuais, para ser mais exato) com um contexto de segurança individual. Com isso, o administrador pode usar as regras do SELinux para definir os objetos

que têm permissão de acesso a essas threads individuais. Examinando mais atentamente a documentação, nota- se que há muitas outras aplicações para isso. Por exemplo, é possível usar o mod_selinux para iniciar hosts virtuais individuais do Apache com seus próprios contextos de seguran- ça, ou definir um contexto com base no endereço IP da máquina que está acessando o servidor.

O mod_selinux oferece uma abordagem mais granular do que nunca

para acessar objetos do SELinux.

Apesar do AppArmor oferecer uma solução similar, ele requer um servidor Apache especial, o que não acontece com o mod_selinux. E, caso o SEPostgreSQL seja usado como banco de dados, o controle obrigatório de acesso pode ser es- tendido aos objetos do banco de dados. Uma combinação dos dois sistemas promete grandes benefí- cios de segurança no uso de aplicativos web. n

Gostou do artigo?

Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.br

Este artigo no nosso site:

http://lnm.com.br/article/3278

Mais informações

[1] Módulo ModSecurity: http://www.modsecurity.org/

[2] SEPostgreSQL: http://wiki.postgresql.org/wiki/SEPostgreSQL [3] Pacote do mod_selinux para Fedora:

https://admin.fedoraproject.org/pkgdb/packages/name/mod_selinux [4] Download do SEPostgreSQL: http://code.google.com/p/sepgsql/

Listagem 9: Contexto de segurança para colunas

01 foo=# CREATE TABLE employee ( 02 foo(# mid integer primary key, 03 foo(# mname varchar(32),

04 foo(# esalary varchar(32) CONTEXT = ‘system_u:object_r:sepgsql _secret_table_t:s0’

05 foo(# );

0607 foo=# GRANT ALL ON employee TO PUBLIC;

0809 foo=# SELECT sepgsql_getcon();

10 sepgsql_getcon 11 ––––––––-

12 user_u:user_r:user_t:s0 13 (1 row)

1415 foo=# SELECT * FROM employee;

16 ERROR: SELinux: denied { select } \ 17 scontext=user_u:user_r:user_t:s0 \

18 tcontext=system_u:object_r:sepgsql_secret_table_t:s0 \ 19 tclass=db_column name=employee.esalary