11.4. Segurança

Relógios executáveis de auditoria em links simbólicos não funcionam

O monitoramento de arquivos fornecido pela opção -w não pode rastrear diretamente um caminho. Ele tem que resolver o caminho para um dispositivo e um inode para fazer uma comparação com o programa executado. Um relógio monitorando um symlink executável monitora o dispositivo e um inode do próprio symlink ao invés do programa executado em memória, que é encontrado a partir da resolução do symlink. Mesmo que o relógio resolva o link simbólico para obter o programa executável resultante, a regra aciona em qualquer binário de chamadas múltiplas chamado de um link simbólico diferente. Isto resulta em registros de inundação com falsos positivos. Conseqüentemente, os relógios executáveis de auditoria em links simbólicos não funcionam.

SELINUX=desabilitado em /etc/selinux/config não funciona corretamente

Desabilitar o SELinux utilizando a opção SELINUX=disabled no /etc/selinux/config resulta em um processo no qual o kernel inicia com o SELinux habilitado e muda para o modo desabilitado mais tarde no processo de inicialização. Isto pode causar vazamentos de memória e condições de corrida e, conseqüentemente, também pânico no kernel.

libselinux-python só está disponível através de seu módulo

O pacote libselinux-python contém apenas ligas Python 2 para o desenvolvimento de aplicações SELinux e é usado para compatibilidade retroativa. Por esta razão, libselinux-python não está mais disponível nos repositórios padrão RHEL 8 através do comando dnf install libselinux-python.

udica processa recipientes UBI 8 somente quando iniciada com --env container=podman

Os recipientes Red Hat Universal Base Image 8 (UBI 8) definem a variável de ambiente do recipiente para o valor oci ao invés do valor podman. Isto impede que a ferramenta udica analise um arquivo JavaScript Object Notation (JSON) de um recipiente.

A remoção da embalagem rpm-plugin-selinux leva à remoção de todas as embalagens de selinux-policy do sistema

A remoção do pacote rpm-plugin-selinux desabilita a SELinux na máquina. Também remove todas as embalagens de selinux-policy do sistema. Instalação repetida do pacote rpm-plugin-selinux, então instala a política SELinux-policy-minimum SELinux, mesmo que a política selinux-policy-target estivesse previamente presente no sistema. Entretanto, a instalação repetida não atualiza o arquivo de configuração do SELinux para contabilizar a mudança na política. Como conseqüência, o SELinux é desativado mesmo após a reinstalação do pacote rpm-plugin-selinux.

SELinux impede que o systemd-journal-gatewayd chame newfstat() em arquivos de memória compartilhada criados pela corosync

A política SELinux não contém uma regra que permita que o daemon do sistema-journal-gatewayd tenha acesso aos arquivos criados pelo serviço corosync. Como consequência, o SELinux nega a função systemd-journal-gatewayd para chamar a função newfstat() nos arquivos de memória compartilhada criados pela corosync.

SELinux impede que a auditoria interrompa ou desligue o sistema

A política SELinux não contém uma regra que permita que o daemon de Auditoria inicie uma unidade do sistema power_unit_file_t. Conseqüentemente, a Auditd não pode parar ou desligar o sistema mesmo quando configurada para fazê-lo em casos como o de não sobrar espaço em uma partição de disco de registro.

os usuários podem executar comandos sudo como usuários bloqueados

Em sistemas onde as permissões dos sudoers são definidas com a palavra-chave ALL, os usuários sudo com permissões podem executar comandos sudo como usuários cujas contas estão bloqueadas. Consequentemente, as contas bloqueadas e expiradas ainda podem ser usadas para executar comandos.

Efeitos negativos da configuração padrão de registro sobre o desempenho

A configuração padrão do ambiente de registro pode consumir 4 GB de memória ou até mais e os ajustes dos valores limite de taxa são complexos quando o sistema-journald está rodando com o rsyslog.

Parâmetro errosnão conhecidos na saída do rsyslog com config.enabled

Na saída do rsyslog, ocorre um erro inesperado no processamento da configuração usando a diretiva config.enabled. Como conseqüência, os erros não conhecidos são exibidos durante o uso da diretiva config.enabled, exceto para as instruções include().

Certas cordas prioritárias rsyslog não funcionam corretamente

O suporte para a cadeia de prioridade GnuTLS para imtcp que permite um controle fino sobre a criptografia não está completo. Conseqüentemente, as seguintes cadeias de prioridade não funcionam corretamente no rsyslog:

As conexões a servidores com assinaturas SHA-1 não funcionam com GnuTLS

