8.5. Segurança
fapolicyd
não impede mais as atualizações da RHEL
Quando uma atualização substitui o binário de uma aplicação em execução, o kernel modifica o caminho binário da aplicação na memória anexando o sufixo " (excluído). Anteriormente, o daemon da política de acesso a arquivos fapolicyd
tratava tais aplicações como não confiáveis, e as impedia de abrir e executar quaisquer outros arquivos. Como conseqüência, o sistema às vezes era incapaz de inicializar após a aplicação de atualizações.
Com o lançamento do RHBA-2020:5243 advisory, fapolicyd
ignora o sufixo no caminho binário para que o binário possa combinar com o banco de dados de confiança. Como resultado, fapolicyd
aplica as regras corretamente e o processo de atualização pode terminar.
(BZ#1897091)
openssl-pkcs11
não trava mais os dispositivos ao tentar entrar em múltiplos dispositivos
Anteriormente, o motor openssl-pkcs11
tentou entrar no primeiro resultado de uma busca usando o PKCS #11 URI fornecido e usou o PIN fornecido mesmo que o primeiro resultado não fosse o dispositivo pretendido e o PIN correspondesse a outro dispositivo. Estas tentativas de autenticação falhadas bloquearam o dispositivo.
openssl-pkcs11
agora tenta entrar em um dispositivo somente se o PKCS #11 URI fornecido corresponder somente a um único dispositivo. O motor agora falha intencionalmente caso a busca do PKCS #11 encontre mais de um dispositivo. Por esta razão, você deve fornecer um PKCS #11 URI que corresponda apenas a um único dispositivo quando usar o openssl-pkcs11
para fazer o login no dispositivo.
OpenSCAP varreduras offline usando rpmverifyfile
agora funcionam corretamente
Antes desta atualização, o scanner OpenSCAP não alterou corretamente o diretório de trabalho atual no modo offline, e a função fchdir
não foi chamada com os argumentos corretos na sonda OpenSCAP rpmverifyfile
. O scanner OpenSCAP foi corrigido para mudar corretamente o diretório de trabalho atual em modo offline, e a função fchdir
foi corrigida para usar os argumentos corretos no rpmverifyfile
. Como resultado, o conteúdo SCAP que contém o OVAL rpmverifyfile
pode ser usado pelo OpenSCAP para escanear sistemas de arquivos arbitrários.
(BZ#163636431)
httpd
agora começa corretamente se usar uma chave privada ECDSA sem correspondência de 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 esta razão, um dispositivo PKCS #11 armazena informações de chave pública em um objeto separado, seja ele um objeto de chave pública ou um objeto de certificado. OpenSSL esperava que a estrutura EVP_PKEY
fornecida por um motor para uma chave privada contivesse a informação da chave pública. Ao preencher a estrutura EVP_PKEY
a ser fornecida à OpenSSL, o mecanismo no pacote openssl-pkcs11
tentou buscar as informações da chave pública somente de objetos de chave pública correspondentes e ignorou os objetos certificados atuais.
Quando OpenSSL solicitou uma chave privada ECDSA do motor, a estrutura EVP_PKEY
fornecida não continha a informação da chave pública se a chave pública não estivesse presente no dispositivo PKCS #11, mesmo quando um certificado correspondente que continha a chave pública estivesse disponível. Como conseqüência, uma vez que o servidor web Apache httpd
chamou a função X509_check_private_key()
, que requer a chave pública, em seu processo de inicialização, o httpd
falhou em iniciar neste cenário. Este problema foi resolvido carregando a chave pública CE do certificado se o objeto chave pública não estiver disponível. Como resultado, o httpd
agora inicia corretamente quando as chaves ECDSA são armazenadas em um dispositivo PKCS #11.
as remediações das regras de Auditoria agora funcionamcorretamente
Anteriormente, o pacote de guia de segurança do scap
continha uma combinação de remediação e uma verificação que poderia 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 foram marcadas como falhadas
Conseqüentemente, durante o processo de instalação da RHEL, o escaneamento do sistema instalado relatou algumas regras de Auditoria como falhadas ou erradas.
Com esta atualização, as remediações foram corrigidas, e o escaneamento do sistema instalado com a política de segurança PCI-DSS não relata mais falsos positivos para as regras de Auditoria.
OpenSCAP agora fornece varredura offline de máquinas e recipientes virtuais
Anteriormente, a refatoração do codebase OpenSCAP fez com que certas sondas RPM falhassem na varredura de sistemas de arquivos VM e containers em modo off-line. Consequentemente, as seguintes ferramentas não podiam ser incluídas no pacote openscap-utils
: oscap-vm
e oscap-chroot
. Além disso, o pacote openscap-containers
foi completamente removido do RHEL 8. Com esta atualização, os problemas nas sondas foram resolvidos.
Como resultado, a RHEL 8 agora contém as ferramentas oscap-podman
, oscap-vm
e oscap-chroot
no pacote openscap-utils
.
(BZ#1618489)
OpenSCAP rpmverifypackage
agora funciona corretamente
Anteriormente, as chamadas ao sistema chdir
e chroot
eram chamadas duas vezes pela sonda rpmverifypackage
. Consequentemente, ocorreu um erro quando a sonda foi utilizada durante uma varredura OpenSCAP com conteúdo personalizado de Open Vulnerability and Assessment Language (OVAL). A sonda rpmverifypackage
foi fixada para utilizar corretamente as chamadas de sistema chdir
e chroot
. Como resultado, o rpmverifypackage
agora funciona corretamente.
(BZ#1646197)