Não é possível iniciar o Redis no SELinux

3

Estou tendo um problema bastante persistente com minha Redis instance. Enquanto SELinux está no modo enforcing , Redis server não consegue iniciar:

[root@server ~]# service redis start
Starting redis-server:                                     [  OK  ]

Mas, na verdade, não foi iniciado como mostrado por lsof . Não retorna nenhum resultado:

[root@server ~]# lsof -i :6379

Para confirmar se não está em execução, há um log de redis:

[5539] 21 Nov 03:44:34 # Opening port 6379: bind: Permission denied

Agora, sou muito novo, com SELinux gerenciando, por favor, tenha paciência comigo, pois talvez eu tenha perdido alguma coisa. Isso foi o que consegui ver:

[root@server ~]# semanage port -l | grep "redis"
redis_port_t                   tcp      6379

[root@server ~]# semanage user -l
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
....
redis           user       s0         s0                             user_r
....

O usuário redis acima não existia inicialmente, mas tentei adicioná-lo como redis-server realmente executado sob ele. Isso não ajudou ...

Apenas para notar, o servidor Redis é usado internamente, então ele escuta apenas 127.0.0.1:6379 .

Alguém tem alguma ideia?

Por enquanto, eu posso colocar SELinux no modo permissivo, mas eu realmente gostaria de apertar e fazer "by-the-book".

UPDATE:

[root@server ~]# ausearch -ts recent -m avc
----
time->Thu Nov 24 13:48:13 2016
type=SYSCALL msg=audit(1480013293.595:34717): arch=c000003e syscall=49 success=no exit=-13 a0=4 a1=7ffea866c0f0 a2=10 a3=7ffea866be50 items=0 ppid=1 pid=16468 auid=0 uid=495 gid=495 euid=495 suid=495 fsuid=495 egid=495 sgid=495 fsgid=495 tty=(none) ses=5202 comm="redis-server" exe="/usr/sbin/redis-server" subj=unconfined_u:system_r:redis_t:s0 key=(null)
type=AVC msg=audit(1480013293.595:34717): avc:  denied  { name_bind } for  pid=16468 comm="redis-server" src=6379 scontext=unconfined_u:system_r:redis_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket

UPDATE (2)

[root@server ~]# rpm -qa | grep -i redis
redis-2.4.10-1.el6.x86_64
php56w-pecl-redis-2.2.7-1.w6.x86_64

SOLUÇÃO:

Seguindo a sugestão de @ Matthew, comecei a analisar o redis_port_t e http_port_t :

[root@server ~]# semanage port -l | grep "redis_port_t"
redis_port_t                   tcp      6379

[root@server ~]# semanage port -l | grep "http_port_t"
http_port_t                    tcp      6379, 80, 81, 443, 488, 8008, 8009, 8443, 9000

E lá estava! A porta 6379 foi adicionada a ambas as políticas de porta! E sim, eu sei lembrar de fazer isso quando comecei a migração :( (que vergonha).

Então, executar isso resolveu o problema:

semanage port -d -t http_port_t 6379
semanage permissive -d redis_t // I don't need this anymore
service redis restart
lsof -i :6379

E lá estava:)

redis-ser 4575 redis    4u  IPv4 236174      0t0  TCP localhost:6379 (LISTEN)
    
por Jovan Perovic 21.11.2016 / 10:01

1 resposta

3

Eu acho que há algo estranho acontecendo nessa política.

Se você verificar os logs de auditoria, ele diz que o contexto de origem do SELinux está corretamente rotulado como redis_t e o contexto de destino está marcado como http_port_t . Isto é, apesar do que sua política diz, que deve ser redis_port_t .

Isso significa o que está no kernel e o que está na política não corresponde. A porta ainda é 6379 embora.

Convém verificar o que você configurou para seu http_port_t e também seu redis_port_t . Tanto quanto eu entendo, ligações de política de porta só podem ter um rótulo por porta / protocolo, então eu suspeito que o que está em seu repositório de políticas não reflete o que está em seu servidor atualmente.

Você pode tentar fazer um semodule -B para reconstruir e recarregar sua política para tentar corrigir o problema de sincronização.

Se não tiver sorte, pesquise o que está nas listagens de porta para http_port_t e atualize a pergunta.

    
por 25.11.2016 / 15:23

Tags