Gestionar la Seguridad de SELinux en RHEL: Guía Práctica

Introducción

En este laboratorio, obtendrá experiencia práctica en la gestión de la seguridad SELinux en RHEL. Aprenderá a cambiar los modos de aplicación de SELinux, tanto temporal como permanentemente, y a configurar Apache con contextos de archivos SELinux personalizados. El laboratorio también cubre el ajuste de la política SELinux para los directorios de inicio de usuario utilizando booleanos y proporciona pasos prácticos para la solución de problemas y la resolución de denegaciones de SELinux para servidores web Apache y contenido web personalizado.

Cambiar el Modo de Aplicación de SELinux

En este paso, aprenderá a gestionar los modos de SELinux, tanto temporal como permanentemente. SELinux (Security-Enhanced Linux) es un mecanismo de seguridad que proporciona control de acceso obligatorio (MAC) para el kernel de Linux. Define los derechos de acceso para procesos, archivos y otros recursos del sistema.

SELinux opera en tres modos principales:

Enforcing (Aplicación): Se aplica la política de SELinux. Los accesos denegados por la política se bloquean y se registran. Este es el modo predeterminado y más seguro.
Permissive (Permisivo): No se aplica la política de SELinux. Los accesos denegados por la política se registran pero no se bloquean. Este modo es útil para la solución de problemas y la prueba de nuevas políticas.
Disabled (Deshabilitado): SELinux está desactivado. No se carga ni se aplica ninguna política. Este modo generalmente no se recomienda para sistemas de producción.

Practicará el cambio del modo de SELinux utilizando herramientas de línea de comandos y modificando archivos de configuración.

Primero, comprobemos el modo de aplicación de SELinux actual.

Comprobar el modo de aplicación de SELinux actual.

Puede utilizar el comando getenforce para ver rápidamente el modo de SELinux actual.
```
getenforce
```
Debería ver Enforcing como salida, lo que indica que SELinux está actualmente aplicando sus políticas.
```
Enforcing
```
Cambiar el modo de SELinux a permissive temporalmente.

El comando setenforce le permite cambiar el modo de SELinux en tiempo de ejecución. Un valor de 0 establece el modo en permissive, y 1 lo establece en enforcing. Este cambio es temporal y no persistirá después de los reinicios.
```
sudo setenforce 0
```
Ahora, verifique el cambio usando getenforce de nuevo.
```
getenforce
```
La salida ahora debería ser Permissive.
```
Permissive
```
Cambiar el modo de SELinux de nuevo a enforcing temporalmente.

Para revertir el cambio temporal, use setenforce 1.
```
sudo setenforce 1
```
Verifique el modo una vez más.
```
getenforce
```
La salida debería ser Enforcing de nuevo.
```
Enforcing
```
Cambiar el modo de SELinux predeterminado a permissive permanentemente.

Para que los cambios de modo de SELinux sean persistentes después de los reinicios, debe modificar el archivo /etc/selinux/config. Este archivo define el modo de SELinux predeterminado para el sistema.

Abra el archivo de configuración usando nano.
```
sudo nano /etc/selinux/config
```
Dentro del editor nano, encuentre la línea que comienza con SELINUX= y cambie su valor de enforcing a permissive.
```
## This file controls the state of SELinux on the system.
## SELINUX= can take one of these three values:
##     enforcing - SELinux security policy is enforced.
##     permissive - SELinux prints warnings instead of enforcing.
##     disabled - No SELinux policy is loaded.
SELINUX=permissive
## SELINUXTYPE= can take one of these three values:
##     targeted - Targeted processes are protected,
##                for the majority of users.
##     minimum - Modification of targeted policy
##               uses current settings and adds to it.
##     mls - Multi Level Security protection.
SELINUXTYPE=targeted
```
Presione Ctrl+X para salir, luego Y para confirmar el guardado y Enter para escribir en el mismo archivo.

Después de guardar el archivo, puede confirmar el cambio en el archivo de configuración usando grep.
```
grep '^SELINUX' /etc/selinux/config
```
La salida debería mostrar SELINUX=permissive.
```
SELINUX=permissive
SELINUXTYPE=targeted
```
Nota Importante: Cambiar /etc/selinux/config no cambia inmediatamente el modo de SELinux activo. Solo establece el modo que se aplicará después del próximo reinicio del sistema. Para ver el modo activo actual, aún necesita usar getenforce.
```
getenforce
```
Todavía debería mostrar Enforcing porque el sistema aún no se ha reiniciado.
```
Enforcing
```

