O Security Enhanced Linux (SELinux) oferece uma camada adicional de segurança do sistema. O SELinux responde fundamentalmente à pergunta: May <subject> do <action> to <object>?, por exemplo May a web server access files in users' home directories?

A política de acesso padrão baseada no usuário, grupo e outras permissões, conhecida como Controle de Acesso Discricionário (DAC), não permite que os administradores de sistema criem políticas de segurança abrangentes e de granulação fina, tais como restringir aplicações específicas a apenas visualizar arquivos de log, enquanto permite que outras aplicações anexem novos dados aos arquivos de log.

A SELinux implementa o Controle de Acesso Obrigatório (MAC). Cada recurso de processo e sistema tem uma etiqueta de segurança especial chamada SELinux context. Um contexto SELinux, às vezes referido como SELinux label, é um identificador que abstrai os detalhes em nível de sistema e se concentra nas propriedades de segurança da entidade. Isto não apenas fornece uma maneira consistente de referenciar objetos na política SELinux, mas também elimina qualquer ambiguidade que possa ser encontrada em outros métodos de identificação. Por exemplo, um arquivo pode ter vários nomes de caminho válidos em um sistema que faz uso de suportes de encadernação.

A política SELinux utiliza estes contextos em uma série de regras que definem como os processos podem interagir uns com os outros e os vários recursos do sistema. Por padrão, a política não permite qualquer interação, a menos que uma regra conceda acesso explícito.

Os contextos SELinux têm vários campos: usuário, função, tipo e nível de segurança. A informação do tipo SELinux é talvez a mais importante quando se trata da política SELinux, como a regra política mais comum que define as interações permitidas entre processos e recursos do sistema utiliza tipos SELinux e não o contexto SELinux completo. Os tipos de SELinux terminam com _t. Por exemplo, o nome do tipo para o servidor web é httpd_t. O contexto do tipo para arquivos e diretórios normalmente encontrados em /var/www/html/ é httpd_sys_content_t. O tipo de contexto para arquivos e diretórios normalmente encontrado em /tmp e /var/tmp/ é tmp_t. O contexto do tipo para as portas do servidor web é http_port_t.

Há uma regra de política que permite ao Apache (o processo do servidor web funcionando como httpd_t) acessar arquivos e diretórios com um contexto normalmente encontrado em /var/www/html/ e outros diretórios de servidores web (httpd_sys_content_t). Não há uma regra de permissão na política para arquivos normalmente encontrados em /tmp e /var/tmp/, portanto, o acesso não é permitido. Com o SELinux, mesmo que o Apache esteja comprometido, e um script malicioso ganhe acesso, ele ainda não é capaz de acessar o diretório /tmp.

Figura 1.1. Um exemplo de como a SELinux pode ajudar a administrar o Apache e a MariaDB de forma segura.

Como o esquema anterior mostra, o SELinux permite que o processo Apache em execução como httpd_t acesse o diretório /var/www/html/ e nega o mesmo processo para acessar o diretório /data/mysql/ porque não há regra de permissão para os contextos do tipo httpd_t e mysqld_db_t. Por outro lado, o processo MariaDB rodando como mysqld_t pode acessar o diretório /data/mysql/ e o SELinux também nega corretamente o processo com o tipo mysqld_t para acessar o diretório /var/www/html/ rotulado como httpd_sys_content_t.

A SELinux oferece os seguintes benefícios:

No entanto, a SELinux não é:

A SELinux é projetada para melhorar as soluções de segurança existentes, não para substituí-las. Mesmo ao executar o SELinux, é importante continuar seguindo boas práticas de segurança, tais como manter o software atualizado, utilizando senhas difíceis de adivinhar e firewalls.

Os exemplos a seguir demonstram como a SELinux aumenta a segurança:

