Gentoo Logo

[ << ] [ < ] [ Inicio ] [ > ] [ >> ]


2. Configurar SELinux para adaptarlo a sus necesidades

Contenido:

2.a. Administrando usuarios

Introducción

A lo largo de la instalación, hemos hablado de como mapear un usuario Linux a uno SELinux. En el ejemplo, hemos utilizado un usuario hipotético llamado "juan" y lo hemos mapeado al usuario SELinux "staff_u". Si está corriendo un sistema multiusuario, la gestión de los mapeos de derechos es importante. Un usuario que se mapea al usuario "user_u" no obtendrá ningún derecho adicional. Incluso si le concediera derechos adicionales a través de órdenes como sudo, la directriz de SELinux no le permitiría a este usuario hacer nada que esté relacionado con la administración.

Por esta razón, es importante tratar los mapeos de usuarios en SELinux y los usuarios Linux de su sistema.

Mapeos de usuario

Ejecute semanage login -l para mostrar los mapeos actuales entre las cuentas de usuario Linux y los usuarios SELinux.

Listado de Código 1.1: Ejecutar semanage login -l

# semanage login -l

Login Name                SELinux User

__default__               user_u
root                      root
juan                      staff_u
system_u                  system_u

El usuario SELinux "user_u" se utiliza para las cuentas normales. De esta forma, el mapeo especial __default__ se define en SELinux para notar que esa cuenta no está definida de otra forma. Esto nos asegura que una cuenta nueva nos obtiene privilegios elevados por defecto.

La siguiente tabla ofrece una vista rápida de los usuarios estándar SELinux disponibles después de la instalación.

Usuario SELinux Descripción
user_u Usuario normal por defecto de SELinux, el cual se debe utilizar para las cuentas de usuario final que no van a ser empleadas para administrar ningún servicio del sistema.
staff_u Usuario SELinux para administradores. Este usuario tiene derechos para conmutar roles y así ganar privilegios elevados.
root Usuario SELinux para la cuenta root. Se diferencia ligeramente de la cuenta staff_u aparte de tener un identificador diferente. Esto nos asegura que los ficheros protegidos por el control de acceso basado en usuario para root no puede ser gestionado por los usuarios staff_u (y otros).
sysadm_u Usuario SELinux para la administración del sistema. Por defecto, esta cuenta no se utiliza inmediatamente ya que este usuario obtiene de forma inmediata el rol administrativo (por lo que staff_u y root todavía necesitarán conmutar roles).
system_u Usuario SELinux para administrar servicios. Nunca se debe utilizar para usuarios finales ya que ofrece acceso directo al rol del sistema (y sus privilegios).
unconfined_u Usado cuando la directriz es targeted, este usuario SELinux tiene muchos privilegios (esencialmente no está limitado en sus acciones, aunque todavía se gestiona través de SELinux con una directriz "muy abierta").

Para mapear una cuenta a un usuario especifico de SELinux, utilice la orden semanage login -a:

Listado de Código 1.2: Mapera la cuenta 'sofia' al usuario staff_u

# semanage login -a -s staff_u sofia

Sin embargo, cuando se actualiza este mapeo, los ficheros en el directorio de inicio (home) del usuario serán propiedad de un usuario SELinux incorrecto. Por ello, es importante etiquetar de nuevo los ficheros de ese usuario:

Listado de Código 1.3: Etiquetar de nuevo los ficheros de sofia

# restorecon -R -F /home/sofia

Cuentas adicionales de SELinux

Es perfectamente posible crear usuarios SELinux adicionales, y mapear las cuentas Linux a esos nuevos usuarios. Esto se puede necesitar cuando desee una auditoría más profunda (al nivel del usuario final) o cuando esté mejorando la directriz con roles adicionales. También, si quiere utilizar la característica de Control de Acceso Basada en Usuario (UBAC), el hecho de usar diferentes usuarios SELinux es importante para reforzar el control de los distintos usuarios (si todos ellos utilizan el mismo usuario SELinux, el UBAC tendrá poco efecto).

La gestión de los usuarios SELinux se realiza usando semanage user:

Listado de Código 1.4: Crear un usuario SELinux

# semanage user -a -R "staff_r sysadm_r" sofia

Verifiquemos como los usuarios SELinux están configurados actualmente:

Listado de Código 1.5: Comprobar las identidades de los usuarios SELinux

# semanage user -l
SELinux User    SELinux Roles

root            staff_r sysadm_r
sofia           staff_r sysadm_r
staff_u         staff_r sysadm_r
sysadm_u        sysadm_r
system_u        system_r
unconfined_u    unconfined_r
user_u          user_r

