Arquivo da categoria: SELINUX

Apresentando o audit2allow para configurar politicas no SELINUX

O SELINUX é ignorado por muitos, o padrão de muito usuário e até administradores é desabilita-lo logo após instalarem o linux. Eu já fiz muito isso. Mas agora entendo que é uma ferramenta essencial para segurança do sistema e tenho a estudado melhor.
Muitas vezes ele é desabilitado porque acaba bloqueando algum serviço que precisamos. Irei mostrar aqui o audit2allow para uma simples configuração do SELINUX sem precisar desabilita-lo. No exemplo estou usando o Red Hat 7.1.

A primeira coisa é que seu SELINUX não esteja desativado. Ele tem dois modos de operação o permissive e o enforcing, o primeiro irá apenas alertar o que é negado pelas políticas e irá por padrão salvar os logs no arquivo /var/log/audit/audit.log com a tag AVC, o segundo é onde ele vai realmente aplicar as políticas e negar o que tiver que ser negado. O modo permissive é bom para troubleshooting.
Segue abaixo o arquivo de configuração, o parâmetro a ser modificado para esses modos é o SELINUX :

[root@server ~]# cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing – SELinux security policy is enforced.
#     permissive – SELinux prints warnings instead of enforcing.
#     disabled – No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of three two values:
#     targeted – Targeted processes are protected,
#     minimum – Modification of targeted policy. Only selected processes are protected.
#     mls – Multi Level Security protection.
SELINUXTYPE=targeted

Se no seu caso ele tiver desabilitado você deve reiniciar o sistema depois de modificar o arquivo. para visualizar o modo ativo pode usar o comando getenforce e para trocar o modo use setenforce 0 ou setenforce 1 (0 – permissive, 1 – enforcing).

Uma dependência no RedHat é o pacote policycoreutils-python:

[root@server ~]# yum install policycoreutils-python

Vou procurar no audit.log o que está sendo negado pelo SELINUX, usei o grep -A 1 para pegar também a mensagem de SYSCALL relativo ao acesso:

[root@server ~]# cat /var/log/audit/audit.log | grep denied -A 1
type=AVC msg=audit(1475563381.130:444590): avc:  denied  { write } for  pid=12513 comm=”logrotate” name=”www-error.log” dev=”dm-1″ ino=67955370 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=SYSCALL msg=audit(1475563381.130:444590): arch=c000003e syscall=2 success=no exit=-13 a0=2467650 a1=20002 a2=246e880 a3=7ffe8e234120 items=0 ppid=12511 pid=12513 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=21381 comm=”logrotate” exe=”/usr/sbin/logrotate” subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)

O que é importante verificar nos logs:
{ write } : Aqui é a permissão que está sendo negada, no meu caso foi a de escrita.
comm=”logrotate” : o executável que chamou o processo.
name=”www-error.log” : Aqui pode ser name ou path, é o objeto que o processo está tentando acessar.
scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023: O contexto do processo.
tcontext=system_u:object_r:usr_t:s0 tclass=file: O contexto do objeto(target).
Na na mensagem do SYSCALL temos o seguinte:
success=no : Indica se o SELINUX negou o acesso(no) ou não(yes), quando estiver em permissive provavelmente estará sempre como yes.
exe=”/usr/sbin/logrotate”: O caminho do executável que iniciou o processo.

Após verificar o log posso usar o audit2allow para verificar melhor o porquê de estar sendo negado:

[root@server ~]# grep logrotate /var/log/audit/audit.log | audit2allow -w -a
type=AVC msg=audit(1475563381.130:444590): avc:  denied  { write } for  pid=12513 comm=”logrotate” name=”www-error.log” dev=”dm-1″ ino=67955370 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usr_t:s0 tclass=file
Was caused by:
Unknown – would be allowed by active policy
Possible mismatch between this policy and the one under which the audit message was generated.

Possible mismatch between current in-memory boolean settings vs. permanent ones.

No caso estou usando o grep para pegar apenas casos relativos ao logrotate, você pode fazer isso para algum processo especifico ou para todos. A opção -a significa que ele irá pegar as informações do audit.log e -w nos dá as informações detalhadas com as possíveis causas.

Agora que temos certeza que queremos liberar esse acesso, usaremos o audit2allow para criar um modulo, este modulo criara as políticas necessárias para liberar o acesso que queremos. Vou apresentar aqui dois exemplos. Nesse primeiro comando estamos gerando um modulo para tudo que estiver no audit.log:

[root@server ~]# audit2allow -a -M MyPolicy

o MyPolicy é o nome da seu modulo.

Nesse segundo exemplo estou filtrando por problemas de acesso apenas do logrotate:

[root@server ~]# grep -i logrotate /var/log/audit/audit.log | audit2allow -M MyPolicy

Após executar um dos comandos será criado dois arquivos com o nome do modulo, um .pp e outro .te

[root@server ~]# ls
MyPolicy.pp  MyPolicy.te

Agora é só instalar nosso modulo no SELINUX:

[root@server ~]# semodule -i MyPolicy.pp

E por fim testar seu acesso e verificar que não está mais sendo bloqueado.

Até a próxima!

Referências:

https://wiki.centos.org/HowTos/SELinux
http://danwalsh.livejournal.com/24750.html

Anúncios