11.4. Seguridad
La vigilancia de los ejecutables de auditoría en los enlaces simbólicos no funciona
La monitorización de archivos proporcionada por la opción -w no puede rastrear directamente una ruta. Tiene que resolver la ruta a un dispositivo y un inodo para hacer una comparación con el programa ejecutado. Un reloj que monitoriza un enlace simbólico ejecutable monitoriza el dispositivo y un inodo del propio enlace simbólico en lugar del programa ejecutado en memoria, que se encuentra a partir de la resolución del enlace simbólico. Incluso si la vigilancia resuelve el enlace simbólico para obtener el programa ejecutable resultante, la regla se dispara en cualquier binario de llamada múltiple llamado desde un enlace simbólico diferente. Esto hace que se inunden los registros con falsos positivos. En consecuencia, las vigilancias de auditoría de ejecutables en enlaces simbólicos no funcionan.
Para solucionar el problema, configure una vigilancia para la ruta resuelta del ejecutable del programa, y filtre los mensajes de registro resultantes utilizando el último componente listado en los campos comm= o proctitle=.
(BZ#1846345)
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)
SELinux impide que auditd detenga o apague el sistema
La política de SELinux no contiene una regla que permita al demonio de Auditoría iniciar una unidad systemd power_unit_file_t. En consecuencia, auditd no puede detener o apagar el sistema incluso cuando está configurado para hacerlo en casos como la falta de espacio en una partición de disco de registro.
Para solucionar este problema, cree un módulo de política SELinux personalizado. Como resultado, auditd puede detener o apagar el sistema correctamente sólo si aplica la solución.
los usuarios pueden ejecutar comandos sudo como usuarios bloqueados
En los sistemas donde los permisos sudoers están definidos con la palabra clave ALL, los usuarios con permisos sudo pueden ejecutar comandos sudo como usuarios cuyas cuentas están bloqueadas. En consecuencia, las cuentas bloqueadas y caducadas pueden seguir utilizándose para ejecutar comandos.
Para solucionar este problema, habilite la opción recién implementada runas_check_shell junto con la configuración adecuada de shells válidos en /etc/shells. Esto evita que los atacantes ejecuten comandos bajo cuentas del sistema como bin.
(BZ#1786990)
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.
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.
Libreswan no funciona correctamente con seccomp=enabled en todas las configuraciones
El conjunto de llamadas al sistema permitidas en la implementación del soporte SECCOMP de Libreswan no está actualmente completo. En consecuencia, cuando SECCOMP está habilitado en el archivo ipsec.conf, el filtrado de llamadas al sistema rechaza incluso las llamadas al sistema necesarias para el correcto funcionamiento del demonio pluto; el demonio es eliminado, y el servicio ipsec es reiniciado.
Para solucionar este problema, vuelva a poner la opción seccomp= en estado desactivado. El soporte de SECCOMP debe permanecer deshabilitado para ejecutar ipsec correctamente.
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.
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)
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)
GnuTLS falla al reanudar la sesión actual con el servidor NSS
Cuando se reanuda una sesión TLS (Transport Layer Security) 1.3, el cliente GnuTLS espera 60 milisegundos más un tiempo estimado de ida y vuelta para que el servidor envíe los datos de reanudación de la sesión. Si el servidor no envía los datos de reanudación en este tiempo, el cliente crea una nueva sesión en lugar de reanudar la sesión actual. Esto no tiene efectos adversos graves, salvo un impacto menor en el rendimiento de una negociación de sesión normal.
La utilidad oscap-ssh falla al escanear un sistema remoto con --sudo
Cuando se realiza un análisis del Protocolo de Automatización de Contenidos de Seguridad (SCAP) de un sistema remoto utilizando la herramienta oscap-ssh con la opción --sudo, la herramienta oscap del sistema remoto guarda los archivos de resultados del análisis y los archivos de informe en un directorio temporal como usuario root. Si la configuración de umask en la máquina remota ha sido cambiada, oscap-ssh podría no tener acceso a estos archivos. Para solucionar este problema, modifique la herramienta oscap-ssh como se describe en esta solución "oscap-ssh --sudo" no recupera los archivos de resultados con el error "scp: ...: Permiso denegado". Como resultado, oscap guarda los archivos como el usuario de destino, y oscap-ssh accede a los archivos normalmente.
OpenSCAP produce falsos positivos causados por la eliminación de las líneas en blanco de las cadenas multilínea YAML
Cuando OpenSCAP genera remedios de Ansible a partir de un flujo de datos, elimina las líneas en blanco de las cadenas multilíneas de YAML. Dado que algunas reparaciones de Ansible contienen contenido literal de archivos de configuración, la eliminación de líneas en blanco afecta a las reparaciones correspondientes. Esto hace que la utilidad openscap falle las comprobaciones correspondientes de Open Vulnerability and Assessment Language (OVAL), aunque las líneas en blanco no tengan ningún efecto. Para solucionar este problema, compruebe las descripciones de las reglas y omita los resultados del análisis que fallaron debido a la falta de líneas en blanco. Como alternativa, utilice remedios de Bash en lugar de remedios de Ansible, porque los remedios de Bash no producen estos resultados falsos positivos.
Los perfiles basados en OSPP son incompatibles con los grupos de paquetes GUI.
Los paquetes deGNOME instalados por el grupo de paquetes Server with GUI requieren el paquete nfs-utils que no es compatible con el Perfil de Protección del Sistema Operativo (OSPP). Como consecuencia, si se selecciona el grupo de paquetes Server with GUI durante la instalación de un sistema con perfiles OSPP o basados en OSPP, por ejemplo, la Guía de Implementación Técnica de Seguridad (STIG), se aborta la instalación. Si el perfil basado en OSPP se aplica después de la instalación, el sistema no puede arrancar. Para solucionar este problema, no instale el grupo de paquetes Server with GUI ni ningún otro grupo que instale GUI cuando utilice el perfil OSPP y los perfiles basados en OSPP. Si utiliza los grupos de paquetes Server o Minimal Install en su lugar, el sistema se instala sin problemas y funciona correctamente.
El sistema RHEL8 con el grupo de paquetes Server with GUI no puede ser remediado usando el perfil e8
El uso del complemento OpenSCAP Anaconda para endurecer el sistema en el grupo de paquetes Server With GUI con perfiles que seleccionan reglas del grupo Verify Integrity with RPM requiere una cantidad extrema de RAM en el sistema. Este problema es causado por el escáner de OpenSCAP; para más detalles vea El escaneo de un gran número de archivos con OpenSCAP hace que los sistemas se queden sin memoria. Como consecuencia, el endurecimiento del sistema utilizando el perfil RHEL8 Essential Eight (e8) no tiene éxito. Para solucionar este problema, elija un grupo de paquetes más pequeño, por ejemplo, Server, e instale los paquetes adicionales que necesite después de la instalación. Como resultado, el sistema tendrá un número menor de paquetes, el escaneo requerirá menos memoria y, por lo tanto, el sistema puede ser endurecido automáticamente.
(BZ#1816199)
El escaneo de un gran número de archivos con OpenSCAP hace que los sistemas se queden sin memoria
El escáner OpenSCAP almacena todos los resultados recogidos en la memoria hasta que finaliza el escaneo. Como consecuencia, el sistema podría quedarse sin memoria en sistemas con poca RAM al escanear un gran número de archivos, por ejemplo de los grandes grupos de paquetes Server with GUI y Workstation. Para solucionar este problema, utilice grupos de paquetes más pequeños, por ejemplo, Server y Minimal Install en sistemas con poca memoria RAM. Si necesita utilizar grupos de paquetes grandes, puede probar si su sistema tiene suficiente memoria en un entorno virtual o de ensayo. Como alternativa, puede adaptar el perfil de exploración para deseleccionar las reglas que implican la recursión en todo el sistema de archivos /:
-
rpm_verify_hashes -
rpm_verify_permissions -
rpm_verify_ownership -
archivo_permisos_no_autorizados_mundo_de_escritura -
no_files_unowned_by_user -
dir_perms_world_writable_system_owned -
file_permissions_unauthorized_suid -
file_permissions_unauthorized_sgid -
file_permissions_unroupowned -
dir_perms_world_writable_sticky_bits
Esto evitará que el escaneo de OpenSCAP haga que el sistema se quede sin memoria.