# semanage login -l
Login Name                SELinux User

__default__               user_u
root                      root
sofia                     staff_u
swift                     staff_u
system_u                  system_u

Ahora que hemos creado un nuevo usuario llamado "sofia", podemos actualizar el mapeo de la cuenta Linux "sofia" hacia el nuevo usuario SELinux "sofia":

Listado de Código 1.6: Actualizar el mapeo del usuario Linux

# semanage login -m -s sofia sofia
# semanage login -l
Login Name                SELinux User

__default__               user_u
root                      root
sofia                     sofia
swift                     staff_u
system_u                  system_u

No olvide etiquetar de nuevo los ficheros de este usuario.

Como puede ver, la gestión de los usuarios SELinux implica definer el rol al cual tiene acceso cada usuario. Hemos dado una introducción de alto nivel a los roles por defecto en Conceptos detrás de SELinux, sin embargo ya que los roles son importantes cuando usamos un sistema de Control de Acceso Obligatorio, refresquémos la memoria de nuevo:

Rol SELinux Descripción
user_r Rol por defecto para el usuario final. Este rol ofrece acceso a las aplicaciones y actividades comunes, sin embargo, no permite la administración del sistema ni de ningún servicio más allá de lo esperado para un usuario normal.
staff_r Rol de administración por defecto para las actividades diarias. Este rol posee privilegios adicionales más allá de los ofrecidos a user_r, sin embargo, no es un rol de administración del sistema completo. Está pensado para las actividades que no sean de administración realizadas por operadores y administradores.
sysadm_r Rol de administración del sistema. Este role tiene privilegios muy elevados (ya que contiene aquellos privilegios necesarios para actualizar la directriz) y debería asignarse únicamente a administradores en los que se confíe plenamente. En casi ninguna situación es asignado a usuarios de forma inmediata (deben en primer lugar conmutar entre roles) excepto para el acceso directo de root (por ejemplo a través de la consola).
system_r Rol de servicio del sistema, el cual se utiliza para los servicios que están corriendo (procesos). Se asigna únicamente a los usuarios cuando estos obtienen derechos específicos y limitados de administración (por ejemplo, derechos de administración sobre un único dominio de un demonio).
unconfined_r El rol no confinado se utiliza cuando la directriz targeted está soportada. Este rol se asigna a usuarios no confinados (por ejemplo el usuario SELinux unconfined_u) los cuales tienen muchos privilegios (éstos trabajan prácticamente sin limitaciones).

Se debe observar que estos roles son los que existen por defecto, sin embargo, el administrador de seguridad puede crear roles adicionales y añadir privilegios particulares. Hablaremos sobre esto más adelante en este manual ya que implica que se debe actualizar la directriz SELinux de Gentoo Hardened.

2.b. Leyendo el registro de auditoría

Introducción

Cuando trabaje con un sistema que tiene habilitado SELinux, se dará cuenta de que las cosas se comportan de forma diferente pero sin indicar ningún mensaje de error con sentido. Normalmente, cuando SELinux "deniega" un acceso en particular, lo almacena en el registro de auditoría del sistema, aunque para la aplicación en si misma, es perfectamente posible que muera de forma silenciosa. En caso contrario, lo más seguro es que obtenga un mensaje de error permiso denegado.

Inicialmente, SELinux se ejecuta en modo permisivo, lo cual significa que SELinux registrará lo que denegaría aunque nos deje continuar. Este modo es perfecto para poner al sistema en forma sin tener demasiados problemas mientras se hace esto. Una vez que crea que sus ajustes de seguridad son correctos, se puede cambiar el modo de permisivo a forzado. Hablaremos de esto más adelante.

En primer lugar, echemos un vistazo al registro de auditoría y veamos lo que se dice allí...

Ubicación(es) del registro de auditoría

El código del núcleo SELinux escribe las denegaciones de acceso (y en alguna ocasión incluso las actividades que se permiten pero que están siendo auditadas) en el registro de auditoría. Si está corriendo una instalación Gentoo Hardened con el registrador del sistema syslog-ng, entonces, el registrador ya está configurado para colocar las líneas de auditoría en /var/log/avc.log. Sin embargo, otros registradores de sistema podrían colocar estas entradas en una ubicación diferente (por ejemplo /var/log/audit.log).

Abajo encontrará las líneas para la configuración apropiada del registrador del sistema syslog-ng de modo que escriba los eventos en el fichero /var/log/avc.log.

Listado de Código 2.1: Extracto de syslog-ng.conf para las entradas AVC de SELinux

