Tenho uma aplicação PHP que se conecta a um banco de dados Postgresql. Isso funciona quando me conecto via rede, mas recebo uma violação do SELinux ao tentar conectar usando o soquete. Acredito que os contextos estão definidos corretamente e os sinalizadores corretos estão habilitados.
httpd_can_network_connect --> on
httpd_can_network_connect_db --> on
a mensagem de alerta para a falha é assim:
SELinux is preventing /usr/sbin/php-fpm from connectto access on the unix_stream_socket /run/postgresql/.s.PGSQL.5432.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that php-fpm should be allowed connectto access on the .s.PGSQL.5432 unix_stream_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'php-fpm' --raw | audit2allow -M my-phpfpm
# semodule -X 300 -i my-phpfpm.pp
Additional Information:
Source Context system_u:system_r:httpd_t:s0
Target Context system_u:system_r:unconfined_service_t:s0
Target Objects /run/postgresql/.s.PGSQL.5432 [ unix_stream_socket
]
Source php-fpm
Source Path /usr/sbin/php-fpm
Port <Unknown>
Host localhost.localdomain
Source RPM Packages php-fpm-8.2.13-1.el9.remi.x86_64
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-38.1.23-1.el9.noarch
Local Policy RPM selinux-policy-targeted-38.1.23-1.el9.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name localhost.localdomain
Platform Linux localhost.localdomain
5.14.0-362.8.1.el9_3.x86_64 #1 SMP PREEMPT_DYNAMIC
Wed Nov 8 17:36:32 UTC 2023 x86_64 x86_64
Alert Count 1080
First Seen 2023-12-29 14:34:45 PST
Last Seen 2024-01-31 12:15:18 PST
Local ID e3bcfa07-6867-47e3-bedf-4d8ca2d16443
Raw Audit Messages
type=AVC msg=audit(1706732118.737:4455): avc: denied { connectto } for pid=516281 comm="php-fpm" path="/run/postgresql/.s.PGSQL.5432" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
type=SYSCALL msg=audit(1706732118.737:4455): arch=x86_64 syscall=connect success=no exit=EACCES a0=8 a1=561638666d58 a2=6e a3=7fa9f9d951a0 items=0 ppid=516267 pid=516281 auid=4294967295 uid=984 gid=984 euid=984 suid=984 fsuid=984 egid=984 sgid=984 fsgid=984 tty=(none) ses=4294967295 comm=php-fpm exe=/usr/sbin/php-fpm subj=system_u:system_r:httpd_t:s0 key=(null)
Hash: php-fpm,httpd_t,unconfined_service_t,unix_stream_socket,connectto
Uma coisa que parece estranha é a falta de um pacote RPM para o soquete postgres.
São fornecidas instruções para gerar um módulo de política local; mas não entendo exatamente o que esses comandos farão e hesito em executá-los.
ausearch -c 'php-fpm' --raw | audit2allow -M my-phpfpm
semodule -X 300 -i my-phpfpm.pp
Esses comandos criam uma política selinux.
ausearch
verifica os logs de auditoria para descobrir o que o PHP queria fazer eaudit2allow
cria uma política que permite tudo o que o primeiro comando encontrou. Em seguida,semodule
ativa a política recém-criada.Sugiro adicionar
-a 4455
uma chave aoausearch
comando para permitir apenas o que foi proibido durante este evento específico. Isso seria mais seguro, pois não permitirá acidentalmente nada não relacionado:Observe também que nomeei a política de forma um pouco diferente, porque com esse filtro sabemos com certeza o que exatamente ela permite.
Veja
man ausearch
eman audit2allow
eman semodule
para detalhes.Não poderia haver nenhum pacote para o arquivo de soquete. Um soquete é um objeto de sistema de arquivos dinâmico, que é criado e removido instantaneamente. Pense que é um "arquivo temporário" que só é válido enquanto o serviço que o criou está em execução. Por esse motivo, os soquetes geralmente são criados em um sistema de arquivos não volátil na memória, montado como
/run
, que não persiste durante a reinicialização.O que é realmente estranho é que o tipo selinux do soquete é
unconfined_service_t
. Deveria haver um tipo predefinido para o soquete Postgres e uma política que permitiria quehttd_t
os processos o acessassem. Acho que é sensato registrar a solicitação de recurso para que isso seja implementado.O problema aqui parece ser que você está executando
php-fpm
como umunconfined_service_t
serviço. Como você iniciou o serviço?Se você estiver iniciando por meio,
systemd
sugiro executar uma nova etiqueta nos pacotes, pois algo não está marcado corretamente.php-fpm
no meu sistema surge comohttpd_t
tal, um monte de regras já em execução para o serviço devem ser aplicadas e funcionar para você.Deve renomear todos os pacotes PHP corretamente. Em seguida, reinicie
php-fpm
normalmentesystemctl
.