6.7.6. Segurança
aferramenta de apoio aos adesivos não funciona com a política de criptografia do FUTURO
Como uma chave criptográfica utilizada por um certificado no API do Portal do Cliente não atende aos requisitos da política de criptografia do FUTURO em todo o sistema, o utilitário de suporte de adesivos não funciona com este nível de política no momento. Para contornar este problema, utilize a política de criptografia DEFAULT enquanto se conecta ao API do Portal do Cliente.
SELINUX=desabilitado em /etc/selinux/config não funciona corretamente
A desativação do SELinux utilizando a opção SELINUX=desabilitado 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. Para contornar este problema, desative o SELinux adicionando o parâmetro selinux=0 à linha de comando do kernel, conforme descrito na seção Mudando os modos SELinux no momento do boot da seção Usando o título SELinux se seu cenário realmente precisar desabilitar completamente o SELinux.
(JIRA:RHELPLAN-34199)
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.
Para contornar este problema, habilite os módulos libselinux-python e python27, e instale o pacote libselinux-python e suas dependências com os seguintes comandos:
# dnf module enable libselinux-python # dnf install libselinux-python
Alternativamente, instale libselinux-python usando seu perfil de instalação com um único comando:
# módulo dnf instalar libselinux-python:2.8/comum
Como resultado, você pode instalar libselinux-python usando o respectivo módulo.
(BZ#1666328)
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.
Para contornar este problema, inicie um container UBI 8 usando um comando podman com o parâmetro --env container=podman. Como resultado, a udica pode gerar uma política SELinux para um contêiner UBI 8 somente quando você utiliza o workaround descrito.
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.
Trabalhar em torno deste problema:
-
Digite o comando
umount /sys/fs/selinux/. -
Instalar manualmente o pacote
de selinuxque faltava. -
Edite o arquivo
/etc/selinux/configpara que a política seja igual aSELINUX=enforcing. -
Digite o comando
load_policy -i.
Como resultado, a SELinux está habilitada e executando a mesma política que antes.
(BZ#1641631)
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.
Para contornar este problema, crie um módulo de política local com uma regra de permissão que possibilite o cenário descrito. Consulte a página de manual audit2allow(1 ) para mais informações sobre como gerar a política SELinux allow e dontaudit regras. Como resultado do trabalho anterior, o systemd-journal-gatewayd pode chamar a função em arquivos de memória compartilhada criados pela corosync com o SELinux em modo de aplicação.
(BZ#1746398)
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.
Veja os efeitos negativos da configuração de registro padrão da RHEL sobre o desempenho e suas mitigações Artigo da Base de Conhecimento para mais informações.
(JIRA:RHELPLAN-10431)
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().
Para contornar este problema, defina config.enabled=on ou use as declarações ().
(BZ#1659383)
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:
NENHUMA: VERS-ALL:-VERS-TLS1.3: MAC-ALL: DHE-RSA: AES-256-GCM: SIGN-RSA-SHA384: COMP-ALL: GROUP-ALL
Para contornar este problema, use apenas cordas de prioridade que funcionem corretamente:
NENHUMA: VERS-ALL:-VERS-TLS1.3: MAC-ALL: ECDHE-RSA: AES-128-CBC: SIGN-RSA-SHA1: COMP-ALL: GROUP-ALL
Como resultado, as configurações atuais devem ser limitadas às cordas que funcionam corretamente.
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.
(BZ#1628553)
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.
Para ativar as conexões, desabilite o modo FIPS do sistema ou habilite o suporte para TLS 1.2 no par.
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.
Para contornar o problema, adicione as seguintes linhas após a linha .include no final da seção crypto_policy no arquivo /etc/pki/tls/openssl.cnf:
SignatureAlgorithms = RSA+SHA256:RSA+SHA512:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA512:ECDSA+SHA384 MaxProtocol = TLSv1.2
Como resultado, uma conexão TLS pode ser estabelecida no cenário descrito.
A biblioteca OpenSSL TLS não detecta se a ficha PKCS#11 suporta a criação de assinaturas RSA ou RSA-PSS brutas
O protocolo TLS-1.3 requer o suporte para a assinatura do RSA-PSS. Se o token PKCS#11 não suportar assinaturas RSA ou RSA-PSS brutas, as aplicações servidoras que usam a biblioteca OpenSSL TLS não funcionarão com a chave RSA se ela estiver na posse do token PKCS#11. Como resultado, a comunicação TLS falhará.
Para contornar este problema, configure o servidor ou cliente para usar a versão TLS-1.2 como a versão mais alta do protocolo TLS disponível.
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.
Para contornar este problema, use chaves ECDSA, ou recupere as chaves localmente do arquivo /etc/ssh/ssh_host_rsa_chave.pub no servidor.
a correção das regras de Auditoria pelo PCI-DSS não funciona corretamente
O pacote de guia de segurança de scap contém uma combinação de remediação e uma verificação que pode resultar em um dos seguintes cenários:
- remediação incorreta das regras de Auditoria
- avaliação de varredura contendo falsos positivos onde as regras aprovadas são marcadas como falhadas
Conseqüentemente, durante o processo de instalação do RHEL 8.1, a varredura do sistema instalado relata algumas regras de Auditoria como falhadas ou erradas.
Para contornar este problema, siga as instruções do RHEL-8.1 para remediação e escaneamento com o artigo da Base de Conhecimento PCI-DSS sobre o perfil de segurança da scap - guia PCI-DSS.
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.
Um serviço de segurança e verificação de conformidade de contêineres não está disponível
No Red Hat Enterprise Linux 7, o utilitário oscap-docker pode ser usado para escaneamento de containers Docker baseado em tecnologias atômicas. No Red Hat Enterprise Linux 8, os comandos Docker- e Atomic relacionados a OpenSCAP não estão disponíveis.
Para contornar este problema, consulte o artigo Usando OpenSCAP para escaneamento de recipientes no RHEL 8 no Portal do Cliente. Como resultado, você pode usar apenas uma forma não suportada e limitada para segurança e verificação de conformidade dos contêineres no RHEL 8 no momento.
(BZ#1642373)
OpenSCAP não fornece escaneamento offline de máquinas e recipientes virtuais
A refatoração do OpenSCAP codebase fez com que certas sondas RPM falhassem na varredura de VM e sistemas de arquivos de containers em modo off-line. Por esse motivo, as seguintes ferramentas foram removidas do pacote openscap-utils: oscap-vm e oscap-chroot. Além disso, o pacote openscap-containers foi completamente removido.
(BZ#1618489)
OpenSCAP rpmverifypackage não funciona corretamente
As chamadas ao sistema chdir e chroot são chamadas duas vezes pela sonda rpmverifypackage. Conseqüentemente, ocorre um erro quando a sonda é utilizada durante uma varredura OpenSCAP com conteúdo personalizado de Open Vulnerability and Assessment Language (OVAL).
Para contornar este problema, não use o teste rpmverifypackage_test OVAL em seu conteúdo ou use somente o conteúdo do pacote scap-security-guide onde o rpmverifypackage_test não é usado.
(BZ#1646197)
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:
Erro gerando papel de remediação .../remediação.sh: Código de saída da oscap foi 1: [saída truncada]
Para contornar este problema, use o comando oscap com a opção --tailoring-file.
(BZ#1640715)
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.
Para contornar este problema, execute a instalação em modo gráfico ou especifique todos os pacotes que são exigidos pelo perfil da política de segurança na seção %packages em seu arquivo Kickstart.
Como resultado, os pacotes que são exigidos pelo perfil de política de segurança não são instalados durante a instalação da RHEL sem uma das soluções descritas, e o sistema instalado não está de acordo com o perfil de política de segurança dado.
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.
Para contornar este problema, siga as instruções na seção Criação de um único fluxo de dados SCAP a partir de um DS original e de um artigo de base de conhecimento de arquivo de personalização. Como resultado deste trabalho, você pode usar um perfil SCAP personalizado na instalação gráfica RHEL.
(BZ#1691305)