# ¡Las siguientes líneas son solo una parte del fichero de configuración!
source kernsrc  { file("/proc/kmsg");       };
destination avc { file("/var/log/avc.log"); };
filter f_avc    { message(".*avc: .*");     };

log {
  source(kernsrc);
  filter(f_avc);
  destination(avc);
};

¿Qué es AVC?

Como ya hemos mencionado, SELinux escribe sus entradas en el registro de auditoría. Estas entradas se llaman mensajes avc o entradas de registro avc. El acrónimo AVC significa Access Vector Cache (Caché de Acceso Vectorial), tal y como indica su nombre, se trata de un sistema caché.

Utilizar un sistema cache de acceso vectorial mejora el rendimiento cuando se trata con (y se fuerzan) actividades y privilegios. Ya que SELinux ofrece un enfoque muy detallado sobre privilegios y permisos, sería tremendamente penoso (en lo que se refiere a rendimiento) si cada llamada supusiera buscar el dominio, el recurso destino, el privilegio y si está permitido o no, esto una y otra vez. En lugar de esto, SELinux utiliza la Caché de Acceso Vectorial para almacenar las solicitudes y respuestas pasadas. Es es sistema AVC el responsable de comprobar los accesos y (si es necesario) registrarlos.

Leyendo un mensaje de denegación en la AVC

Abajo encontrará un mensaje típico de denegación en la AVC.

Listado de Código 2.2: Ejemplo de mensaje de denegación en la AVC

Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472):
  avc:  denied  { module_request } for  pid=14561 comm="firefox" kmod="net-pf-10"
  scontext=staff_u:staff_r:mozilla_t tcontext=system_u:system_r:kernel_t tclass=system

Analicemos cada una de las partes de este mensaje una a una.

Listado de Código 2.3: Denegación AVC: Fecha, hora e información de la ubicación

Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472):
  avc:  denied  { module_request } for  pid=14561 comm="firefox" kmod="net-pf-10"
  scontext=staff_u:staff_r:mozilla_t tcontext=system_u:system_r:kernel_t tclass=system

La primera parte del mensaje le informa del momento en el que se escribió el mensaje (Oct 15 13:04:54), en qué equipo (hpl) y cuántos segundos transcurrieron desde que se inició el sistema (963185.177043).

Listado de Código 2.4: Denegación AVC: información fuente

Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472):
  avc:  denied  { module_request } for  pid=14561 comm="firefox" kmod="net-pf-10"
  scontext=staff_u:staff_r:mozilla_t tcontext=system_u:system_r:kernel_t tclass=system

La información que aparece después es el origen de la denegación, es decir, qué proceso está intentando hacer qué cosa. En este caso, el proceso es firefox, con identificador de proceso (PID) 14561, el cual está corriendo en el dominio fuente staff_u:staff_r:mozilla_t.

Listado de Código 2.5: Denegación AVC: recurso destino

Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472):
  avc:  denied  { module_request } for  pid=14561 comm="firefox" kmod="net-pf-10"
  scontext=staff_u:staff_r:mozilla_t tcontext=system_u:system_r:kernel_t tclass=system

El destino de la actividad es un módulo del núcleo (net-pf-10, el cual es el nombre interno que se le da a IPv6), etiquetado system_u:system_r:kernel_t

Listado de Código 2.6: Denegación AVC: acción denegada

Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472):
  avc:  denied  { module_request } for  pid=14561 comm="firefox" kmod="net-pf-10"
  scontext=staff_u:staff_r:mozilla_t tcontext=system_u:system_r:kernel_t tclass=system

Por último, aparece la acción que ha sido denegada (module_request) y su clase (system). Estas clases le ayudan a identificar qué es lo que se ha denegado, ya que leer un fichero no el lo mismo que leer un directorio.

Por ejemplo, en el siguiente caso, un proceso gorg con identificador (PID) 13935 está intentando leer un fichero llamado localtime con inodo 130867 el cual se encuentra en el dispositivo /dev/md3:

Listado de Código 2.7: Ejemplo de denegación AVC

Oct 15 14:40:30 hpl kernel: [968909.807802] type=1400 audit(1318682430.323:2614):
  avc:  denied  { read } for  pid=13935 comm="gorg" name="localtime" dev=md3 ino=130867
  scontext=staff_u:sysadm_r:gorg_t tcontext=system_u:object_r:locale_t tclass=file

En este caso debería ser obvio que el fichero es /etc/localtime, sin embargo, cuando este no es el caso, las dos órdenes siguiente pueden ser útiles:

Listado de Código 2.8: Encontrar el recurso destino basándose en el inodo y dispositivo

