O SELinux está impedindo / usr / bin / bash de executar o acesso no arquivo myfilename.sh no nginx via php-fpm

0

Histórico: Eu tenho dois servidores CentOS7. Test & Prod .
Existe um script myfilename.sh no meu site, que é executado em php por shell_exec .
Script e todas as pastas pai em ambos os servidores têm contexto selinux idêntico. httpd_sys_rw_content_t

Descrição do problema: Script é executado corretamente em Test server, mas não funciona em Prod .
Log de auditoria em Prod diz SELinux is preventing /usr/bin/bash from execute access on the file myfilename.sh. , mas nada aparece em Test box.

Qualquer ideia do que poderia ter corrido mal e porque o script está funcionando em Test box. Preciso reproduzir o problema no servidor Test antes de corrigi-lo no prod.

Aqui está o log de auditoria:

SELinux is preventing /usr/bin/bash from execute access on the file myfilename.sh.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that bash should be allowed execute access on the myfilename.sh file 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 'sh' --raw | audit2allow -M my-sh
# semodule -i my-sh.pp


Additional Information:
Source Context                system_u:system_r:httpd_sys_script_t:s0
Target Context                unconfined_u:object_r:httpd_sys_rw_content_t:s0
Target Objects                myfilename.sh [ file ]
Source                        sh
Source Path                   /usr/bin/bash
Port                          <Unknown>
Host                          <Unknown>
Source RPM Packages           bash-4.2.46-21.el7_3.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-102.el7_3.16.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     ip-X-X-X-X
Platform                      Linux ip-X-X-X-X 3.10.0-327.10.1.el7.x86_64
                              #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64
Alert Count                   23
First Seen                    2017-06-17 06:33:36 CDT
Last Seen                     2017-06-18 02:18:01 CDT
Local ID                      340158ca-61f6-4472-aadb-18a3bbc34a22

Raw Audit Messages
type=AVC msg=audit(1497770281.465:12508): avc:  denied  { execute } for  pid=10042 comm="sh" name="myfilename.sh" dev="xvdc" ino=3416830 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:httpd_sys_rw_content_t:s0 tclass=file


type=SYSCALL msg=audit(1497770281.465:12508): arch=x86_64 syscall=execve success=no exit=EACCES a0=20d5650 a1=20d5730 a2=20d3c20 a3=7ffe9f4d7de0 items=0 ppid=10041 pid=10042 auid=4294967295 uid=995 gid=992 euid=995 suid=995 fsuid=995 egid=992 sgid=992 fsgid=992 tty=(none) ses=4294967295 comm=sh exe=/usr/bin/bash subj=system_u:system_r:httpd_sys_script_t:s0 key=(null)

Hash: sh,httpd_sys_script_t,httpd_sys_rw_content_t,file,execute
    
por SarkarG 18.06.2017 / 21:53

1 resposta

1
O contexto

link não funcionará para executáveis. Precisamos definir o contexto link para isso

sudo semanage fcontext -a -t httpd_sys_script_exec_t  "/PATH_TO_FILE/myfilename.sh"

E não se esqueça de executar o restaurorecon.

sudo restorecon -Rv /PATH_TO_FILE/
    
por 02.06.2018 / 23:56

Tags