1. Preámbulo
Linux con Seguridad Mejorada (SELinux) es un módulo del núcleo Linux y un subsistema de seguridad de Linux.
SELinux fue desarrollado principalmente por la NSA. Los kernels de Linux 2.6 y superiores ya integran módulos SELinux.
SELinux es muy complejo y tiene muchas cosas conceptuales que son difíciles de aprender. Muchos administradores de sistemas Linux han desactivado SELinux porque les resulta problemático.
Si dominas SELinux y lo usas correctamente, creo que todo el sistema puede llegar básicamente al punto de ser "indestructible" (recuerda siempre que no hay una seguridad absoluta).
Dominar los conceptos básicos de SELinux, así como los métodos de configuración sencillos, es un curso obligatorio para todo administrador de sistemas Linux.
Este artículo está basado en CentOS 7.4.1708.
Este artículo es puramente un intercambio y experiencia personal de aprendizaje, los errores son inevitables, ¡solo para referencia! Si encuentras un error, por favor señalalo, ¡muchas gracias!
2. El papel de SELinux y el mecanismo de gestión de permisos
2.1 El papel de SELinux
La función principal de SELinux es minimizar los recursos a los que pueden acceder los procesos de servicio en el sistema (el principio del privilegio mínimo).
Imagina que si un servicio de red que funciona como root tiene una vulnerabilidad 0day, los hackers pueden explotar esta vulnerabilidad para hacer lo que quieran en tu servidor como root. ¿No da miedo?
SELinux está aquí para resolver este problema.
2.2 DAC
En un sistema operativo que no utiliza SELinux, el factor que determina si un recurso puede ser accedido es si un recurso tiene los permisos del usuario correspondiente (leer, escribir, ejecutar).
Mientras el proceso que accede a este recurso cumpla con las condiciones anteriores, puede ser accedido.
El problema más fatal es que los usuarios root no están sujetos a ninguna regulación, y cualquier recurso del sistema puede ser accedido sin restricciones.
El cuerpo principal de este mecanismo de gestión de permisos es el usuario, también conocido como control de acceso autónomo (DAC).
2.3 MAC
En un sistema operativo que utiliza SELinux, los factores que determinan si un recurso puede ser accedido no solo son los anteriores, sino también si cada tipo de proceso tiene acceso a un determinado tipo de recurso.
De este modo, incluso si un proceso se ejecuta como root, es necesario determinar el tipo de proceso y los tipos de recursos a los que se puede acceder antes de decidir si permitir el acceso a un recurso. El espacio activo del proceso también puede comprimirse al mínimo.
Incluso un proceso de servicio que se ejecuta como root generalmente solo tiene acceso a los recursos que necesita. Incluso si un programa es vulnerable, el alcance del impacto se limita a los recursos a los que se le permite acceder. La seguridad aumenta considerablemente.
El cuerpo principal de este mecanismo de gestión de permisos es el proceso, también conocido como control de acceso obligatorio (MAC).
MAC se subdivide en dos formas: una se llama modo de Seguridad de Categoría (MCS) y la otra se denomina modo de Seguridad Multinivel (MLS).
Las siguientes acciones están en modo MCS.
2.4 Comparación entre DAC y MAC
Aquí tienes una imagen para ilustrar.
Como puedes ver, en modo DAC, mientras el directorio correspondiente tenga los permisos del usuario correspondiente, se puede acceder. En modo MAC, también está limitado por el rango de directorios a los que los procesos pueden acceder.
3. Conceptos básicos de SELinux
3.1 Tema
Se puede equiparar completamente a un proceso.
Nota: Para facilitar la comprensión, salvo que se especifique lo contrario, el proceso se considera el cuerpo principal a continuación.
3.2 Objetivo
Recursos a los que accede el director. Pueden ser archivos, directorios, puertos, dispositivos, etc.
Nota: Para facilitar la comprensión, salvo que se especifique lo contrario, los siguientes documentos o directorios se consideran objetos.
3.3 Política y Norma
Normalmente hay un gran número de archivos y procesos en el sistema, y para ahorrar tiempo y sobrecarga, normalmente solo regulamos selectivamente ciertos procesos.
Y qué procesos deben regularse y cómo controlarlos está determinado por la política.
Una póliza tiene varias normas. Algunas reglas pueden activarse o desactivarse según sea necesario (en adelante denominadas reglas booleanas).
Las reglas son modulares y extensibles. Al instalar una nueva aplicación, la aplicación puede añadir reglas añadiendo nuevos módulos. Los usuarios también pueden añadir o restar reglas manualmente.
En el sistema CentOS 7, existen tres conjuntos de políticas, a saber:
1. dirigido: Controla la mayoría de los procesos de servicio de red. Esta es la política que utiliza el sistema por defecto (todas las que aparecen a continuación se usan).
2. Mínimo: Según el objetivo, solo se regulan procesos de servicio de red seleccionados. Generalmente no.
3. MLS: Protección de seguridad multinivel. Regula todos los procesos. Esta es la política más estricta y la configuración es muy difícil. Generalmente, no se utiliza salvo que existan requisitos de seguridad extremadamente altos.
Las políticas se pueden establecer en /etc/selinux/config.
3.4 Contexto de seguridad
El contexto de seguridad está en el corazón de SELinux.
Contexto de seguridad lo dividiré en "contexto de seguridad de procesos" y "contexto de seguridad documental".
Un Contexto de Seguridad de Procesos suele corresponder a múltiples Contextos de Seguridad de Documentos.
Solo cuando el contexto de seguridad de ambos corresponde puede un proceso acceder al archivo. Su correspondencia está determinada por las normas de la póliza.
El contexto de seguridad del archivo se determina por dónde se creó el archivo y el proceso que lo creó. Y el sistema tiene un conjunto de valores por defecto, y los usuarios también pueden establecer esos valores.
Es importante señalar que simplemente mover archivos no cambia el contexto de seguridad de tus archivos.
La estructura y el significado del contexto de seguridad
El contexto de seguridad tiene cuatro campos, separados por dos puntos. Formas como: system_u:object_r:admin_home_t:s0.
3.5 Modo de Funcionamiento SELinux
SELinux tiene tres modos de funcionamiento, a saber:
1. hacer cumplir: Modo impuesto. Las violaciones de las normas de SELinux serán bloqueadas y registradas en los registros.
2. Permisivo: Modo de tolerancia. Las violaciones de las reglas de SELinux solo se registran en los registros. Generalmente para depuración.
3. desactivado: Apaga SELinux.
El modo de trabajo SELinux se puede configurar en /etc/selinux/config.
Si quieres cambiar de discapacitado a aplicar o permisivo, tendrás que reiniciar el sistema. Y viceversa.
Los modos de aplicación y permisivo pueden intercambiarse rápidamente con el comando Setenforce 1|0.
Es importante señalar que si el sistema ha estado funcionando con SELinux apagado durante un tiempo, el primer reinicio tras activar SELinux puede ser más lento. Porque el sistema tiene que crear un contexto seguro para los archivos en disco (dije que reinicié durante unos 10 minutos y pensé que estaba muerto...... ）。
Los registros de SELinux deben registrarse con la ayuda de auditd.service, por favor no lo desactives.
3.6 Flujo de trabajo de SELinux
Aquí hay una cita de una foto, sin mucha explicación.
Nota: El texto de seguridad anterior se refiere al contexto de seguridad.
4. Operaciones básicas de SELinux
4.1 Consulta el contexto de seguridad de un archivo o directorio
Uso básico de comandos
ls -z
Ejemplos de uso
Consulta el contexto de seguridad de /etc/hosts.
ls -Z /etc/hosts
Resultados de ejecución
-r-r--r--. raíz raíz system_u:object_r:net_conf_t:s0 /etc/hosts
4.2 Consulta el contexto de seguridad del proceso
Uso básico de comandos
ps auxZ | grep -v grep | grep
Ejemplos de uso
Consulta el contexto de seguridad de los procesos relacionados con Nginx.
ps auxZ | grep -v grep | GREP Nguinx
Resultados de ejecución
system_u:system_r:httpd_t:s0 raíz 7997 0.0 0.0 122784 2156 ? Ss 14:31 0:00 nginx: proceso maestro /usr/sbin/nginx
system_u:system_r:httpd_t:s0 nginx 7998 0.0 0.0 125332 7560 ? S 14:31 0:00 nginx: proceso de trabajador
4.3 Modificar manualmente el contexto de seguridad de un archivo o directorio
Uso básico de comandos
CHCON [...]
Función opción -u Modificar el campo de usuario del contexto de seguridad -r Modificar el campo de rol del contexto de seguridad -t Modificar el campo tipo del contexto de seguridad -l Modificar el campo de nivel del contexto de seguridad --reference Modificar el contexto de seguridad consistente con el archivo o directorio especificado -R Operación recursiva -h Modificar el contexto de seguridad del enlace suave (modificar el archivo correspondiente del enlace suave sin esta opción)
Ejemplos de uso
Modifica el contexto de seguridad de la prueba a aaa_u:bbb_r:ccc_t:s0.
CHCON -U aaa_u -R bbb_r -T ccc_t prueba
4.4 Revertir el contexto de seguridad de un archivo o directorio a su valor predeterminado
Uso básico de comandos
RestoreCon [opciones] [...]
Función de opción - V Procedimiento de Operación de Impresión - Operación Recursiva R
Ejemplos de uso
Después de añadir algunos archivos web al directorio de tu servidor Nginx, establece el contexto de seguridad correcto para estos nuevos archivos.
restorecon -R /usr/share/nginx/html/
4.5 Consulta a las reglas booleanas y su estado en el sistema
Uso básico de comandos
getsebool -a
Como el comando consulta todas las reglas o solo una, normalmente consulta todas las reglas primero y luego filtra con grep.
Ejemplos de uso
Consulta reglas booleanas relacionadas con httpd.
getsebool -a | grep httpd
Resultados de ejecución
httpd_anon_write -->
httpd_builtin_scripting --> adelante
httpd_can_check_spam -->
httpd_can_connect_ftp -->
#以下省略
4.6 Cambio de una regla booleana
Uso básico de comandos
setsebool [opción]
La función de opción -P reinicio sigue vigente
Ejemplos de uso
Activa httpd_anon_write reglas.
setsebool -P httpd_anon_write on
4.7 Añadir un contexto de seguridad por defecto para un directorio
Uso básico de comandos
semanage fcontext -a -t "(/.*)?"
Nota: El contexto de seguridad predeterminado de un directorio o archivo puede visualizarse usando el comando semanage fcontext -l junto con el filtrado grep.
Ejemplos de uso
Después de añadir un nuevo directorio del sitio /usr/share/nginx/html2 a Nginx, tienes que establecer el mismo contexto de seguridad por defecto que el directorio original.
semanage fcontext -a -t httpd_sys_content_t "/usr/share/nginx/html2(/.*)?"
4.8 Añadir puertos que permiten ciertos tipos de procesos
Uso básico de comandos
puerto semanage -a -t -p
Nota: Los números de puerto permitidos para varios tipos de servicio pueden consultarse usando el comando semanage port -l con filtrado grep.
Ejemplos de uso
Para Nginx, necesitas usar el puerto 10080 para servicios HTTP.
SeManage puerto -A -T http_port_t -P TCP 10080
5. Análisis y resolución de errores SELinux
5.1 Comprensión de los registros de SELinux
Cuando SELinux está habilitado, algún comportamiento normal de muchos servicios se considera una violación (tanto en el título como en los errores que aparecen a continuación).
En este momento, necesitamos usar los registros de violaciones de SELinux para analizarlas y resolverlas.
Los registros de infracciones de SELinux se guardan en /var/log/audit/audit.log.
/var/log/audit/audit.log 的内容大概是这样的。
type=LOGIN msg=audit(1507898701.391:515): pid=8523 uid=0 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 old-auid=4294967295 auid=0 tty=(ninguno) old-ses=4294967295 ses=25 res=1
Tipo=USER_START MSG=Auditoría(1507898701.421:516): PID=8523 UID=0 AUID=0 SES=25 Subj=system_u:system_r:crond_t:S0-S0:C0.C1023 MSG='op=PAM:session_open Grantors=pam_loginuid,pam_ keyinit,pam_limits,pam_systemd acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=éxito'
...
El archivo contiene mucho contenido, y está mezclado con muchos registros de auditoría del sistema que no tienen nada que ver con errores de SELinux. Usaremos la utilidad sealert para ayudar con el análisis (si el prompt no encuentra el comando, instala el paquete setroubleshoot).
5.2 Analizar errores con Sealert
Uso básico de comandos
Sealert -A /var/log/audit/audit.log
Tras ejecutar el comando, el sistema necesita tomarse un tiempo para analizar las violaciones en los registros y proporcionar un informe de análisis. |
Publicado en 5/7/2019 11:25:50
|
|
|
|
Propietario|
Publicado en 22/7/2021 17:17:58
|