(Encontrar el dispositivo /dev/md3)
# mount | grep /dev/md3
/dev/md3 on / type ext4 (rw,seclabel,noatime,barrier=1,nodelalloc,data=journal)

(Encontrar qué fichero tiene el inodo 130867)
# find / -xdev -inum 130867
/etc/localtime

Gestionar las denegaciones AVC

La mayor parte del trabajo para configurar SELinux es la lectura de las denegaciones y encontrar lo que debe ser corregido (o ignorado), corregirlo y repetir el proceso. Con un poco de suerte, el resto de este manual le ayudará a averiguar lo que está causando la denegación.

Las denegaciones pueden ser cosméticas (una actividad que se deniega pero que no tiene impacto en el comportamiento funcional de la aplicación). Si este es el caso, se puede marcar la denegación como dontaudit, (no auditar) indicando que, por defecto, la denegación ya no será registrada. Si cree que se está denegando algo pero no lo ve en el registro, intente deshabilitar las reglas dontaudit:

Listado de Código 2.9: Deshabilitar dontaudit

(Esta orden también se puede abreviar como "semodule -DB")
# semodule --build --disable_dontaudit

En la mayoría de los casos, se debe actuar sobre las denegaciones. Las acciones que entonces necesitará realizar son:

  • Etiquetar de nuevo el recurso destino (las etiquetas erróneas pueden causar que acciones legítimas sean denegadas)
  • Etiquetar de nuevo el origen (el fichero binario del proceso) ya que una etiqueta errónea puede causar que la aplicación se ejecute en el dominio incorrecto.
  • Cargar el módulo SELinux necesario, ya que los módulos contienen reglas para permitir (y etiquetar) recursos. Sin el módulo correcto cargado, observará algunas denegaciones ya que no hay ningún módulo que realice las concesiones necesarios (sentencias para permitir las acciones).
  • Conceder el rol adecuado al usuario que ejecuta la aplicación. Hemos cubierto los usuarios y sus roles inicialmente, sin embargo, profundizaremos en esto más adelante en este manual.
  • Añadir sus propias sentencias de directriz SELinux, principalmente porque no existen módulos de directriz SELinux para la aplicación que está intentando ejecutar.

2.c. Utilizar etiquetas (de fichero)

Introducción

Dentro de SELinux, los privilegios de acceso se basan en la etiqueta que se da a la parte original (llamada domain) y a su recurso destino. Por ejemplo, un proceso que corre en el dominio passwd_t quiere leer (tener privilegio) el fichero /etc/shadow que está marcado shadow_t (el recurso destino). No es sorprendente que la mayoría de la administración de SELinux consiste en (re)etiquetar los recursos de forma adecuada (y asegurarse que su etiqueta permanece correcta).

Obtener etiqueta(s) de fichero

Existen varias formas de etiquetar de nuevo las órdenes y muchas de ellas son iguales. Pero, antes de explicar esto más en detalle, echaremos un vistazo a algunas etiquetas de fichero (y a cómo puede consultarlas).

En SELinux, las etiquetas se asignan al nivel del fichero a través de la capacidad del sistema de mantener atributos extendidos. Para SELinux, los atributos se llaman security.selinux y se pueden obtener usando getfattr:

Listado de Código 3.1: Obtener el atributo extendido de un fichero en SELinux

$ getfattr -n security.selinux /etc/hosts
# file: etc/hosts
security.selinux="system_u:object_r:net_conf_t"

Desde luego, obtener el atributo del fichero de esta forma, requiere mucho tiempo y no es flexible. Para este propósito, la aplicaciones más importante (incluyendo coreutils) se hacen compatibles con SELinux. Estas aplicaciones en la mayoría de las ocasiones utilizan la opción -Z para mostrar la información de contexto de SELinux. En el caso de ficheros, esto implica el contenido de los atributos extendidos.

Listado de Código 3.2: Obtener el contexto de un fichero

$ ls -Z /etc/hosts
system_u:object_r:net_conf_t   /etc/hosts

Existen otras órdenes como matchpathcon que muestran el contexto tal como debería ser. Sin embargo, su propósito es consultar la directriz SELinux en su sistema para averiguar la directriz que debería usarse, no la que se utiliza:

Listado de Código 3.3: Diferencia entre resultados de contexto y resultados de matchpathcon

$ ls -Z /etc/portage/make.conf
staff_u:object_r:etc_t    /etc/portage/make.conf
$ matchpathcon /etc/portage/make.conf
/etc/portage/make.conf            system_u:object_r:portage_conf_t

Ajustando la(s) etiqueta(s) de fichero

