8.5. Seguridad
fapolicyd ya no impide las actualizaciones de RHEL
Cuando una actualización sustituye el binario de una aplicación en ejecución, el kernel modifica la ruta del binario de la aplicación en la memoria añadiendo el sufijo " (eliminado)". Anteriormente, el demonio de la política de acceso a archivos fapolicyd trataba dichas aplicaciones como no confiables, y les impedía abrir y ejecutar cualquier otro archivo. Como consecuencia, el sistema a veces no podía arrancar después de aplicar las actualizaciones.
Con la publicación del aviso RHBA-2020:5243, fapolicyd ignora el sufijo en la ruta del binario para que éste pueda coincidir con la base de datos de confianza. Como resultado, fapolicyd aplica las reglas correctamente y el proceso de actualización puede finalizar.
(BZ#1897091)
openssl-pkcs11 ya no bloquea los dispositivos al intentar iniciar sesión en varios dispositivos
Anteriormente, el motor openssl-pkcs11 intentaba iniciar sesión en el primer resultado de una búsqueda utilizando el URI PKCS #11 proporcionado y utilizaba el PIN proporcionado incluso si el primer resultado no era el dispositivo previsto y el PIN coincidía con otro dispositivo. Estos intentos fallidos de autenticación bloqueaban el dispositivo.
openssl-pkcs11 ahora intenta entrar en un dispositivo sólo si el URI PKCS #11 proporcionado coincide con un único dispositivo. El motor ahora falla intencionalmente en caso de que la búsqueda de PKCS #11 encuentre más de un dispositivo. Por esta razón, debe proporcionar un URI PKCS #11 que coincida con un solo dispositivo cuando utilice openssl-pkcs11 para iniciar sesión en el dispositivo.
OpenSCAP los escaneos fuera de línea utilizando rpmverifyfile ahora funcionan correctamente
Antes de esta actualización, el explorador OpenSCAP no cambiaba correctamente el directorio de trabajo actual en modo fuera de línea, y la función fchdir no se llamaba con los argumentos correctos en la sonda rpmverifyfile de OpenSCAP. El escáner OpenSCAP ha sido corregido para cambiar correctamente el directorio de trabajo actual en modo offline, y la función fchdir ha sido corregida para usar los argumentos correctos en rpmverifyfile. Como resultado, el contenido SCAP que contiene OVAL rpmverifyfile puede ser usado por OpenSCAP para escanear sistemas de archivos arbitrarios.
(BZ#1636431)
httpd ahora se inicia correctamente si se utiliza una clave privada ECDSA sin que coincida con la clave pública almacenada en un dispositivo PKCS #11
A diferencia de las claves RSA, las claves privadas ECDSA no contienen necesariamente información sobre la clave pública. En este caso, no se puede obtener la clave pública de una clave privada ECDSA. Por esta razón, un dispositivo PKCS #11 almacena la información de la clave pública en un objeto separado, ya sea un objeto de clave pública o un objeto de certificado. OpenSSL espera que la estructura EVP_PKEY proporcionada por un motor para una clave privada contenga la información de la clave pública. Al rellenar la estructura EVP_PKEY que se proporcionaba a OpenSSL, el motor del paquete openssl-pkcs11 intentaba obtener la información de la clave pública sólo de los objetos de clave pública que coincidían e ignoraba los objetos de certificado presentes.
Cuando OpenSSL solicitaba una clave privada ECDSA al motor, la estructura EVP_PKEY proporcionada no contenía la información de la clave pública si ésta no estaba presente en el dispositivo PKCS #11, incluso cuando se disponía de un certificado coincidente que contenía la clave pública. Como consecuencia, dado que el servidor web Apache httpd llamaba a la función X509_check_private_key(), que requiere la clave pública, en su proceso de arranque, httpd fallaba al iniciarse en este escenario. Este problema se ha resuelto cargando la clave pública de la CE desde el certificado si el objeto de clave pública no está disponible. Como resultado, httpd ahora se inicia correctamente cuando las claves ECDSA se almacenan en un dispositivo PKCS #11.
scap-security-guide Las correcciones PCI-DSS de las reglas de auditoría ahora funcionan correctamente
Anteriormente, el paquete scap-security-guide contenía una combinación de remediación y una comprobación que podía dar lugar a uno de los siguientes escenarios:
- corrección incorrecta de las normas de auditoría
- evaluación de escaneo que contiene falsos positivos donde las reglas aprobadas se marcaron como fallidas
En consecuencia, durante el proceso de instalación de RHEL, el escaneo del sistema instalado reportó algunas reglas de Auditoría como fallidas o con errores.
Con esta actualización, se han corregido las correcciones y el escaneo del sistema instalado con la política de seguridad PCI-DSS ya no reporta falsos positivos para las reglas de Auditoría.
OpenSCAP ahora ofrece escaneo sin conexión de máquinas virtuales y contenedores
Anteriormente, la refactorización de la base de código OpenSCAP provocaba que ciertas sondas RPM no pudieran escanear los sistemas de archivos de las máquinas virtuales y los contenedores en modo offline. En consecuencia, las siguientes herramientas no podían incluirse en el paquete openscap-utils: oscap-vm y oscap-chroot. Además, el paquete openscap-containers fue eliminado por completo de RHEL 8. Con esta actualización se han solucionado los problemas de las sondas.
Como resultado, RHEL 8 contiene ahora las herramientas oscap-podman, oscap-vm y oscap-chroot en el paquete openscap-utils.
(BZ#1618489)
OpenSCAP rpmverifypackage ahora funciona correctamente
Anteriormente, las llamadas al sistema chdir y chroot eran llamadas dos veces por la sonda rpmverifypackage. En consecuencia, se producía un error cuando la sonda se utilizaba durante un análisis de OpenSCAP con contenido personalizado de Open Vulnerability and Assessment Language (OVAL). La sonda rpmverifypackage ha sido corregida para utilizar correctamente las llamadas al sistema chdir y chroot. Como resultado, rpmverifypackage ahora funciona correctamente.
(BZ#1646197)