SELinux é um Módulo de Segurança Linux (LSM) que está embutido no kernel do Linux. O subsistema SELinux no kernel é conduzido por uma política de segurança que é controlada pelo administrador e carregada na inicialização. Todas as operações de acesso ao sistema relevantes para a segurança, em nível de kernel, são interceptadas pelo SELinux e examinadas no contexto da política de segurança carregada. Se a política carregada permitir a operação, ela continua. Caso contrário, a operação é bloqueada e o processo recebe um erro.

As decisões da SELinux, tais como permitir ou não o acesso, são armazenadas em cache. Este cache é conhecido como Access Vector Cache (AVC). Ao utilizar estas decisões em cache, as regras da política SELinux precisam ser menos verificadas, o que aumenta o desempenho. Lembre-se que as regras da política SELinux não têm efeito se as regras do DAC negarem o acesso primeiro. As mensagens brutas de auditoria são registradas no /var/log/audit/audit.log e começam com a seqüência type=AVC.

No Red Hat Enterprise Linux 8, os serviços do sistema são controlados pelo daemon systemd; systemd inicia e pára todos os serviços, e os usuários e processos comunicam-se com systemd usando o utilitário systemctl. O daemon systemd pode consultar a política SELinux e verificar a etiqueta do processo de chamada e a etiqueta do arquivo da unidade que o chamador tenta gerenciar, e então perguntar ao SELinux se o acesso é permitido ou não ao chamador. Esta abordagem fortalece o controle de acesso às capacidades críticas do sistema, que incluem iniciar e parar os serviços do sistema.

O daemon systemd também trabalha como um Gerente de Acesso SELinux. Ele recupera o rótulo do processo em execução systemctl ou o processo que enviou uma mensagem D-Bus para systemd. O daemon então procura a etiqueta do arquivo da unidade que o processo quis configurar. Finalmente, systemd pode recuperar informações do kernel se a política do SELinux permitir o acesso específico entre a etiqueta do processo e a etiqueta do arquivo de unidade. Isto significa que uma aplicação comprometida que precisa interagir com systemd para um serviço específico pode agora ser confinada pelo SELinux. Os redatores de políticas também podem utilizar estes controles de granulação fina para confinar os administradores.

O Red Hat Enterprise Linux 8 fornece os seguintes pacotes para trabalhar com o SELinux:

A SELinux pode funcionar em um dos três modos: coercitivo, permissivo, ou desativado.

Use o utilitário setenforce para mudar entre o modo coercitivo e permissivo. As mudanças feitas com setenforce não persistem através de reinicializações. Para mudar para o modo de imposição, digite o comando setenforce 1 como usuário root do Linux. Para mudar para o modo permissivo, digite o comando setenforce 0. Use o utilitário getenforce para visualizar o modo SELinux atual:

# getenforce
Enforcing

# setenforce 0
# getenforce
Permissive

# setenforce 1
# getenforce
Enforcing

No Red Hat Enterprise Linux, você pode definir domínios individuais para o modo permissivo enquanto o sistema roda em modo de execução. Por exemplo, para tornar o domínio httpd_t permissivo:

# semanage permissive -a httpd_t

Note que os domínios permissivos são uma ferramenta poderosa que pode comprometer a segurança de seu sistema. A Red Hat recomenda usar os domínios permissivos com cautela, por exemplo, na depuração de um cenário específico.

Como discutido nos estados e modos SELinux, a SELinux pode ser ativada ou desativada. Quando ativada, a SELinux tem dois modos: coercitivo e permissivo.

Use os comandos getenforce ou sestatus para verificar em que modo o SELinux está funcionando. O comando getenforce retorna Enforcing, Permissive, ou Disabled.

O comando sestatus retorna o status SELinux e a política SELinux sendo utilizada:

$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      31

Use o seguinte procedimento para mudar permanentemente o modo SELinux para permissivo. Quando o SELinux está em modo permissivo, a política SELinux não é aplicada. O sistema permanece operacional e o SELinux não nega nenhuma operação, mas apenas registra mensagens AVC, que podem então ser utilizadas para solução de problemas, depuração e melhorias na política SELinux. Neste caso, cada AVC é registrado apenas uma vez.

