Configure SELinux para permitir que los demonios usen archivos en ubicaciones no predeterminadas

Antecedentes

SELinux agrega otra capa de verificación de permisos en los sistemas Linux. En los sistemas habilitados para SELinux, los permisos regulares de DAC se verifican primero y, si permiten el acceso, la política de SELinux es consultado. Si la política de SELinux deniega el acceso, se genera una entrada de registro en el registro de auditoría en /var/log/audit/audit.log o en dmesg si auditd no se está ejecutando en el sistema.

SELinux asigna una etiqueta, llamada contexto de seguridad , a cada objeto (archivo, proceso, etc.) en el sistema:

• Archivos tener contexto de seguridad almacenado en atributos extendidos. Estos se pueden ver con ls -Z .

  SELinux mantiene una base de datos que asigna patrones de rutas a contextos de archivos predeterminados. Esta base de datos se usa cuando necesita restaurar manualmente los contextos de archivo predeterminados o cuando se vuelve a etiquetar el sistema. Esta base de datos se puede consultar con semanage herramienta.

• Procesos se les asigna un contexto de seguridad cuando se ejecuta un ejecutable (execve llamada al sistema). Los contextos de seguridad del proceso se pueden ver con la mayoría de las herramientas de monitoreo del sistema, por ejemplo, con ps Z $PID .

• También existen otros objetos etiquetados, pero no son relevantes para esta respuesta.

política de SELinux contiene las reglas que especifican qué operaciones entre contextos están permitidas. SELinux opera en lista blanca reglas, se deniega cualquier cosa que no esté explícitamente permitida por la política. La política de referencia contiene módulos de política para muchas aplicaciones y, por lo general, es la política utilizada por las distribuciones habilitadas para SELinux. Esta respuesta describe principalmente cómo trabajar con una política basada en la política de referencia, que probablemente esté usando si usa la política proporcionada por la distribución.

Cuando ejecuta su aplicación como su usuario normal, probablemente no note SELinux, porque la configuración predeterminada coloca a los usuarios en no confinado contexto. Procesos que se ejecutan en no confinado contexto tienen muy pocas restricciones establecidas. Es posible que pueda ejecutar su programa sin problemas en el shell del usuario en un contexto ilimitado, pero cuando se inicia con el sistema init, es posible que ya no funcione en un contexto restringido.

Problemas típicos

Cuando los archivos están en una ubicación no predeterminada (no descrita en la política predeterminada), los problemas suelen estar relacionados con los siguientes motivos:

• Los archivos tienen un contexto de archivo incorrecto/incompatible :Archivos movidos con mv mantener sus metadatos, incluidos los contextos de seguridad de archivos de la ubicación anterior. Los archivos creados en una nueva ubicación heredaron el contexto del directorio principal o del proceso de creación.

• Tener múltiples demonios usando los mismos archivos :La política predeterminada no incluye reglas para permitir la interacción entre los contextos de seguridad en cuestión.

Archivos con contexto de seguridad incorrecto

Si los archivos no son utilizados por otro demonio (u otro proceso confinado) y el único cambio es la ubicación donde se almacenan los archivos, los cambios requeridos en la configuración de SELinux son:

• Agregar una nueva regla a la base de datos de contexto de archivo
• Aplicar el contexto de archivo correcto a los archivos existentes

El contexto del archivo en la ubicación predeterminada se puede usar como plantilla para la nueva ubicación. La mayoría de los módulos de políticas incluyen documentación de la página del manual (generada usando sepolicy manpages ) explicando posibles contextos de archivos alternativos con su semántica de acceso.

La base de datos de contexto de archivos utiliza la sintaxis de expresiones regulares, lo que permite escribir especificaciones superpuestas. Vale la pena señalar que el contexto aplicado es la última especificación encontrada.

Para agregar una nueva entrada a la base de datos de contexto de archivo:

semanage fcontext -a -t <type> "/path/here/(/.*)?"

Después de agregar una nueva entrada de contexto a la base de datos, el contexto de la base de datos se puede aplicar a sus archivos usando restorecon <files> . Ejecutando restorecon con -vn las banderas mostrarán qué contextos de archivo se cambiarían sin aplicar ningún cambio.

Probar un nuevo contexto de archivo sin agregar una nueva entrada en la base de datos

