6.7.6. Seguridad
redhat-support-tool no funciona con la política criptográfica FUTURE
Debido a que una clave criptográfica utilizada por un certificado en la API del Portal del Cliente no cumple los requisitos de la política criptográfica de todo el sistema FUTURE, la utilidad redhat-support-tool no funciona con este nivel de política por el momento. Para solucionar este problema, utilice la política criptográfica DEFAULT al conectarse a la API del Portal de Clientes.
SELINUX=disabled en /etc/selinux/config no funciona correctamente
Desactivar SELinux usando la opción SELINUX=disabled en el archivo /etc/selinux/config resulta en un proceso en el que el kernel arranca con SELinux activado y cambia a modo desactivado más tarde en el proceso de arranque. Esto podría causar fugas de memoria y condiciones de carrera y, en consecuencia, también pánicos en el kernel. Para solucionar este problema, desactive SELinux añadiendo el parámetro selinux=0 a la línea de comandos del kernel, tal y como se describe en la sección Cambio de los modos de SELinux en el arranque del título Uso de SELinux, si su escenario realmente requiere desactivar SELinux por completo.
(JIRA:RHELPLAN-34199)
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)
udica procesa contenedores UBI 8 sólo cuando se inicia con --env container=podman
Los contenedores Red Hat Universal Base Image 8 (UBI 8) establecen la variable de entorno del contenedor con el valor oci en lugar del valor podman. Esto evita que la herramienta udica analice un archivo de notación de objetos JavaScript (JSON) del contenedor.
Para solucionar este problema, inicie un contenedor UBI 8 utilizando un comando podman con el parámetro --env container=podman. Como resultado, udica puede generar una política SELinux para un contenedor UBI 8 sólo cuando se utiliza la solución descrita.
La eliminación del paquete rpm-plugin-selinux conlleva la eliminación de todos los paquetes selinux-policy del sistema
Eliminar el paquete rpm-plugin-selinux deshabilita SELinux en la máquina. También elimina todos los paquetes selinux-policy del sistema. La instalación repetida del paquete rpm-plugin-selinux instala entonces la política SELinux-policy-minimum, incluso si la política selinux-policy-targeted estaba previamente presente en el sistema. Sin embargo, la instalación repetida no actualiza el archivo de configuración de SELinux para tener en cuenta el cambio de política. Como consecuencia, SELinux está deshabilitado incluso al reinstalar el paquete rpm-plugin-selinux.
Para solucionar este problema:
-
Introduzca el comando
umount /sys/fs/selinux/. -
Instale manualmente el paquete
selinux-policy-targetedque falta. -
Edite el archivo
/etc/selinux/configpara que la política sea igual aSELINUX=enforcing. -
Introduzca el comando
load_policy -i.
Como resultado, SELinux está habilitado y ejecuta la misma política que antes.
(BZ#1641631)
SELinux impide que systemd-journal-gatewayd llame a newfstat() en archivos de memoria compartida creados por corosync
La política de SELinux no contiene una regla que permita al demonio systemd-journal-gatewayd acceder a los archivos creados por el servicio corosync. Como consecuencia, SELinux niega a systemd-journal-gatewayd la posibilidad de llamar a la función newfstat() en los archivos de memoria compartida creados por corosync.
Para solucionar este problema, cree un módulo de política local con una regla de permiso que permita el escenario descrito. Consulte la página man de audit2allow(1 ) para obtener más información sobre la generación de la política de SELinux allow y las reglas de dontaudit. Como resultado de la solución anterior, systemd-journal-gatewayd puede llamar a la función en archivos de memoria compartida creados por corosync con SELinux en modo de aplicación.
(BZ#1746398)
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)
Errores deparámetros no conocidos en la salida de rsyslog con config.enabled
En la salida de rsyslog, se produce un error inesperado en los errores de procesamiento de la configuración utilizando la directiva config.enabled. Como consecuencia, se muestran errores de parámetros no conocidos mientras se utiliza la directiva config . enabled excepto en las sentencias include().
Para solucionar este problema, establezca config.enabled=on o utilice las sentencias include().
(BZ#1659383)
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.
Las conexiones a servidores con firmas SHA-1 no funcionan con GnuTLS
Las firmas SHA-1 en los certificados son rechazadas por la biblioteca de comunicaciones seguras GnuTLS como inseguras. En consecuencia, las aplicaciones que utilizan GnuTLS como backend TLS no pueden establecer una conexión TLS con pares que ofrezcan tales certificados. Este comportamiento es inconsistente con otras bibliotecas criptográficas del sistema. Para solucionar este problema, actualice el servidor para utilizar certificados firmados con SHA-256 o un hash más fuerte, o cambie a la política LEGACY.
(BZ#1628553)
TLS 1.3 no funciona en NSS en modo FIPS
TLS 1.3 no es compatible con los sistemas que funcionan en modo FIPS. Como resultado, las conexiones que requieren TLS 1.3 para la interoperabilidad no funcionan en un sistema que funciona en modo FIPS.
Para habilitar las conexiones, desactive el modo FIPS del sistema o habilite el soporte para TLS 1.2 en el peer.
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.
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.
OpenSSL genera una extensión status_request malformada en el mensaje CertificateRequest en TLS 1.3
Los servidores OpenSSL envían una extensión status_request malformada en el mensaje CertificateRequest si el soporte para la extensión status_request y la autenticación basada en el certificado del cliente están activados. En este caso, OpenSSL no interopera con las implementaciones que cumplen con el protocolo RFC 8446. Como resultado, los clientes que verifican correctamente las extensiones en el mensaje 'CertificateRequest' abortan las conexiones con el servidor OpenSSL. Para solucionar este problema, desactive la compatibilidad con el protocolo TLS 1.3 en ambos lados de la conexión o desactive la compatibilidad con status_request en el servidor OpenSSL. Esto evitará que el servidor envíe mensajes malformados.
ssh-keyscan no puede recuperar las claves RSA de los servidores en modo FIPS
El algoritmo SHA-1 está desactivado para las firmas RSA en el modo FIPS, lo que impide que la utilidad ssh-keyscan recupere las claves RSA de los servidores que operan en ese modo.
Para solucionar este problema, utilice claves ECDSA en su lugar, o recupere las claves localmente desde el archivo /etc/ssh/ssh_host_rsa_key.pub en el servidor.
scap-security-guide PCI-DSS remediación de las normas de auditoría no funciona correctamente
El paquete scap-security-guide contiene una combinación de remediación y una comprobación que puede resultar en 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 marcan como fallidas
En consecuencia, durante el proceso de instalación de RHEL 8.1, el escaneo del sistema instalado reporta algunas reglas de Auditoría como fallidas o con errores.
Para solucionar este problema, siga las instrucciones de la solución de RHEL-8.1 para remediar y analizar con el artículo de la base de conocimientos scap-security-guide PCI-DSS profile.
Algunos conjuntos de reglas interdependientes en SSG pueden fallar
La remediación de las reglas de la Guía de Seguridad SCAP (SSG) en un benchmark puede fallar debido al orden indefinido de las reglas y sus dependencias. Si dos o más reglas deben ejecutarse en un orden determinado, por ejemplo, cuando una regla instala un componente y otra regla configura el mismo componente, pueden ejecutarse en el orden incorrecto y la corrección informa de un error. Para solucionar este problema, ejecute la corrección dos veces, y la segunda ejecución corrige las reglas dependientes.
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.
Para solucionar este problema, consulte el artículo Uso de OpenSCAP para escanear contenedores en R HEL 8 en el Portal del Cliente. En consecuencia, por el momento solo se puede utilizar una forma limitada y sin soporte para el escaneo de seguridad y cumplimiento de los contenedores en RHEL 8.
(BZ#1642373)
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)
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)
El complemento OSCAP Anaconda no instala todos los paquetes en modo texto
El complemento OSCAP Anaconda no puede modificar la lista de paquetes seleccionados para su instalación por el instalador del sistema si la instalación se ejecuta en modo texto. En consecuencia, cuando se especifica un perfil de política de seguridad mediante Kickstart y la instalación se ejecuta en modo texto, cualquier paquete adicional requerido por la política de seguridad no se instala durante la instalación.
Para solucionar este problema, ejecute la instalación en modo gráfico o especifique todos los paquetes que requiere el perfil de la política de seguridad en la sección %packages de su archivo Kickstart.
Como resultado, los paquetes requeridos por el perfil de política de seguridad no se instalan durante la instalación de RHEL sin una de las soluciones descritas, y el sistema instalado no cumple con el perfil de política de seguridad dado.
El complemento OSCAP Anaconda no maneja correctamente los perfiles personalizados
El plugin OSCAP Anaconda Addon no maneja adecuadamente los perfiles de seguridad con personalizaciones en archivos separados. En consecuencia, el perfil personalizado no está disponible en la instalación gráfica de RHEL aunque lo especifique correctamente en la sección Kickstart correspondiente.
Para solucionar este problema, siga las instrucciones del artículo de la base de conocimientos Creación de un único flujo de datos SCAP a partir de un DS original y un archivo de adaptación. Como resultado de esta solución, puede utilizar un perfil SCAP personalizado en la instalación gráfica de RHEL.
(BZ#1691305)