Use o seguinte procedimento para mudar o SELinux para o modo de aplicação. Quando o SELinux está funcionando em modo de aplicação, ele aplica a política SELinux e nega o acesso com base nas regras da política SELinux. No RHEL, o modo de aplicação é ativado por padrão quando o sistema foi inicialmente instalado com o SELinux.

# ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts today

# grep "SELinux is preventing" /var/log/messages

# dmesg | grep -i -e type=1300 -e type=1400

Quando você habilita o SELinux em sistemas que anteriormente o tinham desabilitado, para evitar problemas, tais como sistemas incapazes de inicializar ou de processar falhas, siga este procedimento:

Utilize o seguinte procedimento para desativar permanentemente a SELinux.

Na inicialização, você pode definir vários parâmetros do kernel para mudar a maneira como o SELinux funciona:

Cada usuário Linux é mapeado para um usuário SELinux utilizando a política SELinux. Isto permite aos usuários do Linux herdar as restrições dos usuários do SELinux.

Para ver o mapeamento do usuário SELinux em seu sistema, use o comando semanage login -l como raiz:

# semanage login -l
Login Name           SELinux User         MLS/MCS Range        Service

__default__          unconfined_u         s0-s0:c0.c1023       *
root                 unconfined_u         s0-s0:c0.c1023       *

No Red Hat Enterprise Linux, os usuários do Linux são mapeados para o SELinux default login por padrão, que é mapeado para o usuário do SELinux unconfined_u. A linha a seguir define o mapeamento padrão:

__default__          unconfined_u         s0-s0:c0.c1023       *

Os usuários de Linux confinados e não confinados estão sujeitos a verificações de memória executáveis e graváveis, e também são restringidos pelo MCS ou MLS.

Para listar os usuários SELinux disponíveis, digite o seguinte comando:

$ seinfo -u
Users: 8
   guest_u
   root
   staff_u
   sysadm_u
   system_u
   unconfined_u
   user_u
   xguest_u

Note que o comando seinfo é fornecido pelo pacote setools-console, que não é instalado por padrão.

Se um usuário Linux não definido executa uma aplicação que a política SELinux define como aquela que pode fazer a transição do domínio unconfined_t para seu próprio domínio confinado, o usuário Linux não definido ainda está sujeito às restrições desse domínio confinado. O benefício de segurança disto é que, mesmo que um usuário Linux esteja executando um domínio não-confinado, a aplicação permanece confinada. Portanto, a exploração de uma falha na aplicação pode ser limitada pela política.

Da mesma forma, podemos aplicar estas verificações a usuários confinados. Cada usuário confinado é restringido por um domínio de usuário confinado. A política SELinux também pode definir uma transição de um domínio de usuário confinado para seu próprio domínio alvo confinado. Nesse caso, os usuários confinados estão sujeitos às restrições desse domínio de destino confinado. O ponto principal é que privilégios especiais são associados aos usuários confinados de acordo com seu papel.

A tabela a seguir fornece exemplos de domínios básicos confinados para usuários Linux no Red Hat Enterprise Linux:

Note que system_u é uma identidade especial de usuário para processos e objetos do sistema. Ela nunca deve ser associada a um usuário Linux. Além disso, unconfined_u e root são usuários não-confinados. Por estas razões, eles não estão incluídos na tabela anterior de capacidades de usuário do SELinux.

Além dos já mencionados usuários do SELinux, existem papéis especiais, que podem ser mapeados para aqueles usuários usando o comando semanage user. Estas funções determinam o que o SELinux permite que o usuário faça:

Para listar todas as funções disponíveis, digite o comando seinfo -r:

$ seinfo -r
Roles: 14
   auditadm_r
   dbadm_r
   guest_r
   logadm_r
   nx_server_r
   object_r
   secadm_r
   staff_r
   sysadm_r
   system_r
   unconfined_r
   user_r
   webadm_r
   xguest_r

Note que o comando seinfo é fornecido pelo pacote setools-console, que não é instalado por padrão.

