5.5.15. Seguridad
libselinux-python sólo está disponible a través de su módulo
El paquete libselinux-python sólo contiene bindings de Python 2 para el desarrollo de aplicaciones SELinux y se utiliza por compatibilidad con versiones anteriores. Por esta razón, libselinux-python ya no está disponible en los repositorios por defecto de RHEL 8 a través del comando dnf install libselinux-python.
Para solucionar este problema, active los módulos libselinux-python y python27, e instale el paquete libselinux-python y sus dependencias con los siguientes comandos:
# dnf module enable libselinux-python # dnf install libselinux-python
Alternativamente, instale libselinux-python utilizando su perfil de instalación con un solo comando:
# dnf module install libselinux-python:2.8/common
Como resultado, puede instalar libselinux-python utilizando el módulo correspondiente.
(BZ#1666328)
libssh no cumple con la política criptográfica de todo el sistema
La biblioteca libssh no sigue la configuración de políticas criptográficas de todo el sistema. Como consecuencia, el conjunto de algoritmos soportados no se modifica cuando el administrador cambia el nivel de las políticas criptográficas utilizando el comando update-crypto-policies.
Para solucionar este problema, el conjunto de algoritmos anunciados debe ser configurado individualmente por cada aplicación que utilice libssh. Como resultado, cuando el sistema está configurado en el nivel de política LEGACY o FUTURE, las aplicaciones que utilizan libssh se comportan de forma inconsistente cuando se comparan con OpenSSH.
(BZ#1646563)
Algunas cadenas de prioridad de rsyslog no funcionan correctamente
La compatibilidad con la cadena de prioridad GnuTLS para imtcp que permite un control detallado de la codificación no es completa. En consecuencia, las siguientes cadenas de prioridad no funcionan correctamente en rsyslog:
NINGUNO: VERS-ALL:-VERS-TLS1.3: MAC-ALL: DHE-RSA: AES-256-GCM: SIGN-RSA-SHA384: COMP-ALL: GROUP-ALL
Para evitar este problema, utilice sólo cadenas de prioridad que funcionen correctamente:
NINGUNO: VERS-ALL:-VERS-TLS1.3: MAC-ALL: ECDHE-RSA: AES-128-CBC: SIGN-RSA-SHA1: COMP-ALL: GROUP-ALL
En consecuencia, las configuraciones actuales deben limitarse a las cadenas que funcionan correctamente.
Efectos negativos de la configuración de registro por defecto en el rendimiento
La configuración del entorno de registro por defecto puede consumir 4 GB de memoria o incluso más y los ajustes de los valores de límite de velocidad son complejos cuando systemd-journald se ejecuta con rsyslog.
Consulte el artículo de la base de conocimientos Efectos negativos de la configuración de registro por defecto de RHEL en el rendimiento y sus mitigaciones para obtener más información.
(JIRA:RHELPLAN-10431)
OpenSCAP rpmverifypackage no funciona correctamente
Las llamadas al sistema chdir y chroot son llamadas dos veces por la sonda rpmverifypackage. En consecuencia, se produce un error cuando la sonda se utiliza durante un análisis de OpenSCAP con contenido personalizado de Open Vulnerability and Assessment Language (OVAL).
Para solucionar este problema, no utilice la prueba OVAL rpmverifypackage_test en su contenido o utilice sólo el contenido del paquete scap-security-guide donde no se utiliza rpmverifypackage_test.
(BZ#1646197)
SCAP Workbench no genera correcciones basadas en resultados a partir de perfiles adaptados
El siguiente error se produce al intentar generar roles de corrección basados en resultados a partir de un perfil personalizado utilizando la herramienta SCAP Workbench:
Error al generar el rol de remediación .../remediación.sh: El código de salida de oscap era 1: [salida truncada]
Para solucionar este problema, utilice el comando oscap con la opción --tailoring-file.
(BZ#1640715)
Kickstart utiliza org_fedora_oscap en lugar de com_redhat_oscap en RHEL 8
El Kickstart hace referencia al complemento Anaconda del Protocolo de Automatización de Contenidos de Seguridad Abierta (OSCAP) como org_fedora_oscap en lugar de com_redhat_oscap, lo que podría causar confusión. Esto se hace para mantener la compatibilidad con Red Hat Enterprise Linux 7.
(BZ#1665082)
OpenSCAP rpmverifyfile no funciona
El escáner OpenSCAP no cambia correctamente el directorio de trabajo actual en modo offline, y la función fchdir no se llama con los argumentos correctos en la sonda OpenSCAP rpmverifyfile. En consecuencia, el escaneo de sistemas de archivos arbitrarios usando el comando oscap-chroot falla si rpmverifyfile_test es usado en un contenido SCAP. Como resultado, oscap-chroot aborta en el escenario descrito.
(BZ#1636431)
OpenSCAP no proporciona escaneo fuera de línea de máquinas virtuales y contenedores
La refactorización de la base de código de OpenSCAP provocó que ciertas sondas RPM no pudieran escanear los sistemas de archivos de las máquinas virtuales y los contenedores en modo offline. Por esta razón, se eliminaron las siguientes herramientas del paquete openscap-utils: oscap-vm y oscap-chroot. También se eliminó por completo el paquete openscap-containers.
(BZ#1618489)
No se dispone de una utilidad para escanear la seguridad y el cumplimiento de los contenedores
En Red Hat Enterprise Linux 7, la utilidad oscap-docker se puede utilizar para escanear contenedores Docker basados en tecnologías Atomic. En Red Hat Enterprise Linux 8, los comandos OpenSCAP relacionados con Docker y Atomic no están disponibles. Como resultado, oscap-docker o una utilidad equivalente para el escaneo de seguridad y cumplimiento de los contenedores no está disponible en RHEL 8 por el momento.
(BZ#1642373)
La biblioteca TLS de OpenSSL no detecta si el token PKCS#11 admite la creación de firmas RSA sin procesar o RSA-PSS
El protocolo TLS-1.3 requiere el soporte de la firma RSA-PSS. Si el token PKCS#11 no es compatible con las firmas RSA o RSA-PSS en bruto, las aplicaciones de servidor que utilizan la biblioteca TLS de OpenSSL no podrán trabajar con la clave RSA si la tiene el token PKCS#11. Como resultado, la comunicación TLS fallará.
Para solucionar este problema, configure el servidor o el cliente para utilizar la versión TLS-1.2 como la versión de protocolo TLS más alta disponible.
Apache httpd no se inicia si utiliza una clave privada RSA almacenada en un dispositivo PKCS#11 y un certificado RSA-PSS
El estándar PKCS#11 no distingue entre objetos de clave RSA y RSA-PSS y utiliza el tipo CKK_RSA para ambos. Sin embargo, OpenSSL utiliza tipos diferentes para las claves RSA y RSA-PSS. Como consecuencia, el motor openssl-pkcs11 no puede determinar qué tipo debe proporcionarse a OpenSSL para los objetos de clave PKCS#11 RSA. Actualmente, el motor establece el tipo de clave como claves RSA para todos los objetos PKCS#11 CKK_RSA. Cuando OpenSSL compara los tipos de una clave pública RSA-PSS obtenida del certificado con el tipo contenido en un objeto de clave privada RSA proporcionado por el motor, concluye que los tipos son diferentes. Por tanto, el certificado y la clave privada no coinciden. La comprobación realizada en la función X509_check_private_key() de OpenSSL devuelve un error en este escenario. El servidor web httpd llama a esta función en su proceso de inicio para comprobar si el certificado y la clave proporcionados coinciden. Dado que esta comprobación siempre falla para un certificado que contenga una clave pública RSA-PSS y una clave privada RSA almacenada en el módulo PKCS#11, httpd no puede iniciarse utilizando esta configuración. No hay ninguna solución disponible para este problema.
httpd no se inicia si utiliza una clave privada ECDSA sin la correspondiente 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. Cuando se rellena la estructura EVP_PKEY que se proporciona a OpenSSL, el motor del paquete openssl-pkcs11 intenta obtener la información de la clave pública sólo de los objetos de clave pública que coinciden e ignora los objetos de certificado presentes.
Cuando OpenSSL solicita una clave privada ECDSA al motor, la estructura EVP_PKEY proporcionada no contiene la información de la clave pública si ésta no está presente en el dispositivo PKCS#11, incluso cuando se dispone de un certificado coincidente que contiene la clave pública. Como consecuencia, dado que el servidor web Apache httpd llama a la función X509_check_private_key(), que requiere la clave pública, en su proceso de arranque, httpd no se inicia en este escenario. Para solucionar el problema, almacene tanto la clave privada como la pública en el dispositivo PKCS#11 cuando utilice claves ECDSA. Como resultado, httpd se inicia correctamente cuando las claves ECDSA se almacenan en el dispositivo PKCS#11.
OpenSSH no maneja correctamente los URIs PKCS #11 para claves con etiquetas que no coinciden
La suite OpenSSH puede identificar los pares de claves mediante una etiqueta. La etiqueta puede ser diferente en las claves privadas y públicas almacenadas en una tarjeta inteligente. En consecuencia, especificar URIs PKCS #11 con la parte del objeto (etiqueta de la clave) puede impedir que OpenSSH encuentre los objetos apropiados en PKCS #11.
Para solucionar este problema, especifique los URIs PKCS #11 sin la parte del objeto. Como resultado, OpenSSH es capaz de usar claves en tarjetas inteligentes referenciadas usando URIs PKCS #11.
(BZ#1671262)
La salida de iptables-ebtables no es 100 ompatible con ebtables
En RHEL 8, el comando ebtables es proporcionado por el paquete iptables-ebtables, que contiene una reimplementación de la herramienta basada en nftables. Esta herramienta tiene una base de código diferente, y su salida se desvía en aspectos, que son insignificantes o elecciones de diseño deliberadas.
En consecuencia, al migrar sus scripts que analizan la salida de algunos ebtables, ajuste los scripts para que reflejen lo siguiente:
- El formato de la dirección MAC se ha modificado para que tenga una longitud fija. Cuando es necesario, los valores de los bytes individuales contienen un cero inicial para mantener el formato de dos caracteres por octeto.
- El formato de los prefijos IPv6 se ha modificado para ajustarse al RFC 4291. La parte final después del carácter de barra ya no contiene una máscara de red en el formato de dirección IPv6, sino una longitud de prefijo. Este cambio se aplica sólo a las máscaras válidas (contiguas a la izquierda), mientras que las demás se siguen imprimiendo con el formato antiguo.
curve25519-sha256 no está soportado por defecto en OpenSSH
El algoritmo de intercambio de claves SSH curve25519-sha256 falta en las configuraciones de las políticas criptográficas de todo el sistema para el cliente y el servidor OpenSSH, aunque sea compatible con el nivel de política por defecto. Como consecuencia, si un cliente o un servidor utiliza curve25519-sha256 y este algoritmo no es soportado por el host, la conexión podría fallar.
Para solucionar este problema, puede anular manualmente la configuración de las políticas criptográficas de todo el sistema modificando los archivos openssh.config y opensshserver.config en el directorio /etc/crypto-policies/back-ends/ para el cliente y el servidor OpenSSH. Tenga en cuenta que esta configuración se sobrescribe con cada cambio de las políticas criptográficas de todo el sistema. Consulte la página de manual update-crypto-policies(8) para obtener más información.
OpenSSL maneja incorrectamente los tokens PKCS #11 que no admiten firmas RSA o RSA-PSS en bruto
La biblioteca OpenSSL no detecta las capacidades relacionadas con las claves de los tokens PKCS #11. En consecuencia, el establecimiento de una conexión TLS falla cuando se crea una firma con un token que no admite firmas RSA o RSA-PSS en bruto.
Para solucionar el problema, añada las siguientes líneas después de la línea .include al final de la sección crypto_policy en el archivo /etc/pki/tls/openssl.cnf:
SignatureAlgorithms = RSA+SHA256:RSA+SHA512:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA512:ECDSA+SHA384 MaxProtocol = TLSv1.2
Como resultado, se puede establecer una conexión TLS en el escenario descrito.
Las conexiones SSH con sistemas alojados en VMware no funcionan
La versión actual de la suite OpenSSH introduce un cambio de las banderas de calidad de servicio IP (IPQoS) por defecto en los paquetes SSH, que no es manejado correctamente por la plataforma de virtualización VMware. En consecuencia, no es posible establecer una conexión SSH con sistemas en VMware.
Para solucionar este problema, incluya IPQoS=throughput en el archivo ssh_config. Como resultado, las conexiones SSH con sistemas alojados en VMware funcionan correctamente.
Consulte el artículo de la solución de la base de conocimientos RHEL 8 que se ejecuta en VMWare Workstation y que no puede conectarse mediante SSH a otros hosts para obtener más información.
(BZ#1651763)