Y ahora, ¿Cómo podemos manipular las etiquetas de fichero?. Bien, en primer lugar: no se le permitirá cambiar las etiquetas de un fichero (incluso si es el propietario del mismo) a menos que la directriz SELinux se lo permita. Estas reglas de concesión se realizan sobre dos tipos de privilegios: Las etiquetas que puede cambiar (relabelfrom) y a qué etiquetas puede cambiar (relabelto). Puede consultar estar regals usando sesearch:

Listado de Código 3.4: Consultar los tipos relabelto y relabelfrom

# Desde qué etiqueta en los ficheros (-c) se permite (-A) a user_t (-s) etiquetar de nuevo (-p)?
$ sesearch -s user_t -c file -p relabelfrom -A
[...]
allow user_t mozilla_home_t : file { ... relabelfrom relabelto } ;

Si tiene permiso, entonces puede utilizar chcon para cambiar (ch) el contexto de un fichero:

Listado de Código 3.5: Cambiar el contexto de un fichero

$ ls -Z strace.log
staff_u:object_r:user_home_t  strace.log
$ chcon -t mutt_home_t strace.log
$ ls -Z strace.log
staff_u:object_r:mutt_home_t  strace.log

Si no posee los privilegios adecuados, obtendrá un mensaje de error descriptivo:

Listado de Código 3.6: Intentar cambiar el contexto de un fichero

$ chcon -t shadow_t strace.log
chcon: failed to change context of `strace.log' to `staff_u:object_r:shadow_t': Permission denied

Ahora, si cree que todo lo que necesita es la orden chcon, no está en lo cierto. La orden chcon no hace nada más que lo que dice: cambiar el contexto. Cuando el sistema etiqueta de nuevo los ficheros, los cambios se van. El reetiquetado de los ficheros se realiza a menudo para asegurarse de que las etiquetas son las correctas (es decir, las etiquetas concuerdan con lo que la directriz SELinux dice que debería ser). La directriz SELinux contiene, para cada módulo de directriz, la lista de ficheros, directorios, zócalos (sockets), ... y sus contextos de fichero apropiados (etiqueta).

Echaremos un vistazo a los módulos de directriz de SELinux más adelante. Abajo puede encontrar un extracto de esta definición para el módulo mozilla:

Listado de Código 3.7: Extracto de los contextos de fichero del módulo mozilla

/usr/bin/firefox-bin                            -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/usr/bin/mozilla-[0-9].*                        -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/usr/bin/mozilla-bin-[0-9].*                    -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/usr/lib(64)?/galeon/galeon                     -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/usr/lib(64)?/netscape/.+/communicator/communicator-smotif\.real -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/usr/lib(64)?/netscape/base-4/wrapper           -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/usr/lib/[^/]*firefox[^/]*/plugin-container     -- gen_context(system_u:object_r:mozilla_plugin_exec_t,s0)
/usr/lib64/[^/]*firefox[^/]*/plugin-container   -- gen_context(system_u:object_r:mozilla_plugin_exec_t,s0)

Para poner la etiqueta adecuada a un fichero, puede utilizar las órdenes setfiles o restorecon. Debido a que ambas son la misma orden (pero con una forma ligeramente diferente de utilización), ahora hablaremos solo de restorecon. Se puede encontrar más información acerca de la orden setfiles en su página del manual.

Cuando utilice restorecon, la aplicación consultará la directriz SELinux para averiguar qué etiqueta debería ser la correcta para el fichero. Si ésta es diferente, cambiará la etiqueta para que sea la adecuada. Esto significa que no necesita ofrecer la etiqueta a un fichero para que funcione la orden correspondiente. También, restorecon soporta recursión, por lo que no necesita etiquetar de nuevo los ficheros uno a uno.

Listado de Código 3.8: Usar restorecon

$ ls -Z /etc/portage/make.conf
staff_u:object_r:etc_t            /etc/portage/make.conf
$ restorecon /etc/portage/make.conf
$ ls -Z /etc/portage/make.conf
system_u:object_r:portage_conf_t  /etc/portage/make.conf

Por último, Gentoo también ofrece una aplicación muy útil: rlpkg. Este guión etiqueta de nuevo los ficheros de un paquete Gentoo package (rlpkg <nombredepaquete>) o, dando los argumentos adecuados, todos los ficheros del sistema.

Listado de Código 3.9: Usar rlpkg

# Etiquetar de nuevo los ficheros del paquete firefox-bin:
# rlpkg firefox

# Etiquetar de nuevo todos los ficheros del sistema:
# rlpkg -a -r

Saltándose las etiquetas de fichero de la directriz de SELinux