El contexto se puede cambiar manualmente con chcon herramienta. Esto es útil cuando desea probar el nuevo contexto de archivo sin agregar una entrada a la base de datos de contexto de archivo.

El nuevo contexto de archivo se especifica en los argumentos de chcon . Cuando se usa con --reference= opción, el contexto de seguridad de un archivo de referencia se copia a los archivos de destino.

usando un contexto específico (default_t ):

chcon -t default_t <target files>

o usando una referencia:

chcon --reference=<path to default location> <target files>

Nota sobre diferentes sistemas de archivos y puntos de montaje

Si la nueva ubicación es su propio punto de montaje, el contexto se puede configurar con una opción de montaje. El conjunto de contexto con la opción de montaje no se almacena en el disco, por lo que también se puede usar con sistemas de archivos que no admiten atributos extendidos.

mount <device> <mount point> -o context="<context>"

Permitir que los procesos que se ejecutan en diferentes contextos de seguridad usen los mismos archivos

Opción 1:Booleanos

La política de referencia incluye opciones ajustables, denominadas booleanos , que habilitan/deshabilitan ciertas reglas adicionales. Muchos de ellos permiten la interoperación de diferentes demonios del sistema que normalmente no utilizan los mismos archivos.

La lista de todas las opciones ajustables posibles y sus descripciones se pueden enumerar usando semanage boolean -l . audit2allow también podría decir directamente qué valor booleano debe habilitarse.

Para habilitar/deshabilitar un booleano usando semanage :

semanage boolean --on <boolean name>
semanage boolean --off <boolean name>

Los valores booleanos son la forma más sencilla de modificar la política. Sin embargo, no se pueden abordar todas las situaciones posibles alternando un valor booleano. Algunos booleanos también permiten un acceso muy amplio, siendo demasiado permisivos.

Opción 2:extender la política con un nuevo módulo

Si no existe un valor booleano para permitir el acceso, la política debe modificarse agregando un módulo personalizado.

Se puede generar un módulo simple que agregue las reglas requeridas para permitir el acceso a partir de archivos de registro usando audit2allow con los siguientes pasos:

1. Establecer el dominio del daemon (contexto de seguridad) a modo permisivo . En el modo permisivo, la política no se aplica , pero los registros se generan en el acceso que la política normalmente denegaría.

   semanage permissive -a <domain>
   

2. Pruebe su daemon en funcionamiento normal para generar entradas de registro.

3. Cree un nuevo módulo de políticas e insértelo.

   audit2allow -a -M <name>
   semodule -i <name>.pp'
   

4. Vuelva a habilitar el modo de cumplimiento

   semanage permissive -d <domain>
   

Este método funciona mejor cuando solo hay unos pocos contextos de seguridad involucrados. En una configuración compleja, es muy probable que tenga que escribir su propio módulo de políticas. Algunos recursos para comenzar son la wiki de Gentoo y la documentación de la API de política de referencia.

Con este comando:

# semanage fcontext -l /oldpath/

Puede verificar los contextos predeterminados de SElinux en las carpetas de su sistema, por lo que con ese comando puede ver el contexto predeterminado de esa carpeta daemon.

Entonces puede verificar cualquier contexto de SELinux que deba configurar en el directorio al que desea mover su contenido.

Digamos que ves que tu carpeta daemon tiene este contexto (es contexto apache):

# semanage fcontext -l
...
/var/www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0

Luego, aplicará estos contextos a la nueva ruta de esta manera (ejemplo con el contexto de seguridad predeterminado del demonio apache)

# semanage fcontext -a -t httpd_sys_content_t '/newpath(/.*)?'

Después de hacer eso, considerando que su contenido ya está en la nueva ruta, debe forzar todo debajo de esa ruta para obtener ese contexto:

# restorecon -RFvv /newpath

Puedes comprobar si funcionó con este comando:

# ls -Zd /newpath/

Recuerde que cuando mv un directorio o archivos, mantiene el contexto de seguridad. Cuando cp una carpeta o directorio, establecerá el contexto al del padre.

Si necesita consultar las páginas del manual para un software específico, puede instalar las páginas del manual con:

# yum install -y selinux-policy-devel

No olvides ejecutar este comando para reindexar la base de datos man:

# mandb

Luego puede ejecutar este y verificar todas las páginas man de selinux.

# man -k selinux

Sugerencia, ejecute este comando antes y después de instalar ese paquete, para ver la diferencia:

# man -k selinux | wc -l