6.5.4. Seguridad
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)
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.
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.
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)
Los permisos de archivo de /etc/passwd- no están alineados con el Benchmark 1.0.0 de CIS RHEL 8
Debido a un problema con el CIS Benchmark, la remediación de la regla SCAP que asegura los permisos en el archivo /etc/passwd- backup configura los permisos a 0644. Sin embargo, el CIS Red Hat Enterprise Linux 8 Benchmark 1.0.0 requiere permisos de archivo 0600 para ese archivo. Como consecuencia, los permisos de archivo de /etc/passwd- no están alineados con el benchmark después de la remediación.
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)
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.
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.
(BZ#1685470)
OpenSSL en modo FIPS sólo acepta parámetros D-H específicos
En el modo FIPS, los clientes de la capa de seguridad de transporte (TLS) que utilizan OpenSSL devuelven un error de valor dh incorrecto y abortan las conexiones TLS con servidores que utilizan parámetros generados manualmente. Esto se debe a que OpenSSL, cuando está configurado para trabajar de acuerdo con FIPS 140-2, sólo funciona con parámetros D-H que cumplen con el Apéndice D de NIST SP 800-56A rev3 (grupos 14, 15, 16, 17 y 18 definidos en RFC 3526 y con grupos definidos en RFC 7919). Además, los servidores que utilizan OpenSSL ignoran todos los demás parámetros y en su lugar seleccionan parámetros conocidos de tamaño similar. Para solucionar este problema, utilice sólo los grupos que cumplen con la normativa.
(BZ#1810911)
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)
el serviciosystemd no puede ejecutar comandos desde rutas arbitrarias
El servicio systemd no puede ejecutar comandos desde rutas arbitrarias /home/user/bin porque el paquete de políticas de SELinux no incluye ninguna regla de este tipo. En consecuencia, los servicios personalizados que se ejecutan en rutas que no son del sistema fallan y finalmente registran los mensajes de auditoría de denegación de Access Vector Cache (AVC) cuando SELinux deniega el acceso. Para solucionar este problema, realice una de las siguientes acciones:
Ejecute el comando utilizando un script shell con la opción
-c. Por ejemplo,bash -c command-
Ejecuta el comando desde una ruta común utilizando los directorios comunes
/bin,/sbin,/usr/sbin,/usr/local/biny/usr/local/sbin.
rpm_verify_permissions falla en el perfil CIS
La regla rpm_verify_permissions compara los permisos de los archivos con los permisos por defecto de los paquetes. Sin embargo, el perfil del Centro de Seguridad de Internet (CIS), que es proporcionado por los paquetes scap-security-guide, cambia algunos permisos de archivos para que sean más estrictos que los predeterminados. Como consecuencia, la verificación de ciertos archivos usando rpm_verify_permissions falla.
Para solucionar este problema, verifique manualmente que estos archivos tengan los siguientes permisos:
-
/etc/cron.d(0700) -
/etc/cron.hourly(0700) -
/etc/cron.monthly(0700) -
/etc/crontab(0600) -
/etc/cron.weekly(0700) -
/etc/cron.daily(0700)
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)
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.
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)
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, al seleccionar el grupo de paquetes Server with GUI durante la instalación de un sistema con perfiles OSPP o basados en OSPP, por ejemplo, Guía de Implementación Técnica de Seguridad (STIG), OpenSCAP muestra una advertencia de que el grupo de paquetes seleccionado no es compatible con la política de seguridad. 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.
No es posible la instalación con el Servidor con selecciones de software de GUI o Estación de Trabajo y perfil de seguridad CIS
El perfil de seguridad CIS no es compatible con las selecciones de software Servidor con GUI y Estación de Trabajo. En consecuencia, no es posible realizar una instalación de RHEL 8 con la selección de software Servidor con GUI y el perfil CIS. Un intento de instalación utilizando el perfil CIS y cualquiera de estas selecciones de software generará el mensaje de error:
el paquete xorg-x11-server-common ha sido añadido a la lista de paquetes excluidos, pero no puede ser eliminado de la selección de software actual sin romper la instalación.
Para solucionar el problema, no utilice el perfil de seguridad CIS con las selecciones de software Servidor con GUI o Estación de trabajo.
La corrección de las reglas relacionadas con el servicio durante las instalaciones de kickstart podría fallar
Durante una instalación kickstart, la utilidad OpenSCAP a veces muestra incorrectamente que no es necesaria una remediación del estado de habilitación o deshabilitación de servicios. En consecuencia, OpenSCAP podría establecer los servicios del sistema instalado en un estado no compatible. Como solución, puede escanear y remediar el sistema después de la instalación kickstart. Esto solucionará los problemas relacionados con los servicios.
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.
laspolíticas criptográficas permiten incorrectamente los cifrados de Camellia
Las políticas criptográficas de todo el sistema de RHEL 8 deberían deshabilitar los cifrados de Camellia en todos los niveles de políticas, como se indica en la documentación del producto. Sin embargo, el protocolo Kerberos habilita los cifrados por defecto.
Para solucionar el problema, aplique la subpolítica NO-CAMELLIA:
# update-crypto-policies --set DEFAULT:NO-CAMELLIA
En el comando anterior, sustituya DEFAULT por el nombre del nivel criptográfico si ha cambiado de DEFAULT previamente.
Como resultado, los cifrados de Camellia están correctamente desautorizados en todas las aplicaciones que utilizan políticas de cifrado en todo el sistema sólo cuando los desactiva a través de la solución.(BZ#1919155)
