6.2.4. Seguridad

SELinux ya no impide que systemd-journal-gatewayd llame a newfstat() en los archivos /dev/shm/ utilizados por corosync

Anteriormente, la política de SELinux no contenía una regla que permitiera al demonio systemd-journal-gatewayd acceder a los archivos creados por el servicio corosync. Como consecuencia, SELinux denegaba a systemd-journal-gatewayd la llamada a la función newfstat() en los archivos de memoria compartida creados por corosync. Con esta actualización, SELinux ya no impide que systemd-journal-gatewayd llame a newfstat () en los archivos de memoria compartida creados por corosync.

Libreswan ahora funciona con seccomp=enabled en todas las configuraciones

Antes de esta actualización, el conjunto de llamadas al sistema permitidas en la implementación de soporte de Libreswan SECCOMP no coincidía con el nuevo uso de las bibliotecas RHEL. En consecuencia, cuando SECCOMP estaba habilitado en el archivo ipsec.conf, el filtrado de llamadas al sistema rechazaba incluso las llamadas al sistema necesarias para el correcto funcionamiento del demonio pluto; el demonio era eliminado y el servicio ipsec se reiniciaba. Con esta actualización, todas las nuevas llamadas al sistema requeridas han sido permitidas, y Libreswan ahora funciona con la opción seccomp=enabled correctamente.

SELinux ya no impide que auditd detenga o apague el sistema

Anteriormente, la política de SELinux no contenía una regla que permitiera al demonio de auditoría iniciar una unidad systemd power_unit_file_t. En consecuencia, auditd no podía detener o apagar el sistema incluso cuando estaba configurado para hacerlo en casos como la falta de espacio en una partición de disco de registro.

IPTABLES_SAVE_ON_STOP ahora funciona correctamente

Anteriormente, la función IPTABLES_SAVE_ON_STOP del servicio iptables no funcionaba porque los archivos con contenido de tablas IP guardadas recibían un contexto SELinux incorrecto. Esto impedía que el script de iptables cambiara los permisos, y posteriormente el script no podía guardar los cambios. Esta actualización define un contexto adecuado para los archivos iptables.save e ip6tables.save, y crea una regla de transición de nombre de archivo. Como consecuencia, la función IPTABLES_SAVE_ON_STOP del servicio iptables funciona correctamente.

Las bases de datos NSCD pueden ahora utilizar diferentes modos

Los dominios en el atributo nsswitch_domain tienen acceso a los servicios de Name Service Cache Daemon (NSCD). Cada base de datos NSCD se configura en el archivo nscd.conf, y la propiedad shared determina si la base de datos utiliza el modo de memoria compartida o de socket. Anteriormente, todas las bases de datos NSCD tenían que utilizar el mismo modo de acceso, dependiendo del valor booleano nscd_use_shm. Ahora, el uso del socket de flujo Unix está siempre permitido, y por lo tanto diferentes bases de datos NSCD pueden utilizar diferentes modos.

La utilidad oscap-ssh ahora funciona correctamente 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. Anteriormente, si se cambiaba la configuración de umask en la máquina remota, oscap-ssh podía no tener acceso a estos archivos. Esta actualización soluciona el problema, y como resultado, oscap guarda los archivos como el usuario de destino, y oscap-ssh accede a los archivos normalmente.

OpenSCAP ahora maneja correctamente los sistemas de archivos remotos

Anteriormente, OpenSCAP no detectaba de forma fiable los sistemas de archivos remotos si su especificación de montaje no empezaba con dos barras. Como consecuencia, OpenSCAP manejaba algunos sistemas de archivos basados en la red como locales. Con esta actualización, OpenSCAP identifica los sistemas de archivos utilizando el tipo de sistema de archivos en lugar de la especificación de montaje. Como resultado, OpenSCAP ahora maneja correctamente los sistemas de archivos remotos.

OpenSCAP ya no elimina las líneas en blanco de las cadenas multilíneas YAML

Anteriormente, OpenSCAP eliminaba las líneas en blanco de las cadenas multilínea YAML dentro de las correcciones de Ansible generadas a partir de un flujo de datos. Esto afectaba a las correcciones de Ansible y hacía que la utilidad openscap fallara en las comprobaciones correspondientes de Open Vulnerability and Assessment Language (OVAL), produciendo resultados falsos positivos. El problema se ha solucionado y, como resultado, openscap ya no elimina las líneas en blanco de las cadenas multilínea YAML.

OpenSCAP ahora puede escanear sistemas con un gran número de archivos sin quedarse sin memoria

Anteriormente, al escanear sistemas con poca memoria RAM y un gran número de archivos, el escáner OpenSCAP a veces hacía que el sistema se quedara sin memoria. Con esta actualización, se ha mejorado la gestión de la memoria del escáner OpenSCAP. Como resultado, el escáner ya no se queda sin memoria en sistemas con poca RAM cuando se escanea un gran número de archivos, por ejemplo, grupos de paquetes Servidor con GUI y Estación de Trabajo.

config.enabled ahora controla las declaraciones correctamente

Anteriormente, el rsyslog evaluaba incorrectamente la directiva config.enabled durante el procesamiento de la configuración de una sentencia. Como consecuencia, los errores de parámetro no conocido se mostraban para cada sentencia excepto para la de include(). Con esta actualización, la configuración se procesa para todas las sentencias por igual. Como resultado, config.enabled ahora desactiva o activa correctamente las sentencias sin mostrar ningún error.

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.

El perfil e8 se puede utilizar ahora para remediar los sistemas RHEL 8 con Server con GUI

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 ya no requiere una cantidad extrema de RAM en el sistema. La causa de este problema era el escáner OpenSCAP. Para obtener más detalles, consulte El análisis de un gran número de archivos con OpenSCAP hace que los sistemas se queden sin memoria. Como consecuencia, el endurecimiento del sistema mediante el perfil RHEL 8 Essential Eight (e8) ahora también funciona con Server With GUI.