As assinaturas SHA-1 nos certificados são rejeitadas pela biblioteca de comunicações seguras GnuTLS como inseguras. Consequentemente, as aplicações que usam GnuTLS como backend TLS não podem estabelecer uma conexão TLS com os colegas que oferecem tais certificados. Este comportamento é inconsistente com outras bibliotecas criptográficas do sistema. Para contornar este problema, atualize o servidor para usar certificados assinados com SHA-256 ou hash mais forte, ou mude para a política LEGACY.

TLS 1.3 não funciona em NSS no modo FIPS

O TLS 1.3 não é suportado em sistemas que funcionam no modo FIPS. Como resultado, as conexões que requerem o TLS 1.3 para interoperabilidade não funcionam em um sistema que trabalha em modo FIPS.

OpenSSL manipula incorretamente as fichas PKCS #11 que não suportam assinaturas RSA ou RSA-PSS brutas

A biblioteca OpenSSL não detecta as capacidades relacionadas às chaves de fichas PKCS #11. Conseqüentemente, o estabelecimento de uma conexão TLS falha quando uma assinatura é criada com um token que não suporta assinaturas RSA ou RSA-PSS brutas.

OpenSSL gera uma extensão de status_request malformado na mensagem CertificateRequest no TLS 1.3

Os servidores OpenSSL enviam uma extensão mal-formada status_request na mensagem CertificateRequest se o suporte para a extensão status_request e autenticação baseada no certificado do cliente estiverem habilitados. Nesse caso, o OpenSSL não interopera com implementações que estejam em conformidade com o protocolo RFC 8446. Como resultado, os clientes que verificam corretamente as extensões na mensagem CertificateRequest abortam as conexões com o servidor OpenSSL. Para contornar este problema, desabilite o suporte para o protocolo TLS 1.3 em ambos os lados da conexão ou desabilite o suporte para status_request no servidor OpenSSL. Isto evitará que o servidor envie mensagens mal-formadas.

o ssh-keyscan não pode recuperar chaves RSA de servidores em modo FIPS

O algoritmo SHA-1 é desativado para assinaturas RSA no modo FIPS, o que impede que o utilitário ssh-keyscan recupere chaves RSA de servidores que operam nesse modo.

Libreswan não funciona corretamente com seccomp=enabled em todas as configurações

O conjunto de syscalls permitidos na implementação do suporte de Libreswan SECCOMP não está atualmente completo. Consequentemente, quando o SECCOMP é habilitado no arquivo ipsec.conf, a filtragem de chamadas do syscall rejeita até mesmo as chamadas necessárias para o bom funcionamento do daemon pluto; o daemon é morto e o serviço ipsec é reiniciado.

Certos conjuntos de regras interdependentes no SSG podem falhar

A remediação das regras do Guia de Segurança SCAP (SSG) em um padrão de referência pode falhar devido à ordenação indefinida das regras e suas dependências. Se duas ou mais regras precisam ser executadas em uma determinada ordem, por exemplo, quando uma regra instala um componente e outra regra configura o mesmo componente, elas podem ser executadas na ordem errada e a remediação informa um erro. Para contornar este problema, execute a correção duas vezes e a segunda execução corrige as regras dependentes.

SCAP Workbench não gera remediações baseadas em resultados a partir de perfis personalizados

O seguinte erro ocorre quando se tenta gerar funções de remediação baseadas em resultados a partir de um perfil personalizado usando a ferramenta SCAP Workbench:

Kickstart usa org_fedora_oscap em vez de com_redhat_oscap no RHEL 8

O Kickstart faz referência ao Protocolo de Automação de Conteúdo de Segurança Aberta (OSCAP) Anaconda add-on como org_fedora_oscap em vez de com_redhat_oscap, o que pode causar confusão. Isto é feito para preservar a retrocompatibilidade com o Red Hat Enterprise Linux 7.

OSCAP Anaconda Addon não instala todos os pacotes em modo texto

O plugin OSCAP Anaconda Addon não pode modificar a lista de pacotes selecionados para instalação pelo instalador do sistema se a instalação estiver rodando em modo texto. Conseqüentemente, quando um perfil de política de segurança é especificado usando Kickstart e a instalação está rodando em modo texto, quaisquer pacotes adicionais exigidos pela política de segurança não são instalados durante a instalação.

OSCAP Anaconda Addon não lida corretamente com perfis personalizados

O plug-in OSCAP Anaconda Addon não lida adequadamente com perfis de segurança com personalizações em arquivos separados. Conseqüentemente, o perfil personalizado não está disponível na instalação gráfica RHEL, mesmo quando você o especifica corretamente na seção Kickstart correspondente.

GnuTLS falha em retomar a sessão atual com o servidor NSS