Puede que no esté siempre de acuerdo con la etiqueta que la directriz de SELinux fuerza a los ficheros: puede que tenga sus ficheros ubicados en otro lugar (una localización diferente de su árbol Portage es un buen ejemplo) o quizá necesite etiquetarlos de forma diferente para que funcionen otras aplicaciones. Para no tener que chcon estos ficheros una y otra vez, puede mejorar la directriz SELinux en su sistema con reglas adicionales de contextos de fichero. Estas reglas también se utilizan cuando llama a restorecon y se salta las reglas ofrecidas por la directriz SELinux.

Para añadir reglas de contexto de fichero adicionales, necesitará usar la orden semanage. Esta orden se utiliza para manipular y actualizar la directriz local de SELinux en su sistema. En este caso en particular, utilizaremos la orden semanage fcontext:

Listado de Código 3.10: Usar semanage para añadir una regla de contexto de fichero

# Marcar /mnt/gentoo/etc/portage/make.conf como un tipo portage_conf_t
# semanage fcontext -a -t portage_conf_t /mnt/gentoo/etc/portage/make.conf

# Marcar /mnt/gentoo/usr/portage como portage_ebuild_t
# semanage fcontext -a -t portage_ebuild_t "/mnt/gentoo/usr/portage(/.*)?"

Como puede observar en el ejemplo, puede utilizar caracteres comodín: cuando una regla tiene caracteres comodín, tiene menor prioridad que una regla que no los tiene. La prioridad de las reglas con caracteres comodín se basa en lo "bajo" que está la cadena con la primera ocurrencia del carácter comodín. Para más información, por favor, consulte nuestras Preguntas Frecuentes: ¿Cómo averiguo qué regla de contexto de fichero se está utilizando para un fichero en particular?.

Si quiere eliminar una definición de contexto de fichero, puede utilizar semanage fcontext -d:

Listado de Código 3.11: Eliminar una definición de contexto de fichero

# semanage fcontext -d -t portage_ebuild_t /mnt/gentoo/etc/portage/make.conf

Por último, para ver todas las definiciones de contexto de fichero (tanto las definidas por el usuario como las ofrecidas por la directriz SELinux), puede utilizar semanage fcontext -l. Para ver únicamente el conjunto local, añada -C:

Listado de Código 3.12: Ver las mejoras en el contexto de ficheros definidas por el usuario

# semanage fcontext -C -l
SELinux fcontext                          type             Context
/opt/xxe/bin/.*\.jar                      all files        system_u:object_r:lib_t
/srv/virt/gentoo(/.*)?                    all files        system_u:object_r:qemu_image_t

Tipos personalizables

No es muy difícil comprender cómo funcionan las etiquetas sobre los ficheros, sin embargo, puede encontrarse alguna sorpresa si no conoce los tipos personalizables.

Un tipo personalizable es un tipo específico que por defecto no es modificado por las herramientas de administración de SELinux. Si quiere etiquetar de nuevo un fichero que actualmente posee un tipo personalizable, necesitará forzarlo usando algunas órdenes (por ejemplo restorecon -F).