O procedimento a seguir demonstra como adicionar um novo usuário Linux ao sistema. O usuário é automaticamente mapeado para o usuário do SELinux unconfined_u.

Use os seguintes passos para adicionar um novo usuário definido pelo SELinux ao sistema. Este procedimento de exemplo mapeia o usuário para o SELinux staff_u direito com o comando para criar a conta de usuário.

Por default, todos os usuários Linux no Red Hat Enterprise Linux, incluindo usuários com privilégios administrativos, são mapeados para o usuário SELinux não-confinado unconfined_u. Você pode melhorar a segurança do sistema designando usuários para usuários confinados ao SELinux. Isto é útil para estar em conformidade com o Guia de Implementação Técnica de Segurança V-71971. Para mais informações sobre usuários confinados e não-confinados, consulte Gerenciando usuários confinados e não-confinados.

Você pode configurar o servidor HTTP Apache para ouvir em uma porta diferente e fornecer conteúdo em um diretório não padrão. Para evitar negações conseqüentes do SELinux, siga os passos deste procedimento para ajustar a política SELinux de seu sistema.

Você pode mudar partes da política SELinux em tempo de execução utilizando booleans, mesmo sem qualquer conhecimento da política da SELinux. Isto permite mudanças, tais como permitir o acesso de serviços a volumes NFS, sem recarregar ou recompilar a política SELinux. O procedimento seguinte demonstra a listagem de booleans SELinux e sua configuração para alcançar as mudanças necessárias na política.

As montagens NFS no lado do cliente são etiquetadas com um contexto padrão definido por uma política para volumes NFS. Na RHEL, este contexto padrão usa o tipo nfs_t. Além disso, as montagens de Samba no lado do cliente são etiquetadas com um contexto padrão definido pela política. Este contexto padrão usa o tipo cifs_t. Você pode habilitar ou desabilitar booleans para controlar quais serviços estão autorizados a acessar os tipos nfs_t e cifs_t.

Para permitir que o serviço servidor HTTP Apache (httpd) acesse e compartilhe volumes NFS e CIFS, execute os seguintes passos:

Siga apenas as etapas necessárias a partir deste procedimento; na maioria dos casos, você precisa executar apenas a etapa 1.

Após identificar que a SELinux está bloqueando seu cenário, talvez você precise analisar a causa raiz antes de escolher uma correção.

Na maioria dos casos, as sugestões fornecidas pela ferramenta sealert lhe dão a orientação correta sobre como corrigir problemas relacionados com a política SELinux. Consulte Analisando as mensagens de recusa da SELinux para obter informações sobre como utilizar sealert para analisar as recusas da SELinux.

Tenha cuidado quando a ferramenta sugerir o uso da ferramenta audit2allow para mudanças de configuração. Você não deve usar audit2allow para gerar um módulo de política local como sua primeira opção quando você vê uma negação do SELinux. A solução de problemas deve começar com uma verificação se houver um problema de etiquetagem. O segundo caso mais frequente é que você alterou uma configuração de processo, e esqueceu de informar ao SELinux sobre isso.

# semanage fcontext -a -t httpd_sys_content_t "/srv/myweb(/.*)?"

Este comando semanage adiciona o contexto do diretório /srv/myweb/ e todos os arquivos e diretórios sob ele à configuração de contexto de arquivo SELinux. O utilitário semanage não altera o contexto. Como root, use o utilitário restorecon para aplicar as mudanças:

# restorecon -R -v /srv/myweb