Cambiar el modo de SELinux predeterminado de nuevo a enforcing en el archivo de configuración.

Ahora, cambiemos el modo persistente de nuevo a enforcing. Esta es la configuración recomendada y más segura para SELinux.

Abra el archivo de configuración de nuevo.

sudo nano /etc/selinux/config

Cambie el parámetro SELINUX= de nuevo a enforcing.

## This file controls the state of SELinux on the system.
## SELINUX= can take one of these three values:
##     enforcing - SELinux security policy is enforced.
##     permissive - SELinux prints warnings instead of enforcing.
##     disabled - No SELinux policy is loaded.
SELINUX=enforcing
## SELINUXTYPE= can take one of these three values:
##     targeted - Targeted processes are protected,
##                for the majority of users.
##     minimum - Modification of targeted policy
##               uses current settings and adds to it.
##     mls - Multi Level Security protection.
SELINUXTYPE=targeted

Guarde y salga del archivo (Ctrl+X, Y, Enter).

Confirme el cambio en el archivo de configuración.

grep '^SELINUX' /etc/selinux/config

La salida ahora debería mostrar SELINUX=enforcing.

SELINUX=enforcing
SELINUXTYPE=targeted

En este punto, el modo de SELinux activo del sistema sigue siendo Enforcing (si no reinició después del paso 4), y la configuración persistente también es Enforcing.

Configurar Apache con Contextos de Archivo SELinux Personalizados

En este paso, aprenderá a configurar Apache para servir contenido web desde un directorio no estándar y a gestionar sus contextos de archivos SELinux. De forma predeterminada, las políticas de SELinux restringen a Apache (httpd) a servir archivos solo desde directorios específicos, principalmente /var/www/html. Si coloca contenido web en una ubicación diferente, SELinux impedirá que Apache acceda a él, incluso si los permisos del sistema de archivos son correctos. Aquí es donde entran en juego los contextos de archivos SELinux.

Un contexto de archivo SELinux es una etiqueta aplicada a un archivo o directorio que define sus atributos de seguridad. Para que Apache sirva contenido desde una ubicación personalizada, esa ubicación y su contenido deben tener el contexto SELinux correcto, típicamente httpd_sys_content_t. Usará semanage fcontext para definir una regla persistente y restorecon para aplicarla.

Primero, necesita instalar el servidor HTTP Apache.

Instalar el servidor HTTP Apache.

Use el gestor de paquetes dnf para instalar el paquete httpd.
```
sudo dnf install -y httpd
```
Debería ver una salida que indica la instalación exitosa del paquete httpd y sus dependencias.
Crear un directorio personalizado para contenido web y un archivo index.html.

Creará un nuevo directorio llamado /custom y colocará un archivo index.html simple dentro de él. Este será su raíz de documentos web no estándar.
```
sudo mkdir /custom
echo 'This is custom web content.' | sudo tee /custom/index.html
```
Verifique el contenido del archivo index.html.
```
cat /custom/index.html
```
```
This is custom web content.
```
Configurar Apache para usar la nueva raíz de documentos.

El archivo de configuración principal de Apache es /etc/httpd/conf/httpd.conf. Necesita editar este archivo para que Apache apunte a su nuevo directorio /custom en lugar del predeterminado /var/www/html.

Abra el archivo de configuración usando nano.
```
sudo nano /etc/httpd/conf/httpd.conf
```
Dentro del editor, encuentre las líneas DocumentRoot "/var/www/html" y <Directory "/var/www/html">. Cambie ambas apariciones de /var/www/html a /custom.

Las secciones relevantes deberían verse así después de la modificación:
```
#
## DocumentRoot: The directory out of which you will serve your
## documents. By default, all requests are taken from this directory, but
## symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/custom"

#
## Relax access to content within /var/www.
#
<Directory "/custom">
    AllowOverride None
    ## Allow open access:
    Require all granted
</Directory>
```
Guarde y salga del archivo (Ctrl+X, Y, Enter).
Iniciar y habilitar el servicio web Apache.

Después de modificar la configuración, necesita iniciar el servicio httpd. Dado que está en un entorno de contenedor, systemctl no está disponible. Iniciará httpd directamente.
```
sudo /usr/sbin/httpd -DFOREGROUND &
```
El símbolo & ejecuta el comando en segundo plano, lo que le permite continuar usando la terminal. Debería ver una salida similar a esta, que indica que Apache se está iniciando.
```
[1] 5094
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using fe80::216:3eff:fe00:63b%eth0. Set the 'ServerName' directive globally to suppress this message
```
Nota: El mensaje de advertencia sobre el nombre de dominio completo del servidor es normal en este entorno de laboratorio y se puede ignorar de forma segura.

Para verificar que Apache se está ejecutando, puede buscar el proceso httpd.
```
ps aux | grep httpd
```
Debería ver varios procesos httpd en ejecución.
```
root        ... /usr/sbin/httpd -DFOREGROUND
apache      ... /usr/sbin/httpd -DFOREGROUND
...output omitted...
```
Intentar acceder a la página web.

Ahora, intente acceder a su página web usando curl. Dado que está en la misma máquina, puede usar localhost.
```
curl http://localhost/index.html
```
Nota: En este entorno particular, es posible que encuentre que la página web es accesible incluso con el contexto root_t. Esto demuestra que, si bien SELinux está aplicando, el contexto root_t puede tener permisos más amplios de lo esperado. Sin embargo, para las mejores prácticas de seguridad y la configuración adecuada de SELinux, el contenido web aún debe usar el contexto httpd_sys_content_t apropiado.
```
This is custom web content.
```
Comprobar el contexto SELinux actual del directorio personalizado.

Use el comando ls -Z para ver el contexto SELinux de su directorio /custom y el archivo index.html.
```
ls -Zd /custom /custom/index.html
```
Notará que tienen el contexto root_t, que no es el contexto recomendado para el contenido web de Apache.
```
system_u:object_r:root_t:s0 /custom
system_u:object_r:root_t:s0 /custom/index.html
```
Compare esto con la raíz de documentos predeterminada de Apache:
```
ls -Zd /var/www/html
```
Verá que /var/www/html tiene el contexto httpd_sys_content_t. Este es el contexto que necesita aplicar a su directorio personalizado.
```
system_u:object_r:httpd_sys_content_t:s0 /var/www/html
```
Definir una regla de contexto de archivo SELinux persistente para /custom.

El comando semanage fcontext se usa para gestionar las reglas de mapeo de contexto de archivo SELinux. La opción -a agrega una nueva regla, -t especifica el tipo de destino y la expresión regular '/custom(/.*)?' coincide con el directorio /custom en sí y todos los archivos y subdirectorios dentro de él.
```
sudo semanage fcontext -a -t httpd_sys_content_t '/custom(/.*)?'
```
Este comando agrega la regla a la política de SELinux, pero no cambia inmediatamente los contextos de los archivos existentes.
Aplicar los nuevos contextos SELinux a los archivos.

El comando restorecon se usa para restaurar los contextos SELinux de archivos y directorios a sus valores predeterminados según lo definido por la política. La opción -R aplica el cambio de forma recursiva y -v proporciona una salida detallada.
```
sudo restorecon -Rv /custom
```
Debería ver una salida que indica que los contextos de /custom y /custom/index.html han sido reetiquetados.
```
Relabeled /custom from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0
Relabeled /custom/index.html from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0
```
Verifique los contextos de nuevo usando ls -Z.
```
ls -Zd /custom /custom/index.html
```
Ahora deberían tener el contexto httpd_sys_content_t.
```
system_u:object_r:httpd_sys_content_t:s0 /custom
system_u:object_r:httpd_sys_content_t:s0 /custom/index.html
```
Acceder a la página web de nuevo.

Ahora que los contextos SELinux son correctos, intente acceder a la página web con curl de nuevo.
```
curl http://localhost/index.html
```
Ahora debería ver el contenido de su archivo index.html.
```
This is custom web content.
```
Finalmente, detenga el proceso del servidor HTTP Apache.
```
sudo pkill httpd
```
Verifique que no se estén ejecutando procesos httpd.
```
ps aux | grep httpd
```
Solo debería ver el proceso grep en sí.
```
labex     ... grep httpd
```

Ajustar la Política de SELinux para Directorios Home de Usuario con Booleans

En este paso, aprenderá a ajustar la política de SELinux utilizando Booleanos para permitir que Apache sirva contenido web desde los directorios de inicio de los usuarios. De forma predeterminada, SELinux impide que servicios como Apache accedan a archivos en los directorios de inicio de los usuarios por razones de seguridad. Sin embargo, existen escenarios específicos, como las páginas web personales, donde se desea esta funcionalidad.

Los Booleanos de SELinux son configuraciones de verdadero/falso que permiten a los administradores modificar el comportamiento de la política de SELinux sin escribir políticas personalizadas complejas. Proporcionan una forma flexible de habilitar o deshabilitar ciertas características de seguridad. Por ejemplo, existe un Booleano específicamente para permitir que Apache acceda a los directorios de inicio de los usuarios.

Habilitar la función de directorio de usuario de Apache.

Apache tiene un módulo llamado mod_userdir que permite a los usuarios publicar contenido web desde un directorio public_html dentro de su directorio de inicio (por ejemplo, ~/public_html). Esta función se configura típicamente en /etc/httpd/conf.d/userdir.conf. De forma predeterminada, esta función a menudo está deshabilitada.

Abra el archivo de configuración usando nano.
```
sudo nano /etc/httpd/conf.d/userdir.conf
```
Dentro del editor, encontrará líneas relacionadas con UserDir. Necesita comentar la línea que deshabilita UserDir y descomentar la línea que lo habilita para public_html.

Cambiar:
```
UserDir disabled
#UserDir public_html
```
A:
```
#UserDir disabled
UserDir public_html
```
Guarde y salga del archivo (Ctrl+X, Y, Enter).
Crear un directorio public_html y un archivo index.html en su directorio de inicio.

Creará el directorio public_html y un archivo index.html dentro de él. Aquí es donde residirá su contenido web personal.
```
mkdir ~/public_html
echo 'This is labex user content.' > ~/public_html/index.html
```
Verifique el contenido del archivo index.html.
```
cat ~/public_html/index.html
```
```
This is labex user content.
```
Informativo: Cuando creó el directorio ~/public_html, se configuró automáticamente con los contextos SELinux user_home_t y ~/ (su directorio de inicio) con home_dir_t. El proceso del servidor web Apache (httpd_t) no puede leer archivos etiquetados como user_home_t o home_dir_t de forma predeterminada debido a la política de SELinux.
Iniciar el servicio web Apache.

Inicie el servicio httpd. Recuerde, systemctl no está disponible en este entorno de contenedor, por lo que iniciará httpd directamente.
```
sudo /usr/sbin/httpd -DFOREGROUND &
```
Puede ver un mensaje de advertencia sobre el nombre de dominio completo del servidor, que se puede ignorar de forma segura en este entorno de laboratorio.

Verifique que Apache se esté ejecutando.
```
ps aux | grep httpd
```
```
root        ... /usr/sbin/httpd -DFOREGROUND
apache      ... /usr/sbin/httpd -DFOREGROUND
...output omitted...
```
Intentar acceder a la página web del usuario y observar la denegación de SELinux.

Ahora, intente acceder a su página web personal usando curl. La URL para los directorios de usuario normalmente sigue el formato http://localhost/~username/.
```
curl http://localhost/~labex/index.html
```
Probablemente recibirá un error "Forbidden" (Prohibido), lo que indica que Apache aún no puede acceder al contenido debido a SELinux.
```
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /~labex/index.html
on this server.<br />
</p>
</body></html>
```
Comprobar los Booleanos de SELinux relacionados con los directorios de inicio para httpd.

El comando getsebool le permite ver el estado actual de los Booleanos de SELinux. Puede filtrar la salida usando grep para encontrar Booleanos relacionados con httpd y los directorios de inicio.
```
sudo getsebool -a | grep httpd | grep home
```
Debería ver httpd_enable_homedirs --> off, lo que indica que este Booleano está actualmente deshabilitado.
```
httpd_enable_homedirs --> off
```
Habilitar el Booleano httpd_enable_homedirs de forma persistente.

El comando setsebool se usa para cambiar el estado de los Booleanos de SELinux. La opción -P hace que el cambio sea persistente después de los reinicios.
```
sudo setsebool -P httpd_enable_homedirs on
```
Verifique que el Booleano ahora esté on.
```
sudo getsebool -a | grep httpd | grep home
```
```
httpd_enable_homedirs --> on
```
Establecer los permisos de archivo correctos para el directorio de inicio.

Incluso con el Booleano de SELinux habilitado, Apache necesita los permisos correctos del sistema de archivos para acceder a su directorio de inicio y al directorio public_html. De forma predeterminada, los directorios de inicio de los usuarios no son accesibles para el usuario Apache.
```
chmod 711 ~
chmod 755 ~/public_html
chmod 644 ~/public_html/index.html
```
Acceder a la página web de nuevo.

Ahora que tanto el Booleano httpd_enable_homedirs está habilitado como los permisos de archivo son correctos, intente acceder a su página web personal con curl de nuevo.
```
curl http://localhost/~labex/index.html
```
Ahora debería ver el contenido de su archivo index.html.
```
This is labex user content.
```
Solución de problemas: Si aún encuentra problemas de acceso incluso después de habilitar el booleano y establecer los permisos de archivo, esto demuestra la naturaleza de múltiples capas de la seguridad de Linux. En algunos entornos, factores adicionales como:
- Directivas de configuración de Apache en /etc/httpd/conf.d/userdir.conf
- Contextos de archivos SELinux en la estructura del directorio de inicio
- Módulos de Apache adicionales o configuraciones de seguridad
puede ser necesario abordarlos. El punto clave de aprendizaje es comprender cómo funcionan los booleanos de SELinux junto con los permisos de archivo tradicionales y las configuraciones específicas de la aplicación.
Detener el proceso del servidor HTTP Apache.

Finalmente, detenga el proceso del servidor HTTP Apache.
```
sudo pkill httpd
```
Verifique que no se estén ejecutando procesos httpd.
```
ps aux | grep httpd
```
```
labex     ... grep httpd
```

Solucionar Problemas de Denegaciones de SELinux para el Servidor Web Apache

En este paso, aprenderá a identificar y solucionar problemas de denegaciones de seguridad de SELinux, centrándose específicamente en problemas que podrían impedir que el servidor web Apache funcione correctamente. Cuando SELinux bloquea una operación, registra un mensaje de denegación de "Access Vector Cache" (AVC). Estos mensajes son cruciales para comprender por qué falló una operación y cómo resolverla.

Utilizará herramientas como auditd (el demonio del Sistema de Auditoría de Linux) y sealert para analizar estos mensajes de denegación. auditd recopila llamadas y eventos del sistema, incluidas las denegaciones de SELinux, y los almacena en /var/log/audit/audit.log. La herramienta sealert, parte del paquete setroubleshoot-server, puede analizar estos registros y proporcionar explicaciones legibles por humanos y soluciones sugeridas para las denegaciones de SELinux.

Primero, debe asegurarse de que auditd y setroubleshoot-server estén instalados.

Instalar auditd y setroubleshoot-server.
```
sudo dnf install -y audit setroubleshoot-server
```
Debería ver una salida que indica la instalación exitosa de estos paquetes.
Iniciar el servidor web Apache y crear un archivo problemático.

Para simular una denegación de SELinux, creará un archivo con un contexto SELinux incorrecto e intentará servirlo con Apache.

Primero, asegúrese de que Apache se esté ejecutando.
```
sudo /usr/sbin/httpd -DFOREGROUND &
```
Ahora, cree un nuevo directorio y un archivo index.html dentro de él. Esta vez, establecerá intencionalmente un contexto SELinux incorrecto para este archivo para activar una denegación.
```
sudo mkdir /testweb
echo 'This is a test page.' | sudo tee /testweb/index.html
```
De forma predeterminada, /testweb/index.html probablemente tendrá el contexto root_t. Vamos a confirmar.
```
ls -Z /testweb/index.html
```
```
system_u:object_r:root_t:s0 /testweb/index.html
```
Ahora, configuremos Apache para que sirva desde /testweb. Abra /etc/httpd/conf/httpd.conf.
```
sudo nano /etc/httpd/conf/httpd.conf
```
Cambie DocumentRoot y la directiva <Directory> a /testweb.
```
DocumentRoot "/testweb"

<Directory "/testweb">
    AllowOverride None
    Require all granted
</Directory>
```
Guarde y salga (Ctrl+X, Y, Enter).

Reinicie Apache para aplicar los cambios de configuración. Dado que está en un contenedor, necesita matar el proceso anterior e iniciar uno nuevo.
```
sudo pkill httpd
sudo /usr/sbin/httpd -DFOREGROUND &
```
Intentar acceder a la página web.

Intente acceder a la página web usando curl.
```
curl http://localhost/index.html
```
Nota Importante: En este entorno, es posible que encuentre que la página web es accesible incluso con el contexto root_t, similar a lo que observamos en el Paso 2. Esto demuestra que, si bien SELinux está aplicando, el contexto root_t tiene permisos más amplios que los contextos más restrictivos.
```
This is a test page.
```
Sin embargo, con el propósito de aprender técnicas de solución de problemas de SELinux, procederemos como si hubiera una denegación. En entornos SELinux más restrictivos o con diferentes configuraciones de políticas, el acceso a archivos con contextos inapropiados sí generaría denegaciones.
Aprender sobre la investigación de denegaciones de SELinux usando ausearch.

El comando ausearch se usa para consultar los registros de auditoría. Puede buscar denegaciones de AVC de SELinux (-m AVC) que ocurrieron hoy (-ts today).
```
sudo ausearch -m AVC -ts today
```
Nota: Dado que la página web era accesible en nuestro entorno, es posible que no vea ninguna denegación de AVC reciente relacionada con esta prueba específica. Sin embargo, este comando normalmente generaría entradas detalladas del registro de auditoría si hubiera denegaciones. En un escenario de denegación típico, buscaría entradas relacionadas con httpd y /testweb/index.html.

Una entrada de denegación de AVC típica se vería así:
```
----
time->...
type=AVC msg=audit(...): avc:  denied  { getattr } for  pid=... comm="httpd" path="/testweb/index.html" dev="overlay" ino=... scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0
...output omitted...
```
Las partes clave en una denegación de AVC serían:
- denied { getattr }: La operación que fue denegada (obtener atributos del archivo).
- comm="httpd": El proceso que fue denegado (servidor HTTP Apache).
- path="/testweb/index.html": El archivo al que se accedió.
- scontext=system_u:system_r:httpd_t:s0: El contexto SELinux de la fuente (Apache).
- tcontext=system_u:object_r:root_t:s0: El contexto SELinux del destino (su archivo index.html).
- tclass=file: El tipo de destino (un archivo).
Esta salida muestra claramente que a httpd_t (Apache) se le denegó el acceso getattr a un archivo con el contexto default_t.
Aprender sobre el uso de sealert para el análisis de SELinux.

sealert puede analizar los registros de auditoría y proporcionar información más fácil de usar. Puede ejecutar sealert -a para analizar todas las denegaciones recientes o usar sealert -l <UUID> si tiene un UUID específico de un mensaje setroubleshoot en /var/log/messages.
```
sudo sealert -a /var/log/audit/audit.log
```
Nota: Dado que no hemos encontrado denegaciones reales en este entorno, la ejecución de sealert puede no mostrar resultados relacionados con nuestro ejemplo /testweb. Sin embargo, en un escenario donde ocurren denegaciones de SELinux, sealert analizaría el registro de auditoría y presentaría un resumen.

Una salida típica de sealert para un problema de contexto httpd se vería así:
```
SELinux is preventing /usr/sbin/httpd from getattr access on the file /testweb/index.html.

***** Plugin catchall_labels (83.8 confidence) suggests *******************
If you want to allow httpd to have getattr access on the index.html file
Then you need to change the label on /testweb/index.html
Do ## semanage fcontext -a -t FILE_TYPE '/testweb/index.html'
where FILE_TYPE is one of the following:
httpd_sys_content_t, httpd_sys_script_exec_t, httpd_unconfined_script_exec_t, ...

***** Plugin httpd_can_network_connect (93.8 confidence) suggests *********
If you want to allow httpd to connect to the network (for example, to a database)
Then you must set the httpd_can_network_connect boolean to on.
Do ## setsebool -P httpd_can_network_connect on
...output omitted...
```
La salida de sealert sería muy útil en escenarios de denegación reales. Indicaría explícitamente el problema y sugeriría soluciones, como cambiar la etiqueta con semanage fcontext -a -t FILE_TYPE '/testweb/index.html' y enumerar httpd_sys_content_t como un FILE_TYPE adecuado.

Finalmente, detenga el proceso del servidor HTTP Apache.
```
sudo pkill httpd
```
Verifique que no se estén ejecutando procesos httpd.
```
ps aux | grep httpd
```
```
labex     ... grep httpd
```

Resolver Problemas de SELinux para Contenido Web Personalizado

En este paso final, aplicará el conocimiento adquirido del ejercicio de solución de problemas anterior para resolver la denegación de SELinux que impidió que Apache sirviera contenido desde el directorio /testweb. Usará semanage fcontext para definir el contexto SELinux correcto para su contenido web personalizado y restorecon para aplicarlo.

Este proceso refuerza la comprensión de cómo funcionan los contextos SELinux y cómo configurarlos correctamente para servicios como Apache.

Asegúrese de que Apache se esté ejecutando y la configuración esté en su lugar.

Primero, asegúrese de que Apache esté configurado para servir desde /testweb y se esté ejecutando. Si detuvo Apache en el paso anterior, inícielo de nuevo.
```
sudo /usr/sbin/httpd -DFOREGROUND &
```
Verifique que el DocumentRoot en /etc/httpd/conf/httpd.conf esté configurado en /testweb. Si no es así, modifíquelo como se hizo en el paso anterior.
```
grep "DocumentRoot" /etc/httpd/conf/httpd.conf
```
```
DocumentRoot "/testweb"
```
Además, confirme que /testweb/index.html existe y tiene el contexto root_t.
```
ls -Z /testweb/index.html
```
```
system_u:object_r:root_t:s0 /testweb/index.html
```
Acceder a la página web para confirmar el comportamiento actual.

Verifiquemos que la página web sea actualmente accesible con el contexto root_t.
```
curl http://localhost/index.html
```
Como hemos visto antes, la página es accesible incluso con el contexto root_t.
```
This is a test page.
```
Si bien esto funciona, procederemos a demostrar la configuración SELinux adecuada para el contenido web.
Definir el contexto de archivo SELinux correcto para /testweb.

El contexto SELinux correcto para el contenido web servido por Apache es httpd_sys_content_t. Necesita agregar una regla persistente usando semanage fcontext.
```
sudo semanage fcontext -a -t httpd_sys_content_t '/testweb(/.*)?'
```
Este comando le dice a SELinux que cualquier archivo o directorio dentro de /testweb (incluido /testweb en sí) debe etiquetarse con httpd_sys_content_t.

Aplicar los nuevos contextos SELinux a los archivos.

Después de definir la regla, debe aplicarla a los archivos existentes usando restorecon.

sudo restorecon -Rv /testweb

Debería ver una salida que indica que los contextos han sido reetiquetados.

Relabeled /testweb from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0
Relabeled /testweb/index.html from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0

Verifique los contextos nuevamente usando ls -Z.

ls -Z /testweb/index.html

system_u:object_r:httpd_sys_content_t:s0 /testweb/index.html

Acceder a la página web de nuevo para confirmar la configuración adecuada.

Ahora que los contextos SELinux se aplican correctamente de acuerdo con las mejores prácticas, intente acceder a la página web con curl una vez más.
```
curl http://localhost/index.html
```
El contenido aún debería ser accesible, y ahora está configurado correctamente con el contexto SELinux recomendado.
```
This is a test page.
```
Esto demuestra que, si bien el contexto root_t puede funcionar en este entorno, el uso del contexto httpd_sys_content_t adecuado sigue las mejores prácticas de SELinux y garantiza la compatibilidad en diferentes configuraciones de seguridad.

Finalmente, detenga el proceso del servidor HTTP Apache.
```
sudo pkill httpd
```
Verifique que no se estén ejecutando procesos httpd.
```
ps aux | grep httpd
```
```
labex     ... grep httpd
```

Resumen

En este laboratorio, aprendió a administrar la seguridad de SELinux en RHEL. Comenzó por comprender y practicar cómo cambiar los modos de aplicación de SELinux, tanto temporalmente usando setenforce como de forma persistente modificando /etc/selinux/config. Esto incluyó verificar el modo actual con getenforce y comprender las implicaciones de los modos Enforcing (Aplicación), Permissive (Permisivo) y Disabled (Deshabilitado).

Además, obtuvo experiencia práctica en la configuración de Apache con contextos de archivo SELinux personalizados utilizando semanage fcontext y restorecon para garantizar el correcto funcionamiento del servidor web. También aprendió a ajustar la política de SELinux para los directorios de inicio de usuario habilitando booleanos SELinux específicos con setsebool. Finalmente, el laboratorio cubrió técnicas esenciales de solución de problemas para las denegaciones de SELinux, específicamente para el servidor web Apache, mediante el análisis de los registros de auditoría con ausearch y audit2allow para identificar y resolver problemas de acceso para contenido web personalizado.