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
