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.

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.

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:

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.

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).

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.

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.

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.

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.

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á.

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.

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.

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.

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.

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.

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.