No existe muchos tipos personalizables por defecto. La lista de tipos que SELinux considera personalizables se indican en el fichero customizable_types en la ubicación /etc/selinux/*/contexts:

Listado de Código 3.13: Listar los tipos personalizables

# cat /etc/selinux/strict/contexts/customizable_types
mount_loopback_t
public_content_rw_t
public_content_t
swapfile_t
textrel_shlib_t

Estos tipos existen porque se utilizan para los ficheros cuya ubicación no es fija (y por lo tanto, la directriz de SELinux no puede asegurar si la etiqueta de los ficheros es correcta o no). El tipo public_content_t, que se utiliza para ficheros que se van a leer por varios servicios (por ejemplo, FTP, servidor web, ...) debería darle una idea de este tipo de ficheros.

Si mira en la página del manual de restorecon, se mencionan tanto los tipos personalizables como la sección de usuario. Esta última es para las reglas que se identifican en la directriz de SELinux para ficheros de un usuario final, como las siguientes definiciones en el módulo de directriz mozilla:

Listado de Código 3.14: Definición de sección de usuario dentro del módulo mozilla

HOME_DIR/\.mozilla(/.*)?      gen_context(system_u:object_r:mozilla_home_t,s0)
HOME_DIR/\.netscape(/.*)?     gen_context(system_u:object_r:mozilla_home_t,s0)
HOME_DIR/\.phoenix(/.*)?      gen_context(system_u:object_r:mozilla_home_t,s0)

Aunque en el ejemplo de arriba, forzar restorecon en los ficheros es probablemente correcto, se pueden dar ejemplos en los que ésto no se desea. Por ejemplo, la directriz firefox por defecto únicamente permite a la aplicación escribir en los directorios etiquetados con mozilla_home_t. Si se quiere descargar algo, esto es imposible (a menos que lo haga en ~/.mozilla). La solución para esto es etiquetar un directorio (digamos ~/Descargas) con mozilla_home_t.

2.d. Directriz SELinux y Booleanos

Introducción

Hemos tratado con usuarios y etiquetas, pero todavía tenemos que tratar con un tercer aspecto que no hemos tocado: La propia directriz SELinux.

La directriz SELinux tal y como se ofrece en Gentoo Hardened es una directriz cuidadosamente ajustada y basada en la directriz de referencia (una directriz SELinux independiente de toda distribución) con cambios menores. Con suerte, no necesitará escribir de nuevo la directriz para adaptarla a sus necesidades, sin embargo, de vez en cuando son necesarios algunos cambios.

Cambiar el comportamiento de la directriz SELinux: Booleanos

Una forma común y agradable de ajustar la directriz SELinux es mediante el uso de un booleano. Un booleano SELinux, también llamado condicional, modifica el comportamiento de la directriz SELinux basándose en los ajustes que realiza el usuario. Para clarificar esto un poco, echemos un vistazo a algunos de los booleanos disponibles:

Listado de Código 4.1: Obtener los booleanos SELinux

# getsebool -a | grep ^user
user_direct_mouse --> off
user_dmesg --> off
user_ping --> on
user_rw_noexattrfile --> off
user_tcp_server --> off
user_ttyfile_stat --> off

Aunque parece que no hay mucho que decir a primera vista, estos booleanos alteran el modo en que la directriz SELinux fuerza la actividad de los usuarios (de ahí que los booleanos comiencen con user_). Por ejemplo, user_ping esta definido a on, por lo que se permite al usuario utilizar la orden ping. Si se define a off, la directriz SELinux no permitiría al usuario utilizar ping.

Se puede cambiar el valor de un booleanos entre on y off utilizando setsebool o togglesebool. Con setsebool necesitará indicar el valor (on u off), mientras que togglesebool conmuta el valor.

Listado de Código 4.2: Deshabilitar el uso de ping por parte de los usuarios

# setsebool user_ping off

Por defecto, setsebool no almacena los valores booleanos, por lo que después de un reinicio los antiguos valores se cargarán. Para hacer estos cambios persistentes, necesitará añadir la opción -P:

Listado de Código 4.3: Permitir a los usuarios ejecutar dmesg de forma persistente

# setsebool -P user_dmesg on

Los booleanos permiten a los administradores ajustar la directriz, y a los administradores de seguridad escribir directrices que sean los suficientemente flexibles para que su uso se extienda. En términos de la flexibilidad de Gentoo, estos booleanos no deberían usarse demasiado (sería deseable asociar estos booleanos con ajustes USE, de modo que un servidor instalado con USE="ldap" obtenga la directriz SELinux para utilizar, mientras que USE="-ldap" la deshabilita). Aún así, el uso de booleanos es una forma popular para hacer más flexible una directriz SELinux.

Gestionar los módulos de directriz SELinux

En esta última parte, cubriremos los módulos de reglas de la directriz SELinux. Mencionamos anteriormente que la directriz SELinux que usa Gentoo Hardened se basa en la directriz de referencia, la cual ofrece un enfoque modular a las directrices de SELinux. Existe una directriz base que es obligatoria en todos los sistemas y se trata de que sea lo más pequeña posible. El resto son módulos de la directriz SELinux, que normalmente ofrecen las declaraciones, reglas y los contextos de ficheros para una sola aplicación (o tipo de aplicación).

Con semodule -l puede ver la lista de módulos de directriz SELinux que están cargados:

Listado de Código 4.4: Listar los módulos cargados por SELinux

# semodule -l
alsa       1.11.0
apache     2.3.0
entropyd   1.6.0
dbus       1.15.0
dnsmasq    1.9.0
(...)

En Gentoo Hardened, cada módulo se ofrece mediante el paquete sec-policy/selinux-<nombredemódulo>. Por ejemplo, el primer módulo que vemos en el ejemplo de arriba lo ofrece el paquete selinux-alsa:

Listado de Código 4.5: Paquete de módulo de directriz SELinux en Gentoo

$ emerge --search selinux-alsa
Searching...
[ Results for search key : selinux-alsa ]
[ Applications found : 1]

* sec-policy/selinux-alsa
    Latest version available: 2.20110726
    Latest version installed: 2.20110726
    Size of files: 574 kB
    Homepage:      http://www.gentoo.org/proj/en/hardened/selinux/
    Description:   SELinux policy for alsa
    License:       GPL-2

Cuando se necesita un módulo que no está instalado en su sistema, se considera un fallo (los paquetes que lo necesitan deben depender del paquete de la directriz SELinux si se ha definido el ajuste USE selinux). Por esto, una vez que instale el paquete, el módulo se cargará automáticamente:

Listado de Código 4.6: Instalar un paquete de directriz SELinux

# emerge selinux-screen

Si necesita eliminar un módulo de su sistema, desinstalar el paquete no será suficiente: el propio módulo directriz SELinux se copia antes al almacén de directrices (como parte del proceso de instalación) y Portage no lo eliminará de este almacén. Por lo tanto, deberá eliminarlo manualmente:

Listado de Código 4.7: Desinstalar un módulo de directriz SELinux

# emerge -C selinux-screen
# semodule -r screen

2.e. Siguientes pasos

¿Qué hacer ahora?

Hasta ahora, su sistema ha estado corriendo en modo permisivo. Necesitará habilitar el modo forzado antes de estar protegido adecuadamente mediante SELinux. Discutiremos cómo cambiar al modo forzado en Permisivo, no confinado, deshabilitado o lo que no..., pero antes de eso, necesitará tener en cuenta algunas cosas...

Usuarios de Initramfs

Si su sistema utiliza un initramfs para arrancar, no podrá iniciar el sistema directamente en modo forzado (debido a la incidencia #397597). Para evitar esta cuestión, puede crear el siguiente guión de inicio que cambiará de modo permisivo a modo forzado de una forma razonablemente rápida dentro del proceso de inicio (y antes de arrancar los servicios de red):

Listado de Código 5.1: Contenido de /etc/init.d/selinux_enforce

#!/sbin/runscript
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-using-configuring.xml,v 1.7 2013/08/13 14:26:42 nimiux Exp $
description="Switch into SELinux enforcing mode"

depend() {
        need sysfs
}

start() {
       if get_bootparam "norestorecon" ; then
               ewarn "Skipping restoring file contexts in /dev as requested"
       else
               ebegin "Restoring file contexts in /dev"
                       restorecon -R /dev
               eend 0
       fi


       if get_bootparam "nosetenforce" ; then
               ewarn "Skipping switching to enforcing mode as requested by kernel cmdline"
       else
               . /etc/selinux/config
               CURRENTMODE=$(cat /sys/fs/selinux/enforce)

               if [ "${SELINUX}" = "enforcing" ] && [ "${CURRENTMODE}" = "0" ];
               then
                       ebegin "Switching to enforcing mode"
                       echo 1 > /sys/fs/selinux/enforce
                       eend $?
                else
                       ewarn "Not switching to enforcing mode, or enforcing mode already enabled"
                fi
        fi
}

Añada el guión de inicio al nivel de ejecución boot, y edite la configuración de su gestor de arranque para arrancar siempre con la definición enforcing=0. El guión de inicio actualizará los contextos de fichero en /dev y a continuación, si su sistema está configurado para arrancar en modo forzado, cambiará a ese modo.

Si necesita permanecer en modo permisivo de forma temporal, puede añadir nosetenforce como parámetro de inicio (después de enforcing=0) lo cual evitará el paso setenforce).

Usuarios de entornos gráficos

Si arranca en un entorno gráfico (es decir, si utiliza GDM, KDM u otro gestor gráfico de acceso al sistema), necesitará actualizar el(los) fichero(s) de configuración PAM de los gestores mediante las siguientes indicaciones:

Listado de Código 5.2: Ejemplo de actualización del fichero de configuración LXDM PAM

# /etc/pam.d/lxdm
# [...]
session    required     pam_loginuid.so
session    optional     pam_gnome_keyring.so auto_start
session optional     pam_selinux.so

Esto asegurará que el contexto de seguridad en el que ha accedido al sistema está definido correctamente. Actualizaremos los paquetes que definen esos ficheros PAM de forma adecuada, pero esto nos llevará algún tiempo.


[ << ] [ < ] [ Inicio ] [ > ] [ >> ]


Imprimir

Ver completo

Página actualizada 10 de agosto, 2013

Sumario: Con SELinux ahora "instalado" y habilitado (aunque funcionando en modo permisivo), podemos configurarlo para que se adapte a nuestra necesidades particulares. Después de todo, SELinux es un sistema de Control de Acceso Obligatorio en el cual, como administrador de seguridad, pude definir lo que está permitido y lo que no.

Chris PeBenito
Autor

Sven Vermeulen
Autor

Chris Richards
Autor

José María Alonso
Traductor

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.