O SELinux não impõe restrições de gravação do apache apesar de estar ativado

Question

Problema: O SELinux não protege arquivos e diretórios rotulados como httpd_sys_content_t de serem gravados, excluídos ou alterados quando uma nova raiz de documento / personalizada é criada.

Eu reproduzi esse comportamento duas vezes em diferentes construções de servidor. O ambiente é uma instalação limpa e nova do CentOS 7. Remendada completamente pelo yum. repo epl instalado. apache, php, mysql (mariadb), phpmyadmin instalado.

O SELinux é habilitado por padrão no CentOS 7. getenforce e sestatus confirmam que o SELinux está sendo executado.

Eu criei um virtualhost simples no apache com sua raiz de documentos definida como: / web / sites / test1

No começo, tudo funciona como esperado. O SELinux não permitirá que o apache exiba o site até que eu faça o seguinte:

semanage fcontext --add --type httpd_sys_content_t "/web(/.*)?"
semanage fcontext --add --type httpd_sys_content_t "/web/sites(/.*)?"
restorecon -Rv /web

Como esperado, depois disso, o virtualhost funcionou.

No entanto, o estranho comportamento é que, ao instalar o wordpress nesse virtualhost, posso fazer upload de imagens e coisas desse tipo via wordpress, mesmo que o contexto httpd_sys_content_t não permita isso (de acordo com o meu entendimento).

Confirmei que todos os arquivos no diretório wordpress estão rotulados corretamente como tipo: httpd_sys_content_t

No entanto, o wordpress ainda é capaz de gravar no diretório (desde que as permissões de arquivo antigas o permitam).

Eu criei uma solução: o comportamento típico / esperado é restaurado ao fazer uma nova rotulação do sistema de arquivos:

touch /.autorelabel
reboot

Na reinicialização, devo usar o contexto httpd_sys_rw_content_t como seria de esperar. Mas gostaria de entender com mais clareza por que esse passo é necessário, uma vez que li que uma nova etiquetagem completa raramente (ou nunca) seria necessária. Existe algum meio mais fácil e menos drástico de fazer com que o SELinux se comporte como esperado?

Para ser mais conciso: Devo esperar ter que fazer um "touch / .autorelabel" em uma situação como essa? Existe uma maneira melhor? Deveria funcionar sem mais nada (e este é, portanto, um bug com o CentOS 7 'fora da caixa')?

    

Answer 1

Os comentários de @ dawud estão incorretos. As permissões do DAC são verificadas primeiro . Se eles negarem acesso, o processo receberá permissão negada. Se o DAC permitir acesso, a política do selinux MAC será verificada. Se o DAC permitir o acesso, mas o MAC negar o acesso, o acesso será negado. O DAC nunca pode substituir o MAC. Diagrama

Seu plugin Wordpress deve ser rotulado com httpd_sys_script_exec_t e, portanto, ser executado como httpd_sys_script_t . Usei apol , a ferramenta de análise de políticas, para examinar a política em uma VM do CentOS. Acontece que, quando os% booleans httpd_enable_cgi e httpd_unified estão habilitados, as regras de permissão são ativadas para que os processos com o rótulo httpd_sys_script_t tenham acesso total aos objetos marcados com httpd_sys_content_t .

Abaixo estão as regras ofensivas que são ativadas (indicadas pelos comentários [Enabled]). Observe que httpdcontent é um atributo do SELinux atribuído na política para todos os httpd_sys*content_t labels, portanto, essas regras se aplicam a todos eles.

allow httpd_sys_script_t httpdcontent : dir { ioctl read write create getattr setattr lock unlink link rename add_name remove_name reparent search rmdir open } ;  [Enabled]
allow httpd_sys_script_t httpdcontent : file { ioctl read write create getattr setattr lock append unlink link rename entrypoint open } ;  [Enabled]
allow httpd_sys_script_t httpdcontent : lnk_file { ioctl read write create getattr setattr lock append unlink link rename } ;  [Enabled]

Também estão ativadas as regras de transição de tipo que fazem com que novos objetos criados por um processo httpd_sys_script_t em um diretório httpd_sys_content_t -labeled sejam rotulados com httpd_sys_rw_content_t .

type_transition httpd_sys_script_t httpd_sys_content_t : dir httpd_sys_rw_content_t;  [Enabled]
type_transition httpd_sys_script_t httpd_sys_content_t : file httpd_sys_rw_content_t;  [Enabled]
type_transition httpd_sys_script_t httpd_sys_content_t : lnk_file httpd_sys_rw_content_t;  [Enabled]

Eu verifiquei o Red Hat Apache SELinux docs e descobriu isso:

httpd_unified
When enabled, this Boolean allows httpd_t complete access to all of the httpd types (that is to execute, read, or write sys_content_t). When disabled, there is separation in place between web content that is read-only, writeable or executable. Disabling this Boolean ensures an extra level of security but adds the administrative overhead of having to individually label scripts and other web content based on the file access that each should have.

Experimente desligar o link e veja se as coisas se comportam da maneira esperada.