$ matchpathcon -V /var/www/html/*
/var/www/html/index.html has context unconfined_u:object_r:user_home_t:s0, should be system_u:object_r:httpd_sys_content_t:s0
/var/www/html/page1.html has context unconfined_u:object_r:user_home_t:s0, should be system_u:object_r:httpd_sys_content_t:s0

Neste exemplo, os arquivos index.html e page1.html estão etiquetados com o tipo user_home_t. Este tipo é utilizado para arquivos em diretórios residenciais de usuários. O uso do comando mv para mover arquivos de seu diretório home pode resultar em arquivos rotulados com o tipo user_home_t. Este tipo não deve existir fora dos diretórios home. Use o utilitário restorecon para restaurar tais arquivos ao seu tipo correto:

# restorecon -v /var/www/html/index.html
restorecon reset /var/www/html/index.html context unconfined_u:object_r:user_home_t:s0->system_u:object_r:httpd_sys_content_t:s0

Para restaurar o contexto para todos os arquivos sob um diretório, use a opção -R:

# restorecon -R -v /var/www/html/
restorecon reset /var/www/html/page1.html context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0
restorecon reset /var/www/html/index.html context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0

Por exemplo, para permitir que o Servidor HTTP Apache se comunique com a MariaDB, habilite o booleano httpd_can_network_connect_db:

# setsebool -P httpd_can_network_connect_db on

Note que a opção -P faz com que a configuração seja persistente em todas as reinicializações do sistema.

Se o acesso for negado para um determinado serviço, use os utilitários getsebool e grep para ver se há alguma booleana disponível para permitir o acesso. Por exemplo, use o comando getsebool -a | grep ftp para pesquisar booleans relacionados ao FTP:

$ getsebool -a | grep ftp
ftpd_anon_write --> off
ftpd_full_access --> off
ftpd_use_cifs --> off
ftpd_use_nfs --> off

ftpd_connect_db --> off
httpd_enable_ftp_server --> off
tftp_anon_write --> off

Para obter uma lista de booleanos e descobrir se eles estão habilitados ou desabilitados, use o comando getsebool -a. Para obter uma lista de booleans incluindo seu significado, e para descobrir se eles estão habilitados ou desabilitados, instale o pacote selinux-policy-devel e use o comando semanage boolean -l como root.

# semanage port -l | grep http
http_cache_port_t              tcp      3128, 8080, 8118
http_cache_port_t              udp      3130
http_port_t                    tcp      80, 443, 488, 8008, 8009, 8443
pegasus_http_port_t            tcp      5988
pegasus_https_port_t           tcp      5989

O tipo de porta http_port_t define as portas em que o Servidor HTTP Apache pode ouvir, que neste caso são as portas TCP 80, 443, 488, 8008, 8009, e 8443. Se um administrador configura httpd.conf para que httpd escute na porta 9876 (Listen 9876), mas a política não é atualizada para refletir isto, o seguinte comando falha:

# systemctl start httpd.service
Job for httpd.service failed. See 'systemctl status httpd.service' and 'journalctl -xn' for details.

# systemctl status httpd.service
httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
   Active: failed (Result: exit-code) since Thu 2013-08-15 09:57:05 CEST; 59s ago
  Process: 16874 ExecStop=/usr/sbin/httpd $OPTIONS -k graceful-stop (code=exited, status=0/SUCCESS)
  Process: 16870 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)

Uma mensagem de negação da SELinux semelhante à seguinte está registrada em /var/log/audit/audit.log:

type=AVC msg=audit(1225948455.061:294): avc:  denied  { name_bind } for  pid=4997 comm="httpd" src=9876 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket

Para permitir que httpd escute em uma porta que não esteja listada para o tipo http_port_t, use o comando semanage port para atribuir uma etiqueta diferente à porta:

# semanage port -a -t http_port_t -p tcp 9876

A opção -a acrescenta um novo registro; a opção -t define um tipo; e a opção -p define um protocolo. O último argumento é o número da porta a ser adicionado.

Para estas situações, após o acesso ser negado, use o utilitário audit2allow para criar um módulo de política personalizada para permitir o acesso. Você pode relatar a falta de regras na política SELinux em Red Hat Bugzilla. Para o Red Hat Enterprise Linux 8, crie bugs contra o produto Red Hat Enterprise Linux 8, e selecione o componente selinux-policy. Inclua a saída dos comandos audit2allow -w -a e audit2allow -a em tais relatórios de bugs.

Se um pedido pede grandes privilégios de segurança, pode ser um sinal de que o pedido está comprometido. Use ferramentas de detecção de intrusão para inspecionar tal comportamento suspeito.

O Solution Engine no Portal do Cliente da Red Hat também pode fornecer orientações na forma de um artigo contendo uma possível solução para o mesmo problema ou para um problema muito semelhante. Selecione o produto e versão relevantes e use palavras-chave relacionadas ao SELinux, como selinux ou avc, juntamente com o nome de seu serviço ou aplicativo bloqueado, por exemplo: selinux samba.

O sistema de Auditoria Linux armazena entradas de log no arquivo /var/log/audit/audit.log por padrão. Para listar somente registros relacionados ao SELinux, utilize o comando ausearch com o parâmetro de tipo de mensagem definido para AVC e AVC_USER no mínimo, por exemplo:

# ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR

Uma entrada de negação da SELinux no arquivo de registro de auditoria pode parecer como se segue:

type=AVC msg=audit(1395177286.929:1638): avc:  denied  { read } for  pid=6591 comm="httpd" name="webpages" dev="0:37" ino=2112 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir

As partes mais importantes desta entrada são:

A entrada de registro anterior pode ser traduzida para:

SELinux denied the httpd process with PID 6591 and the httpd_t type to read from a directory with the nfs_t type.

A seguinte mensagem de negação SELinux ocorre quando o Servidor HTTP Apache tenta acessar um diretório etiquetado com um tipo para a suíte Samba:

type=AVC msg=audit(1226874073.147:96): avc:  denied  { getattr } for  pid=2465 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

Esta negação da SELinux pode ser traduzida para:

SELinux denied the httpd process with PID 2465 to access the /var/www/html/file1 file with the samba_share_t type, which is not accessible to processes running in the httpd_t domain unless configured otherwise.

A tecnologia de segurança multinível (MLS) classifica os dados usando os níveis de segurança da informação:

As regras que se aplicam ao fluxo de dados operam de níveis mais baixos para níveis mais altos, e nunca o contrário.

A MLS chama processos como subjects, e arquivos, dispositivos e outros componentes passivos do sistema como objects. Tanto os sujeitos quanto os objetos são rotulados com um nível de segurança, o que implica na liberação de um sujeito ou na classificação de um objeto.

A SELinux utiliza o modelo Bell-La Padula Model (BLP). Este modelo especifica como a informação pode fluir dentro do sistema com base em etiquetas fixadas a cada assunto e objeto. No BLP, os processos podem ler o mesmo nível de segurança ou níveis de segurança mais baixos, mas só podem escrever para o mesmo nível de segurança ou para um nível de segurança mais alto.

O sistema sempre combina as regras de acesso MLS com permissões de acesso convencionais (permissões de arquivo). Por exemplo, se um usuário com um nível de segurança de "Secret" usa o Controle de Acesso Discricionário (DAC) para bloquear o acesso a um arquivo por outros usuários, isto também bloqueia o acesso por usuários com um nível de segurança de "Top Secret". Uma autorização de segurança maior não permite automaticamente a navegação arbitrária em um sistema de arquivos.

Os usuários com autorizações de nível superior não adquirem automaticamente direitos administrativos em sistemas multiníveis. Embora eles possam ter acesso a todas as informações no computador, isto é diferente de ter direitos administrativos.

Use os seguintes passos para mudar a política SELinux de segurança direcionada para segurança multinível (MLS).

Uma política de segurança SELinux é uma coleção de regras SELinux. Uma política é um componente central do SELinux e é carregada no kernel pelas ferramentas de espaço de usuário do SELinux. O kernel reforça o uso de uma política SELinux para avaliar as solicitações de acesso no sistema. Por padrão, o SELinux nega todas as solicitações, exceto as solicitações que correspondem às regras especificadas na política carregada.

Cada regra da política SELinux descreve uma interação entre um processo e um recurso do sistema:

PERMITIR apache_processar apache_log:FILE READ;

Você pode ler esta regra de exemplo como The Apache process can read its logging file. Nesta regra, apache_process e apache_log são labels. Uma política de segurança SELinux atribui etiquetas aos processos e define as relações com os recursos do sistema. Desta forma, uma política mapeia as entidades do sistema operacional para a camada SELinux.

As etiquetas SELinux são armazenadas como atributos estendidos de sistemas de arquivo, tais como ext2. Você pode listá-los usando o utilitário getfattr ou um comando ls -Z, por exemplo:

$ ls -Z /etc/passwd
system_u:object_r:passwd_file_t:s0 /etc/passwd

Onde system_u é um usuário do SELinux, object_r é um exemplo do papel do SELinux, e passwd_file_t é um domínio do SELinux.

A política SELinux padrão fornecida pelos pacotes selinux-policy contém regras para aplicações e daemons que são partes do Red Hat Enterprise Linux 8 e são fornecidos por pacotes em seus repositórios. As aplicações não descritas em uma regra nesta política de distribuição não são confinadas pela SELinux. Para mudar isto, é necessário modificar a política usando um módulo de política, que contém definições e regras adicionais.

No Red Hat Enterprise Linux 8, você pode consultar a política SELinux instalada e gerar novos módulos de política usando a ferramenta sepolicy. Os scripts que sepolicy gera junto com os módulos de política sempre contêm um comando usando o utilitário restorecon. Este utilitário é uma ferramenta básica para corrigir problemas de etiquetagem em uma parte selecionada de um sistema de arquivo.

Este procedimento de exemplo fornece passos para confinar um simples daemon pela SELinux. Substitua o daemon por seu aplicativo personalizado e modifique a regra de exemplo de acordo com as exigências daquele aplicativo e sua política de segurança.

Para simplificar a criação de novas políticas SELinux para recipientes personalizados, a RHEL 8 fornece o utilitário udica. Você pode usar esta ferramenta para criar uma política baseada em uma inspeção do arquivo JavaScript Object Notation (JSON) do contêiner, que contém capacidades Linux, pontos de montagem e definições de portas. Consequentemente, a ferramenta combina regras geradas usando os resultados da inspeção com regras herdadas de um bloco específico de Linguagem Intermediária Comum (CIL) SELinux.

O processo de geração da política SELinux para um contêiner utilizando udica tem três partes principais:

Durante a fase de análise, udica procura por capacidades Linux, portas de rede e pontos de montagem.

Com base nos resultados, udica detecta quais capacidades Linux são requeridas pelo contêiner e cria uma regra SELinux que permite todas essas capacidades. Se o contêiner se liga a uma porta específica, udica utiliza bibliotecas de espaço de usuário SELinux para obter a etiqueta SELinux correta de uma porta que é utilizada pelo contêiner inspecionado.

Posteriormente, udica detecta quais diretórios são montados no espaço de nome do sistema de arquivos do contêiner a partir do host.

O recurso de herança em bloco da CIL permite que udica crie modelos da SELinux allow rules com foco em uma ação específica, por exemplo:

Estes modelos são chamados de blocos e a política final da SELinux é criada através da fusão dos blocos.

Para gerar uma política de segurança SELinux para um contêiner personalizado, siga as etapas deste procedimento.

As funções do sistema RHEL são uma coleção de funções e módulos possíveis que fornecem uma interface de configuração consistente para gerenciar remotamente vários sistemas RHEL. A função do sistema SELinux permite as seguintes ações:

A tabela a seguir fornece uma visão geral das variáveis de entrada disponíveis na função do sistema SELinux.

O exemplo de playbook /usr/share/doc/rhel-system-roles/selinux/example-selinux-playbook.yml, instalado pelo pacote rhel-system-roles, demonstra como definir a política direcionada no modo de aplicação. O playbook também aplica várias modificações de políticas locais e restaura contextos de arquivos no diretório /tmp/test_dir/.

Siga os passos para preparar e aplicar um livro de exercícios possível com suas configurações SELinux verificadas.

Use os seguintes passos para transferir suas configurações SELinux personalizadas e verificadas entre os sistemas baseados no RHEL 8.