Ao retomar uma sessão TLS (Transport Layer Security) 1,3, o cliente GnuTLS espera 60 milissegundos mais um tempo estimado de ida e volta para o servidor enviar os dados de retomada da sessão. Se o servidor não enviar os dados de retomada dentro deste tempo, o cliente cria uma nova sessão em vez de retomar a sessão atual. Isto não causa efeitos adversos sérios, exceto por um pequeno impacto de desempenho em uma negociação de sessão regular.

O utilitário oscap-ssh falha ao digitalizar um sistema remoto com --sudo

Ao realizar um scan do Protocolo de Automação de Conteúdo de Segurança (SCAP) de um sistema remoto usando a ferramenta oscap-ssh com a opção --sudo, a ferramenta oscap no sistema remoto salva os arquivos de resultados do scan e informa os arquivos em um diretório temporário como usuário root. Se as configurações umask na máquina remota tiverem sido alteradas, o oscap-ssh pode não ter acesso a estes arquivos. Para contornar este problema, modificar a ferramenta oscap-ssh, como descrito nesta solução. O "oscap-ssh --sudo" não consegue recuperar os arquivos de resultados com o "scp: Erro "Permissão negada". Como resultado, o oscap salva os arquivos como usuário alvo, e o oscap-ssh acessa os arquivos normalmente.

OpenSCAP produz falsos positivos causados pela remoção de linhas em branco das cordas multi-linhas da YAML

Quando o OpenSCAP gera remediações possíveis a partir de um fluxo de dados, ele remove linhas em branco das cordas multi-linhas da YAML. Como algumas remediações possíveis contêm conteúdo de arquivo de configuração literal, a remoção de linhas em branco afeta as remediações correspondentes. Isto faz com que o utilitário openscap falhe as correspondentes verificações de Vulnerabilidade Aberta e Linguagem de Avaliação (OVAL), mesmo que as linhas em branco não tenham qualquer efeito. Para contornar este problema, verifique as descrições das regras e pule os resultados da varredura que falharam por falta de linhas em branco. Alternativamente, use remediações Bash em vez de Remediações Ansíveis, porque as remediações Bash não produzem estes resultados falsos positivos.

Os perfis baseados em OSPP são incompatíveis com os grupos de pacotes GUI.

Os pacotesGNOME instalados pelo grupo de pacotes Server with GUI requerem o pacote nfs-utils que não esteja em conformidade com o Perfil de Proteção do Sistema Operacional (OSPP). Como conseqüência, a seleção do grupo de pacotes Server with GUI durante a instalação de um sistema com perfis baseados em OSPP ou OSPP, por exemplo, Guia de Implementação Técnica de Segurança (STIG), aborta a instalação. Se o perfil baseado em OSPP for aplicado após a instalação, o sistema não é inicializável. Para contornar este problema, não instale o grupo de pacotes Server with GUI ou qualquer outro grupo que instale a GUI ao usar o perfil baseado em OSPP e perfis baseados em OSPP. Ao utilizar os grupos de pacotes Server ou Minimal Install, o sistema se instala sem problemas e funciona corretamente.

O sistema RHEL8 com o grupo de pacotes Server with GUI não pode ser remediado usando o perfil do e8

O uso do OpenSCAP Anaconda Add-on para endurecer o sistema no grupo de pacotes Server With GUI com perfis que selecionam regras do grupo Verify Integrity with RPM requer uma quantidade extrema de RAM no sistema. Este problema é causado pelo scanner do OpenSCAP; para mais detalhes, veja Digitalizando grandes números de arquivos com o OpenSCAP faz com que os sistemas fiquem sem memória. Como conseqüência, o endurecimento do sistema usando o perfil RHEL8 Essential Eight (e8) não é bem sucedido. Para contornar este problema, escolha um grupo menor de pacotes, por exemplo, Servidor, e instale pacotes adicionais necessários após a instalação. Como resultado, o sistema terá um número menor de pacotes, a varredura exigirá menos memória e, portanto, o sistema pode ser endurecido automaticamente.

A digitalização de grandes números de arquivos com OpenSCAP faz com que os sistemas fiquem sem memória

O scanner OpenSCAP armazena todos os resultados coletados na memória até que a varredura termine. Como conseqüência, o sistema pode ficar sem memória em sistemas com pouca memória RAM ao digitalizar um grande número de arquivos, por exemplo, dos grandes grupos de pacotes Server with GUI e Workstation. Para contornar este problema, utilize grupos de pacotes menores, por exemplo, Server e Minimal Install em sistemas com pouca memória RAM. Se você precisar usar grandes grupos de pacotes, você pode testar se seu sistema tem memória suficiente em um ambiente virtual ou de encenação. Alternativamente, você pode adaptar o perfil de escaneamento para desmarcar as regras que envolvem recorrência sobre todo o sistema / de arquivos: