Búsqueda de sitios web

Serie RHCSA: Conceptos básicos de control de acceso obligatorio con SELinux en RHEL 7 - Parte 13


Durante esta serie hemos explorado en detalle al menos dos métodos de control de acceso: permisos estándar ugo/rwx (Administrar usuarios y grupos – Parte 3) y listas de control de acceso (Configurar ACL). sobre sistemas de archivos – Parte 7).

Aunque son necesarios como permisos de primer nivel y mecanismos de control de acceso, tienen algunas limitaciones que son abordadas por Security Enhanced Linux (también conocido como SELinux para abreviar).

Una de esas limitaciones es que un usuario puede exponer un archivo o directorio a una brecha de seguridad mediante un comando chmod mal elaborado y, por lo tanto, provocar una propagación inesperada de los derechos de acceso. Como resultado, cualquier proceso iniciado por ese usuario puede hacer lo que quiera con los archivos de su propiedad, donde finalmente un software malicioso o comprometido puede lograr acceso de nivel raíz a todo el sistema.

Con esas limitaciones en mente, la Agencia de Seguridad Nacional de Estados Unidos (NSA) ideó por primera vez SELinux, un método de control de acceso obligatorio y flexible, para restringir la capacidad de los procesos para acceder o realizar otras operaciones en objetos del sistema (como archivos, directorios, puertos de red, etc.) al modelo de permiso mínimo, que puede modificarse más adelante según sea necesario. En pocas palabras, a cada elemento del sistema se le da sólo el acceso necesario para funcionar.

En RHEL 7, SELinux está incorporado en el propio kernel y está habilitado en modo Enforcing de forma predeterminada. En este artículo explicaremos brevemente los conceptos básicos asociados a SELinux y su funcionamiento.

Modos SELinux

SELinux puede operar de tres maneras diferentes:

  1. Aplicación: SELinux deniega el acceso según las reglas de políticas de SELinux, un conjunto de pautas que controlan el motor de seguridad.
  2. Permisivo: SELinux no niega el acceso, pero las denegaciones se registran para acciones que se habrían denegado si se hubieran ejecutado en modo obligatorio.
  3. Desactivado (se explica por sí mismo).

El comando getenforce muestra el modo actual de SELinux, mientras que setenforce (seguido de un 1 o un 0) es se utiliza para cambiar el modo a Aplicar o Permisivo, respectivamente, solo durante la sesión actual.

Para lograr persistencia entre cierres de sesión y reinicios, deberá editar el archivo /etc/selinux/config y configurar la variable SELINUX en enforcing o permissive. o deshabilitado:

getenforce
setenforce 0
getenforce
setenforce 1
getenforce
cat /etc/selinux/config

Normalmente utilizará setenforce para alternar entre los modos SELinux (aplicando a permisivo y viceversa) como primer paso para la resolución de problemas. Si SELinux está actualmente configurado en enforcing mientras experimenta un determinado problema, y lo mismo desaparece cuando lo configura en permisivo, puede estar seguro de que está buscando en un problema de permisos de SELinux.

Contextos SELinux

Un contexto SELinux consiste en un entorno de control de acceso donde se toman decisiones basadas en el usuario, rol y tipo de SELinux (y opcionalmente un nivel):

  1. Un usuario de SELinux complementa una cuenta de usuario normal de Linux al asignarla a una cuenta de usuario de SELinux, que a su vez se utiliza en el contexto de SELinux para los procesos en esa sesión, con el fin de definir explícitamente sus roles y niveles permitidos.
  2. El concepto de rol actúa como intermediario entre los dominios y los usuarios de SELinux en el sentido de que define a qué dominios de proceso y tipos de archivos se puede acceder. Esto protegerá su sistema contra la vulnerabilidad a ataques de escalada de privilegios.
  3. Un tipo define un tipo de archivo SELinux o un dominio de proceso SELinux. En circunstancias normales, a los procesos se les impide acceder a archivos que otros procesos usan y acceder a otros procesos, por lo que el acceso solo se permite si existe una regla de política SELinux específica que lo permita.

Veamos cómo funciona todo eso a través de los siguientes ejemplos.

EJEMPLO 1: Cambiar el puerto predeterminado para el demonio sshd

En Seguridad SSH – Parte 8 explicamos que cambiar el puerto predeterminado donde escucha sshd es una de las primeras medidas de seguridad para proteger su servidor contra ataques externos. Editemos el archivo /etc/ssh/sshd_config y configuremos el puerto en 9999:

Port 9999

Guarde los cambios y reinicie sshd:

systemctl restart sshd
systemctl status sshd

Como puede ver, sshd no pudo iniciarse. ¿Pero qué pasó?

Una inspección rápida de /var/log/audit/audit.log indica que a sshd se le han denegado permisos para iniciarse en el puerto 9999 (los mensajes de registro de SELinux incluyen la palabra “AVC” para que puedan identificarse fácilmente entre otros mensajes) porque ese es un puerto reservado para el servicio JBoss Management:

cat /var/log/audit/audit.log | grep AVC | tail -1

En este punto, puede desactivar SELinux (¡pero no lo haga!) como se explicó anteriormente e intentar iniciar sshd nuevamente, y debería funcionar. Sin embargo, la utilidad semanage puede decirnos qué debemos cambiar para que podamos iniciar sshd en cualquier puerto que elijamos sin problemas.

Correr,

semanage port -l | grep ssh

para obtener una lista de los puertos donde SELinux permite que sshd escuche.

Entonces, cambiemos el puerto en /etc/ssh/sshd_config al puerto 9998, agreguemos el puerto al contexto ssh_port_t y luego reiniciemos el servicio. :

semanage port -a -t ssh_port_t -p tcp 9998
systemctl restart sshd
systemctl is-active sshd

Como puede ver, esta vez el servicio se inició correctamente. Este ejemplo ilustra el hecho de que SELinux controla el número de puerto TCP según sus propias definiciones internas de tipo de puerto.

EJEMPLO 2: Permitir que httpd envíe sendmail de acceso

Este es un ejemplo de SELinux administrando un proceso accediendo a otro proceso. Si implementara mod_security y mod_evasive junto con Apache en su servidor RHEL 7, deberá permitir que httpd acceda a sendmail para poder enviar una notificación por correo después de un ataque (D)DoS. En el siguiente comando, omita el indicador -P si no desea que el cambio sea persistente durante los reinicios.

semanage boolean -1 | grep httpd_can_sendmail
setsebool -P httpd_can_sendmail 1
semanage boolean -1 | grep httpd_can_sendmail

Como puede ver en el ejemplo anterior, las configuraciones booleanas de SELinux (o simplemente booleanas) son reglas de verdadero/falso integradas en las políticas de SELinux. Puede enumerar todos los valores booleanos con semanage boolean -l y, alternativamente, canalizarlos a grep para filtrar la salida.

EJEMPLO 3: Servir un sitio estático desde un directorio distinto al predeterminado

Supongamos que está sirviendo un sitio web estático usando un directorio diferente al predeterminado (/var/www/html), digamos /websites (este podría ser el caso si no Si estás almacenando tus archivos web en una unidad de red compartida, por ejemplo, y necesitas montarla en /websites).

a). Cree un archivo index.html dentro de /websites con el siguiente contenido:

<html>
<h2>SELinux test</h2>
</html>

Si lo haces,

ls -lZ /websites/index.html

Verás que el archivo index.html ha sido etiquetado con el tipo default_t SELinux, al que Apache no puede acceder:

b). Cambie la directiva DocumentRoot en /etc/httpd/conf/httpd.conf a /websites y No olvides actualizar el bloque Directorio correspondiente. Luego, reinicie Apache.

c). Vaya a http:// y debería obtener una respuesta HTTP 503 prohibido.

d). A continuación, cambie la etiqueta de /websites, de forma recursiva, al tipo httpd_sys_content_t para otorgar a Apache acceso de solo lectura a ese directorio y su contenido:

semanage fcontext -a -t httpd_sys_content_t "/websites(/.*)?"

e). Finalmente, aplique la política SELinux creada en d):

restorecon -R -v /websites

Ahora reinicie Apache y busque http:// nuevamente y verá el archivo html mostrado correctamente:

Resumen

En este artículo hemos repasado los conceptos básicos de SELinux. Tenga en cuenta que debido a la amplitud del tema, no es posible ofrecer una explicación completa y detallada en un solo artículo, pero creemos que los principios descritos en esta guía le ayudarán a pasar a temas más avanzados si así lo desea.

Si se me permite, permítame recomendarle dos recursos esenciales para comenzar: la página NSA SELinux y la guía del usuario y administrador de RHEL 7 SELinux.

No dude en hacernos saber si tiene alguna pregunta o comentario.