Aqui está uma abordagem tutorial do caso SELinux:
Descubra se o SELinux está ativo:
$ sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted
Nesse caso, algumas verificações comparativas podem ajudar. Por exemplo, um servidor tem um DocumentRoot padrão em /var/www/html, mas queremos em outro lugar /path/to/document/root.
Se o SELinux não estiver mexendo ativamente com o recurso, ls -dZo diretório mostrará algo como:
$ ls -dZ /path/to/document/root
? /path/to/document/root/
Por outro lado, se os contextos do SELinux forem aplicados, será ls -dZmais parecido com:
$ ls -dZ /path/to/document/root
drwxrws--x+ cfgadm cfgadmin system_u:object_r:file_t:s0 /path/to/document/root
Se compararmos com um DocumentRoot de trabalho, seria algo como:
$ ls -dZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html
Os argumentos _rand _trelacionam-se aos -r( --rolee -t( --type) aos chcon. Aqui está uma página de manual cortada:
NAME
chcon - change file security context
SYNOPSIS
chcon [OPTION]... CONTEXT FILE...
chcon [OPTION]... [-u USER] [-r ROLE] [-l RANGE] [-t TYPE] FILE...
chcon [OPTION]... --reference=RFILE FILE...
DESCRIPTION
Change the security context of each FILE to CONTEXT. With --reference,
change the security context of each FILE to that of RFILE.
--reference=RFILE
use RFILE's security context rather than specifying a CONTEXT value
-R, --recursive
operate on files and directories recursively
À primeira vista, o seguinte pode parecer funcionar, mas pode não funcionar.
$ sudo chcon -R -t httpd_sys_content_t /path/to/document/root
Se o servidor da Web ainda não conseguir ver o DocumentRoot, observe que o contexto importa desde o início até a raiz:
$ sudo chcon -R -t httpd_sys_content_t /path/to/document
$ sudo chcon -R -t httpd_sys_content_t /path/to
$ sudo chcon -R -t httpd_sys_content_t /path
Neste ponto, o servidor da web pode ver o diretório.
Sim, eu aprendi da maneira mais difícil hoje à noite.
NOTA: O uso do chcon conceitualmente tem uma desvantagem conforme a documentação do RedHat ( 5.6.1. Alterações temporárias: chcon ) que afirma:
The chcon command changes the SELinux context for files. However, changes
made with the chcon command do not survive a file system relabel, or the
execution of the restorecon command.
Use semanage e restorecon para fazer mudanças mais permanentes. Um breve exemplo:
$ sudo semanage fcontext --add -t httpd_sys_content_t -s system_u \
"/path/to/document/root(/.*)?"
$ sudo restorecon -FR /path/to/document/root
Com relação ao restorecon , observe que -F é necessário para afetar todo o contexto (isto é, usuário e tipo). Além disso, -R significa fazer alterações recursivamente. Os argumentos -v ou -p podem mostrar o progresso de maneira detalhada ou concisa. Use -FRnv para ver o que aconteceria sem realmente fazer alterações.
Depois que a semântica é usada dessa maneira, é possível visualizar as alterações de segurança local com um comando como:
$ sudo semanage export
A saída da exportação de semânticas pode ser salva e usada pela importação de semânticas para facilitar a aplicação de um conjunto de alterações em vários sistemas.
NOTA: Esta resposta fornece um contexto de tipo mais básico para um site. A segurança pode ser muito mais granular. Por exemplo, veja uma lista de tipos que podem ser aplicados às páginas do servidor da web com um comando como:
$ seinfo -t | grep http
NOTA: Utilitários como semanage e Seinfo não pode ser instalado por padrão. Pelo menos em algumas distribuições, os pacotes necessários podem ter o seguinte nome:
policycoreutils-python
setools-console
DocumentRoot, isso pode lhe dar uma ideia do que o servidor da web está vendo. Você também pode querer verificar os outros diretórios ao longo do caminho, embora se é realmente sob/var/www/aqueles que não deve ser um problema