5.5.15. Segurança
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)
a libssh não cumpre com a política de criptografia do sistema
A biblioteca libssh não segue as configurações de política criptográfica de todo o sistema. Como conseqüência, o conjunto de algoritmos suportados não é alterado quando o administrador muda o nível de políticas criptográficas usando o comando update-crypto-policies.
Para contornar este problema, o conjunto de algoritmos anunciados precisa ser definido individualmente por cada aplicação que utiliza a libssh. Como resultado, quando o sistema é definido ao nível da política LEGACY ou FUTURE, as aplicações que utilizam a libssh se comportam de forma inconsistente quando comparadas ao OpenSSH.
(BZ#1646563)
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.
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)
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)
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.
(BZ#1665082)
OpenSCAP rpmverifyfile não funciona
O scanner OpenSCAP não muda corretamente o diretório de trabalho atual no modo off-line, e a função fchdir não é chamada com os argumentos corretos na sonda OpenSCAP rpmverifyfile. Conseqüentemente, o escaneamento de sistemas de arquivos arbitrários usando o comando oscap-chroot falha se o rpmverifyfile_test for usado em um conteúdo SCAP. Como resultado, o oscap-chroot aborta no cenário descrito.
(BZ#163636431)
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)
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. Como resultado, o oscap-docker ou um utilitário equivalente para segurança e verificação de conformidade de containers não está disponível no RHEL 8 no momento.
(BZ#1642373)
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.
O Apache httpd não inicia se usar uma chave privada RSA armazenada em um dispositivo PKCS#11 e um certificado RSA-PSS
O padrão PKCS#11 não diferencia entre objetos chave RSA e RSA-PSS e usa o tipo CKKK_RSA para ambos. Entretanto, OpenSSL usa tipos diferentes para chaves RSA e RSA-PSS. Como consequência, o motor openssl-pkcs11 não pode determinar que tipo deve ser fornecido ao OpenSSL para objetos chave PKCS#11 RSA. Atualmente, o mecanismo define o tipo de chave como chaves RSA para todos os objetos PKCS#11 CKKK_RSA. Quando OpenSSL compara os tipos de uma chave pública RSA-PSS obtida do certificado com o tipo contido em um objeto de chave privada RSA fornecido pelo motor, conclui que os tipos são diferentes. Portanto, o certificado e a chave privada não correspondem. A verificação realizada na função X509_check_private_key() OpenSSL retorna um erro neste cenário. O servidor web httpd chama esta função em seu processo de inicialização para verificar se o certificado e a chave fornecida coincidem. Como esta verificação sempre falha para um certificado contendo uma chave pública RSA-PSS e uma chave privada RSA armazenada no módulo PKCS#11, o httpd falha ao começar a usar esta configuração. Não há nenhuma solução disponível para este problema.
httpd não inicia se usar uma chave privada ECDSA sem a correspondente chave pública armazenada em um dispositivo PKCS#11
Ao contrário das chaves da RSA, as chaves privadas da ECDSA não contêm necessariamente informações de chave pública. Neste caso, você não pode obter a chave pública de uma chave privada ECDSA. Por este motivo, um dispositivo PKCS#11 armazena informações de chave pública em um objeto separado, seja um objeto de chave pública ou um objeto de certificado. A OpenSSL espera que a estrutura EVP_PKEY fornecida por um motor para uma chave privada contenha as informações da chave pública. Ao preencher a estrutura EVP_PKEY a ser fornecida à OpenSSL, o mecanismo no pacote openssl-pkcs11 tenta buscar as informações da chave pública apenas de objetos de chave pública correspondentes e ignora os objetos certificados atuais.
Quando OpenSSL solicita uma chave privada ECDSA do motor, a estrutura EVP_PKEY fornecida não contém as informações da chave pública se a chave pública não estiver presente no dispositivo PKCS#11, mesmo quando um certificado correspondente que contenha a chave pública estiver disponível. Como conseqüência, como o servidor web Apache httpd chama a função X509_check_private_key(), que requer a chave pública, em seu processo de inicialização, o httpd não inicia neste cenário. Para contornar o problema, armazenar tanto a chave privada quanto a pública no dispositivo PKCS#11 ao usar chaves ECDSA. Como resultado, o httpd inicia corretamente quando as chaves ECDSA são armazenadas no dispositivo PKCS#11.
OpenSSH não lida com PKCS #11 URIs para chaves com etiquetas inadequadas corretamente
A suíte OpenSSH pode identificar os pares de chaves por uma etiqueta. A etiqueta pode diferir em chaves privadas e públicas armazenadas em um cartão inteligente. Consequentemente, especificar o PKCS #11 URIs com a parte do objeto (etiqueta da chave) pode impedir que o OpenSSH encontre objetos apropriados no PKCS #11.
Para contornar este problema, especifique PKCS #11 URIs sem a parte do objeto. Como resultado, o OpenSSH é capaz de usar chaves em cartões inteligentes referenciados usando o PKCS #11 URIs.
(BZ#1671262)
A saída de iptables-ebtables não é 100ompatível com ebtables
No RHEL 8, o comando ebtables é fornecido pelo pacote iptables-ebtables, que contém uma reimplementação da ferramenta baseada em nftables. Esta ferramenta tem uma base de código diferente, e sua saída se desvia em aspectos que são negligenciáveis ou escolhas deliberadas de projeto.
Conseqüentemente, ao migrar seus scripts analisando algumas saídas de ebtables, ajuste os scripts para refletir o seguinte:
- A formatação do endereço MAC foi alterada para ser fixada em comprimento. Quando necessário, os valores de bytes individuais contêm um zero inicial para manter o formato de dois caracteres por octeto.
- A formatação dos prefixos IPv6 foi alterada para estar em conformidade com a RFC 4291. A parte móvel após o caractere de barra não contém mais uma máscara de rede no formato de endereço IPv6, mas um comprimento de prefixo. Esta alteração se aplica somente a máscaras válidas (contíguas à esquerda), enquanto outras ainda são impressas na formatação antiga.
curve25519-sha256 não é suportado por padrão no OpenSSH
O algoritmo de troca de chaves SSH curva25519-sha256 está faltando nas configurações de políticas criptográficas de todo o sistema para o cliente e servidor OpenSSH, apesar de estar em conformidade com o nível padrão de políticas. Como conseqüência, se um cliente ou um servidor usar a curva25519-sha256 e este algoritmo não for suportado pelo host, a conexão pode falhar.
Para contornar este problema, você pode anular manualmente a configuração das políticas de criptografia de todo o sistema modificando os arquivos openssh.config e opensshshserver.config no diretório /etc/crypto-policies/back-ends/back-ends para o cliente e servidor OpenSSH. Note que esta configuração é sobrescrita com cada mudança das políticas de criptografia de todo o sistema. Veja a página de manual update-crypto-policies(8) para mais informações.
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.
As conexões SSH com sistemas hospedados em VMware não funcionam
A versão atual da suíte OpenSSH introduz uma mudança da bandeira padrão de Qualidade de Serviço IP (IPQoS) nos pacotes SSH, que não é tratada corretamente pela plataforma de virtualização VMware. Conseqüentemente, não é possível estabelecer uma conexão SSH com sistemas na VMware.
Para contornar este problema, inclua o IPQoS=throughput no arquivo ssh_config. Como resultado, as conexões SSH com sistemas hospedados em VMware-hosted funcionam corretamente.
Veja o artigo RHEL 8 rodando na Estação de Trabalho VMWare incapaz de se conectar via SSH a outros hosts da solução Knowledgebase para mais informações.
(BZ#1651763)
