Gentoo Logo

Renuncia de responsabilidad: Este documento ya no es válido y carece de soporte.


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


2. Conceptos detrás de SELinux

Contenido:

2.a. Introducción

Conceptos detrás de SELinux

Debido a que SELinux es un sistema MAC, probablemente se habrá dado cuenta de que la gestión de los permisos y privilegios basados en SELinux va a ser un poco más complicada que la gestión de privilegios en un control de acceso discrecional que es el que se utiliza generalmente en un sistema Linux. Algo importante a tener en cuenta es que SELinux trabaja encima del sistema DAC que es el que utiliza todo el mundo en Linux. Siendo un administrador de sistemas, necesitará familiarizarse con algunos conceptos y estructuras que SELinux ha colocado para gestionar el acceso a estos sistemas.

El propósito de este capítulo es La descripción de estos conceptos. Daremos ejemplos de estos conceptos en un sistema Gentoo Hardened con SELinux habilitado. Sin embargo, no se preocupe si el uso de algunas órdenes en particular no se detalla suficientemente. Se muestran únicamente como ejemplos (lo que se aprenda de esto es más importante) y será discutido más abajo en este documento.

Directrices de SELinux

Dentro de Gentoo (y también dentro de otras distribuciones), SELinux es soportado por varios niveles de directriz. Estos son, en orden ascendente en complejidad (significando que pueden ofrecer mayor seguridad pero que son más difíciles de gestionar):

  1. targeted es una directriz en la que los servicios que utilizan la red (demonios) están confinados (los procesos solo pueden ejecutar aquellas acciones que estén definidas en la directriz). Sin embargo, otras aplicaciones corren en el llamado unconfined (no confinado), lo que indica que hay muy pocas restricciones para estos procesos.
  2. strict es una directriz en la que todos los procesos están confinados. No existen dominios no confinados. En otras distribuciones, esta es considerada la directriz targeted pero sin la definición de dominio no confinado.
  3. multi-category security es una directriz en la que los dominios (confinados) pueden ser categorizados (clasificados), permitiendo que múltiples procesos corran en diferentes instancias de un dominio confinado.
  4. multi-level security es una directriz en la que existen reglas relativas a la sensibilidad de dominios y recursos. Esto permite una directriz de flujo de información "adecuada" (asegurándose de que la información sensible no se filtra a través de dominios con menores privilegios). Conceptualmente, esto se puede comprender mejor si se consideran los niveles de sensibilidad Público, Interno, Confidencial, Estrictamente confidencial, etc.

Cuando se utiliza Gentoo Hardened, todas estas directrices están disponibles. Sin embargo el desarrollo se centra principalmente en strict y mcs (multi-category security). Se asume que la directriz targeted funciona si funciona la directriz strict aunque sabemos que la directriz mls (multi-level security) no está preparada para el uso en producción.

Nota: Para aclarar posibles confusiones, especialmente cuando se intenta buscar soporte fuera de Gentoo: nuestra implementación "strict" no es la implementación que era "strict" hasta el año 2008. El antiguo significado de "strict" involucraba una implementación diferente de la directriz.

2.b. Contextos de seguridad

Usuarios, Roles y Dominios

Uno de los primeros conceptos con los que debe familiarizarse es el de contexto de seguridad. Se trata de un estado que se asigna a un recurso de modo que identifica únicamente qué concesiones (permisos) se dan al recurso. Este contexto es extremadamente importante para SELinux ya que es la definición en la cual basa sus permisos (concesiones o revocaciones). Cuando un recurso no tiene un contexto asignado, SELinux intentará darle un contexto de seguridad por defecto, el cual, considerando la filosofía del menor privilegio posible, tiene pocos permisos para realizar cualquier acción.

En el marco de SELinux, este contexto de seguridad se muestra usando de tres a cinco definiciones, dependiendo del tipo de directriz que se esté utilizando:

user
El usuario SELinux (no el mismo que el usuario técnico de Linux/Unix) asignado al recurso.
role
El rol SELinux en el que el recurso trabaja actualmente.
type
El tipo asignado al recurso, la clave para las reglas de reforzamiento de SELinux.
sensitivity
Este es un nivel dado a un recurso informado al sistema sobre la sensibilidad de este recurso. La sensibilidad es algo relacionado con Publico, Interno, Restringido, Confidencial, Estrictamente confidencial, ... Los niveles de sensibilidad están soportados únicamente por las directrices MLS.
category
Se trata de una instanciación específica de un recurso. Permite la segregación de recursos incluso si son del mismo tipo. Se hablará más acerca de las categorías más adelante. Las categorías están soportadas únicamente por las directrices MLS y MCS.

Se dará más información sobre estas definiciones en particular a lo largo de este capítulo.

Como ejemplo, echemos un vistazo al contexto de seguridad de un usuario que ha ingresado en el sistema:

Listado de Código 2.1: Obtener el contexto de seguridad de un usuario que ha ingresado en el sistema

~$ id -Z
staff_u:staff_r:staff_t

En este caso, el usuario está identificado como el usuario SELinux staff_u, que actualmente tiene el rol staff_r y está asignado al tipo staff_t. Las acciones que se permiten a este usuario están basadas en este contexto de seguridad. También, observará que únicamente se muestran tres identificadores. Esto es debido a que se ha tomado el ejemplo de un sistema con directriz strict (o targeted). El siguiente ejemplo da el mismo resultado pero para una sistema con directriz MCS.

Listado de Código 2.2: Obteniendo el contexto de seguridad de un usuario que ha ingresado en un sistema con directriz MCS

~$ id -Z
staff_u:staff_r:staff_t:s0-s0:c0.c1023

Aquí, el usuario está corriendo con el nivel de sensibilidad s0 (el cual, en un sistema con directriz MCS, el el único disponible) y con una categoría c0 hasta c1023 (inclusive). Sin embargo, observe que en un sistema con directriz MCS, las categorías son opcionales, por lo que deberá ver una salida del tipo: staff_u:staff_r:staff_t:s0.

Directrices de control de acceso

Como ya se ha mencionado, estos contextos de seguridad se usan como base de las reglas de permisos. Lo que hace SELinux es comprobar el contexto de seguridad de la fuente (por ejemplo un proceso) y del destino (por ejemplo un fichero que el proceso necesita leer). Entonces se comprueba si la operación solicitada (lectura) está permitida entre estos dos contextos. Recuerde que SELinux trabaja encima del sistema de permisos estándar usados en Linux. Si un proceso no puede, en principio, leer un fichero, ni siquiera se consulta a SELinux.

Hasta ahora, el contexto de seguridad define el estado de un recurso, sin embargo, no hemos hablado de los recursos en sí. En el marco de SELinux, los tipos de recursos están definidos como clases de objetos. Ejemplos muy comunes son file o dir. SELinux también gestiona clases como filesystem, tcp_socket, process, sem (semáforos) y mucho más.

En cada clase de objeto, se declara un conjunto de permisos, los cuales son aplicables a un recurso de esta clase de objeto. Por ejemplo, la clase de objeto process soporta cuanto menos los siguientes permisos:

Listado de Código 2.3: Permisos soportados para un recurso 'process'

~# ls /selinux/class/process/perms
dyntransition  getcap      rlimitinh     setpgid        siginh
execheap       getpgid     setcap        setrlimit      sigkill
execmem        getsched    setcurrent    setsched       signal
execstack      getsession  setexec       setsockcreate  signull
fork           noatsecure  setfscreate   share          sigstop
getattr        ptrace      setkeycreate  sigchld        transition

La regla más común de SELinux para el control de acceso (allow) se describe de la siguiente forma:

Listado de Código 2.4: La sentencia SELinux allow

allow ACTOR  TARGET:CLASS PRIVILEGE;
      +-+-+  +-+--+ +-+-+ +---+---+
        |      |      |       `- Permiso a conceder (como "write")
       |      |      `- Clase a la que se da el permiso (como "file")
       |      `- Recurso (etiqueta) en la que el permiso es válido (como "portage_conf_t")
       `- Actor (dominio) que obtiene el privilegio (como "sysadm_t")

Echemos un vistazo a un pequeño ejemplo que explica las reglas de permisos y cómo las utiliza SELinux. El usuario ejemplo está en el contexto staff_u:staff_r:staff_t y desea escribir en su propio directorio. Lo lógico sería que se le permitiera esta acción. No se preocupe por las órdenes mostradas aquí, las discutiremos en detalle más abajo en este mismo documento.

Listado de Código 2.5: Comprobar si un usuario puede escribir en su propio directorio home

(Muestra el contexto de seguridad para el directorio home del usuario)
~$ ls -dZ ${HOME}
staff_u:object_r:user_home_dir_t  /home/swift

(Busca la regla que permite al tipo staff_t escribir en un directorio con el tipo user_home_dir_t type)
~$ sesearch -s staff_t -t user_home_dir_t -c dir -p write -A
Found 1 semantic av rules:
  allow staff_t user_home_dir_t : dir { ioctl read write create ... };

Como era de esperar, el contexto de seguridad del usuario (para ser más específico, el dominio en el que reside) tiene acceso de escritura al dominio de los directorios destino. La noción de dominio aparece frecuentemente en la documentación de SELinux y se refiere al tipo asignado a un proceso. Por cierto, como los ficheros no tienen ningún rol, SELinux les asigna el rol por defecto object_r.

Ahora echemos un vistazo al siguiente ejemplo. Nuestro usuario, que pertenece al grupo portage, quiere escribir en el directorio /var/tmp/portage:

Listado de Código 2.6: Comprobar si un usuario puede escribir en el directorio /var/tmp/portage

~$ id -a
uid=1001(swift) gid=100(users) groups=100(users),...,250(portage),...
~$ ls -ldZ /var/tmp/portage
drwxrwxr-x. 3 portage portage  system_u:object_r:portage_tmp_t 4096 Dec  6 21:08 /var/tmp/portage

Desde le punto de vista de los permisos estándar de Linux, el usuario tiene permiso para escribir. Pero, ¿Le permitirá SELinux hacerlo?

Listado de Código 2.7: Intentar escribir en /var/tmp/portage

~$ sesearch -s staff_t -t portage_tmp_t -c dir -p write -A
~$
(Observe que no se obtiene ninguna información)
~$ touch /var/tmp/portage/foo
touch: no se puede efectuar `touch' sobre «/var/tmp/portage/foo»: Permiso denegado

Como SELinux no pudo encontrar una regla que permitiera al dominio staff_t escribir en cualquier directorio etiquetado con el tipo portage_tmp_t type, se denegó el acceso.

2.c. Forzado de tipos / Tipos de dominio

Tipos y dominios

Para explicar como funcionan las reglas de permisos y como se fuerzan mediante los contextos de seguridad, comencemos con la última definición en el contexto (el tipo) y trabajemos hacia los roles y usuarios.

  • Un tipo SELinux es una etiqueta en particular que se asigna a un recurso. Por ejemplo, la orden passwd está etiquetada con el tipo passwd_exec_t.
  • Un dominio SELinux es el estado de seguridad de un proceso e identifica los derechos y permisos que posee. Normalmente, nos referiremos a él por su declaración de tipo. Por ejemplo, el dominio para una orden passwd es passwd_t.

Las reglas que identifican las acciones permitidas para un dominio ya se han descrito anteriormente, las citamos de nuevo:

Listado de Código 3.1: Reglas estándar de las directrices SELinux

allow <src_domain> <dst_type> : <class> { permiso [ permiso [ ... ] ] } ;

Un ejemplo del dominio passwd_t podrían ser los permisos concedidos entre el dominio passwd_t y el tipo shadow_t (usado por el fichero /etc/shadow).

Listado de Código 3.2: Concesiones entre passwd_t y shadow_t

allow passwd_t shadow_t : file { ioctl read write create ... } ;

Esta sintaxis de permisos es muy potente, pero también complicada. Para tener un sistema seguro en el que se permite un comportamiento normal, necesitará ajustar finamente estas reglas para todas y cada una de las aplicaciones (y de igual forma para los dominios) que desea albergar en su sistema. Dar permisos de forma extensiva a un dominio en un tipo en particular, puede resultar en la pérdida de eficiencia e incluso de efectividad.

Para soportar reglas de concesión de forma más sencilla, SELinux permite el agrupamiento de tipos usando los atributos de tipos. Por ejemplo, el atributo exec_type agrupa todos los tipos que se asignan a los ficheros ejecutables (como bin_t, ssh_exec_t, ...), mientras que el atributo file_type agrupa todos los tipos que se asignan a ficheros regulares. Aunque esto pueda simplificar la gestión de las reglas, puede resultar en que se asignen sin quererlo más permisos de los que se desean asignar.

Transiciones de dominio

Hasta aquí hemos hablado de tipos, definiciones de dominios y sus permisos. Hemos comentado previamente que los permisos están basados en el dominio en el que reside un proceso. Pero, ¿cómo llega un proceso a ser parte de un dominio? Podrá pensar que esto ocurre de una forma prefijada (ejecutar la orden passwd conllevaría que el proceso se asociara al dominio passwd_t), de hecho, esto se realiza mediante la combinación de tres privilegios muy específicos que deben ser concedidos:

  1. Se debe permitir al dominio actual la transición a otro dominio.
  2. El dominio destino debe tener un punto de entrada, que es un ejecutable, al cual se le permite arrancar en el dominio.
  3. El dominio fuente debe tener permisos de ejecución (en el dominio) sobre ese ejecutable.

Importante: El hecho de que no se permita la transición, no significa que no se pueda ejecutar el binario. El binario puede ser ejecutado, pero no lo hará dentro del dominio destino. En lugar de eso, heredará el dominio del ejecutor y por lo tanto los permisos y derechos de ese dominio.

Usando estas reglas, el administrador de la seguridad de un sistema puede controlar de forma más específica quién y bajo qué condiciones se pueden realizar acciones particulares.

2.d. Roles y derechos

El rol de un rol

Los dominios y las reglas de dominio expuestas anteriormente son bastante potentes. Sin embargo, SELinux ofrece mucho más. Después de todo, debe ser posible denegar el acceso a dominios particulares a usuarios no autorizados. Un requisito es, desde luego, no permitir transiciones desde el dominio del usuario a un dominio restringido, pero, ¿cómo se permite a un conjunto de usuarios mientras que se deniega a otro?

Presentaremos los roles. Usando roles, puede indicarle a SELinux qué dominios se permiten para un rol y cuales no. Un ejemplo podría ser el dominio ifconfig_t. Este dominio tiene los derechos para cambiar las definiciones de las interfaces de red, lo cual es algo que no debe permitir a sus usuarios. Y, de hecho, si pudiera verificarlo, SELinux no permite asignar el rol de usuario user_r al dominio ifconfig_t.

Listado de Código 4.1: Comparación de user_r y sysadm_r para el dominio ifconfig_t

~$ seinfo -ruser_r -x
  user_r
    Dominated Roles:
      user_r
    Types:
      ...
~$ seinfo -rsysadm_r -x
  sysadm_r
    Dominated Roles:
      sysadm_r
    Types:
      ...
      ifconfig_t
      ...

Importante: De nuevo, el hecho de no poder asociar un dominio, no significa que el rol user_r no pueda ejecutar el binario ifconfig. Puede, pero ejecutará este binario en su propio dominio (user_t). Este dominio no tiene derechos para manipular la interfaces de red (sin embargo puede leer información del interfaz aunque con información limitada).

Los roles se usan a menudo en sistemas de control de acceso para agrupar permisos en un solo conjunto funcional (el rol), el cual se puede asignar a individuos (cuentas). Por ejemplo, estos sistemas de control de acceso crean roles para contables, operadores, administradores,... y conceden los privilegios apropiados a estos roles. Entonces, a estos usuarios se les asigna uno (o a veces varios) roles y los usuarios heredan los permisos asignados a estos roles.

En SELinux, se usa esta idea (se usan roles para diferenciar privilegios de forma funcional), sin embargo se implementa de forma distinta: a los roles se le asignan dominios destino en los que se permite que un rol "pueda entrar". Los permisos permanecen asignados a los dominios.

Transiciones de rol

Los usuarios (y los procesos) pueden cambiar de rol. En SELinux se permite, pero únicamente cuando se concede la posibilidad de cambiar. Por defecto, las directrices de SELinux usadas en Gentoo Hardened ofrecen cinco roles en un sistema SELinux:

object_r
El rol object_r es el único rol disponible por defecto en SELinux. Normalmente solo se asigna a recursos en los que no se puede obtener ningún valor o rendimiento del sistema de roles (como en ficheros y directorios).
system_r
El rol system_r se usa para servicios del sistema con muchos privilegios. Se permite al rol system_r cambiar a cualquier otro rol definido por "defecto". Ningún rol excepto sysadm_r puede cambiar al rol system_r.
sysadm_r
El rol sysadm_r se usa para actividades de administración del sistema. Se permite al rol sysadm_r cambiar a cualquier otro rol definido por "defecto". Únicamente se permite a los roles system_r y staff_r cambiar al rol sysadm_r.
staff_r
El rol staff_r se asigna a los operadores del sistema que deberían tener derechos para realizar tareas de administración. Al rol staff_r se le permite cambiar únicamente al rol sysadm_r. Solo sysadm_r y system_r pueden cambiar al rol staff_r.
user_r
El rol user_r se asigna a usuarios estándar y sin muchos privilegios. No se permite la transición a ningún otro rol; únicamente se permite a los roles sysadm_r y system_r cambiar al rol user_r.

Nota: Los roles por "defecto" son: user_r, staff_r, sysadm_r y system_r. Si se crean roles adicionales, éstos no serán parte del los roles por "defecto".

Usando estas definiciones, un usuario dentro del rol user_r nunca podrá ejecutar ifconfig en el dominio ifconfig_t. El uso de la palabra nunca es importante: no podrá, incluso si el usuario puede usar la cuenta root mediante sudo o cualquier otra orden que permita ejecutar ifconfig en el dominio ifconfig_t, porque, a pesar de que ha ejecutado sudo, el usuario está utilizando el rol user_r.

Usuarios de SELinux

Un usuario de SELinux no es lo mismo que un usuario Linux. Mientras que se puede cambiar de una cuenta de usuario estándar de Linux a otra usando órdenes como su o sudo, un usuario SELinux no se puede cambiar. Incluso cuando ejecute con éxito sudo, su usuario SELinux seguirá siendo el mismo.

Cuando observe un sistema gestionado con SELinux, podrá ver que ese sistema no tiene muchos usuarios SELinux. Por ejemplo, la configuración por defecto de Gentoo Hardened define los usuarios root, user_u, staff_u, sysadm_u y system_u y en muchos sistemas nunca se crea ningún usuario SELinux más. En este caso, ¿la ventaja mencionada arriba sobre usuarios SELinux (una vez que el usuario ingresa en el sistema, éste no puede cambiar a otro usuario SELinux) es la única?

Bien, no. Los usuarios SELinux también se usan para categorizar las cuentas que tienen el permiso de usar un rol en particular.

Listado de Código 4.2: Usuarios SELinux y sus roles asociados

~# semanage user -l
SELinux User    SELinux Roles

root            staff_r sysadm_r
staff_u         staff_r sysadm_r
sysadm_u        sysadm_r
system_u        system_r
user_u          user_r

Los usuarios Linux estándar están vinculados a estos usuarios SELinux:

Listado de Código 4.3: Usuarios Linux y sus vínculos con usuarios SELinux

~# semanage login -l
Login Name          SELinux User

__default__         user_u
root                root
swift               staff_u

En este ejemplo, únicamente el nombre de los usuarios Linux swift (a través de staff_u) y root (a través del usuario SELinux root) podrán eventualmente trabajar en el rol sysadm_r. El resto de cuentas serán vinculadas por defecto al usuario user_u (y al rol user_r).

Esto se aplica únicamente a los usuarios interactivos. Los procesos que se lanzan mediante un guión de inicio o de cualquier otra forma no se asocian con el usuarios SELinux user_u: dependiendo del contexto de seguridad de los procesos que los lancen, podrán cambiar a cualquier otro. Desde luego, si el contexto de seguridad del proceso que los está lanzando es user_u:user_r:user_t entonces no podrán transformarse en otro más que user_u:user_r:* con * un dominio soportado por el rol user_r.

Los usuarios SELinux se utilizan también para implementar el Control de Acceso Basado en Usuario o UBAC. Esta funcionalidad de SELinux permite a los dominios conocer a los usuarios: un proceso corriendo en el contexto de un usuario SELinux en particular puede, por ejemplo, únicamente trabajar con ficheros del mismo usuario SELinux. Esto ofrece un método de acceso más fino ya que ese proceso podrá correr en un dominio que tenga acceso al dominio del fichero, pero no podrá escribir en el fichero ya que el usuario SELinux es distinto.

Actualmente SELinux en Gentoo Hardened soporta ambas directrices y también el soporte sin UBAC, aunque se recomienda encarecidamente el uso de UBAC. Esto se controla usando el ajuste USE ubac.

2.e. Seguridad multinivel / Seguridad multicategoría

Introducción

Además de la característica para forzar los tipos, SELinux también ofrece soporte MLS (seguridad multinivel) y MCS (seguridad multicategoría). Esto permite a los administradores definir una directriz de confidencialidad jerárquica. Por ejemplo, puede asegurarse de que un proceso o usuario en un determinado dominio de seguridad y nivel, pueda escribir en ficheros del mismo nivel (o superior), o leer ficheros del mismo nivel (o inferior), pero no puede escribir en ficheros de un nivel inferior. Esto permite a los administradores implementar un nivel de seguridad jerárquica pública/interna/confidencial/estrictamente confidencial para los ficheros.

Aunque la implementación de MLS podría realizarse usando las reglas de forzado de tipos que hemos explicado previamente, hacerlo así podría desembocar en una colección inmanejable de tipos y permisos. La implementación MLS facilita esto.

Seguridad Multinivel

Es la más flexible, pero la más complicada de gestionar. El método que ofrece SELinux es MLS, o Seguridad Multinivel (Multi-Level Security). Cuando se utiliza este tipo de directriz, los administradores de seguridad pueden asignar etiquetas de sensibilidad a los recursos y definir qué dominios (y qué niveles de seguridad) pueden leer o escribir en qué nivel. Un nivel se da siempre como un rango, mostrando el menor y mayor nivel en el que un dominio en particular está corriendo.

Además del nivel de sensibilidad, la directriz MLS soporta categorías por cada nivel. Estas categorías permiten que el administrador de seguridad pueda hacer distintos "contenedores" probablemente independientes para los recursos que sean sensibles. Para dar un ejemplo, el administrador puede soportar los niveles desde Público hasta Estrictamente confidencial y categorías como "Finanzas", "Análisis de Riesgo", "Adquisiciones", "Sistemas TIC", ...

Con estas categorías, uno puede permitir que un rol tenga acceso a todos los niveles de sensibilidad para una categoría en particular (digamos "Sistemas TIC") pero que tenga acceso únicamente a los documentos Públicos e Internos del resto de categorías.

Seguridad Multicategoría

La directriz MCS o Seguridad Multicategoría (Multi-Category Security) es un subconjunto de la directriz MLS. Soporta las distintas categorías, pero sin usar los múltiples niveles de seguridad para los recursos.

El uso de la directriz MCS se ha hecho popular debido aq que es bastante más fácil de gestionar mientras que conserva algo de la flexibilidad presente en la directriz MLS. La directriz MLS se utiliza más para propósitos de negocio (y así, tiene alguna influencia en la propia organización de ese negocio). La directriz MCS es más utilizada en arquitecturas multipropiedad. En una arquitectura multipropiedad, los sistemas son procesos en ejecución para varios clientes a la vez. La categorización permite la separación de estos privilegios a través de estos procesos sin introducir dominios múltiples (los cuáles requerirían el desarrollo de nuevas directrices para cada nuevo cliente al que se quisiera servir).

2.f. Directriz de referencia

Acerca de refpolicy

Como se ha descrito previamente, SELinux utiliza forzado de tipos para describir el estado de su sistema. Esto se realiza dando a cada recurso del sistema (sea un proceso, un puerto de red, un fichero o directorio) un tipo específico y describiendo las reglas de cómo cada tipo puede trabajar con otros tipos.

La gestión de esta directriz no es fácil. Al contrario que otros sistemas MAC, los cuales confían en un modo de aprendizaje y no utilizan definiciones de dominio (éstos en su lugar registran qué órdenes tiene permitidas ejecutar un proceso), una definición correcta SELinux requiere muchas (miles y miles) líneas de permisos.

Para asegurarse de que no se realizan esfuerzos duplicados, y para ayudar a las distribuciones como Gentoo, Fedora, RedHat, Debian, ... en sus esfuerzo de integración de SELinux, se ha lanzado un proyecto denominado The Reference Policy (La directriz de referencia).

Este proyecto, gestionado por Tresys, se usa en la mayoría de las distribuciones que soportan SELinux, incluyendo Gentoo Hardened, Fedora, RedHat Enterprise Linux, Debian, Ubuntu y más. Esta implementación no solo ofrece las directrices modulares que los usuarios están buscando, sino que mejora la experiencia con SELinux añadiendo herramientas de desarrollo adicionales que hacen más fácil trabajar con las directrices de SELinux en su sistema. Las actualizaciones en la directriz de referencia se realizan eventualmente en todas las distribuciones soportadas. Lo mismo sucede con Gentoo Hardened, que trata de utilizar una directriz los más cercana a la de referencia, y envía sus propios parches a la directriz de referencia, lo cual beneficia a toda la comunidad.

El API de la directriz de referencia

Una de las mayores ventajas de la directriz de referencia es su API. Para ayudar a los autores de las directrices, la directriz de referencia utiliza un lenguaje de macros que genera las reglas necesarias de permisión así como otras reglas. Este lenguaje de macros, hace muy fácil añadir derechos a dominios en particular. El API documentado se encuentra en línea, sin embargo, si tiene ajustado USE="doc", se almacenará en su sistema en el momento en que instale y configure SELinux.

Enfoque modular

Otra característica de la directriz de referencia es el uso de modulos. Si quisiera construir todas las reglas en una única directriz (un fichero binario legible por el núcleo Linux, permitieńdole interpretar y forzar las reglas SELinux rules), el fichero enseguida crecería demasiado y se mostraría ineficiente.

En lugar de esto, la directriz de referencia define las reglas en los llamados módulos, los cuales a su vez definen un dominio (por ejemplo portage_t) o más (si están fuertemente relacionados) y los derechos y privilegios que ese dominio necesitaría para funcionar de forma correcta. Cualquier derecho que necesita el dominio respecto a otro dominio debe definirse en las interfaces de ese dominio (mire más arriba), forzando que los módulos sean específicos y manejables.

Listado de Código 6.1: Vista rápida de ejemplo de módulos SELinux instalados

# semodule -l
alsa    1.11.0
apache  2.3.0
audioentropy    1.6.0
dbus    1.15.0
dmidecode       1.4.0
(...)

Al utilizar un enfoque modular, únicamente se necesita cargar la directriz base (la capa del núcleo, así como otras definiciones fundamentales) y los módulos relacionados con ese sistema. Podrá entonces ignorar de forma segura los demás módulos. Esto mejora el rendimiento (directrices más cortas, lo cual conlleva que las reconstrucciones sean un poco menos penosas) y la manejabilidad (definiendo de forma adecuada los límites de las reglas de la directriz).

Configuraciones y condicionales

Pero, ¡un momento!, aún hay más. La directriz de referencia también soporta el uso de booleanos. Éstos son ajustes que un administrador de la seguridad puede habilitar o deshabilitar para cambiar la directriz activa. Los booleanos definidos de forma correcta permiten a los administradores de seguridad ajustar finamente la directriz para sus sistemas.

Listado de Código 6.2: Vista rápida de los booleanos disponibles

# getsebool -a
allow_execheap --> off
allow_execmem --> off
allow_execmod --> off
allow_execstack --> off
allow_gssd_read_tmp --> on
allow_httpd_anon_write --> off

Los booleanos son una parte importante para construir una directriz de referencia genérica que sea utilizable por la mayoría de los usuarios de SELinux. Aunque tiene requisitos específicos (como el hecho de permitir ptrace o deshabilitar execmem) aún pueden utilizar la misma directriz de referencia y definir únicamente aquellos booleanos que se necesiten.

Ficheros de directriz y versiones

La infraestructura de directriz SELinux utilizada (por ejemplo, las capacidades y funcionalidades que ésta ofrece) no se incluyen en su primera versión. Actualmente, las entregas de SELinux utilizan un versión del binario 24 o 26 (dependiendo de la versión del núcleo utilizada).

Listado de Código 6.3: Obtener la versión del binario de la directriz

# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        strict

Cada vez que se añaden funcionalidades o capacidades que requieren cambios a la estructura interna de la directriz compilada, se incrementa este número de versión. A continuación se muestra una vista rápida del histórico de versiones de la directriz, básicamente es una traducción del fichero security/selinux/include/security.h perteneciente al núcleo Linux.

Versión 12
"Antigua API" para SELinux, la cual es ahora obsoleta
Versión 15
"Nueva API" para SELinux, integrada en el núcleo Linux 2.6.0 (hasta la versión 2.6.5)
Versión 16
Añadidas extensiones condicionales a la directriz (2.6.5)
Versión 17
Añadido soporte para IPV6 (2.6.6 - 2.6.7)
Versión 18
Añadido soporte para zócalos (sockets) de enlace de red con ajuste fino (2.6.8 - 2.6.11)
Versión 19
Mejorada la seguridad multinivel (2.6.12 - 2.6.13)
Versión 20
Optimizaciones en el acceso al tamaño de la tabla de vectores (2.6.14 - 2.6.18)
Versión 21
Transiciones en rango de clases de objetos (2.6.19 - 2.6.24)
Versión 22
Capacidades de la directriz (características) (2.6.25)
Versión 23
Modo permisivo para cada dominio (2.6.26 - 2.6.27)
Versión 24
Jerarquía explícita (limites de tipos) (2.6.28 - 2.6.38)
Versión 25
Soporte de transiciones basadas en nombres de fichero (2.6.39)
Versión 26
Soporte de transición de roles para clases no-proceso (3.0)
Versión 27
Soporte para la herencia flexible de los usuarios y roles de los objetos creados (3.5)
Versión 28
Soporte para la herencia flexible del tipo de los objetos creados (3.5)
Versión 29
Soporte al nombrado de restricciones (3.13)

2.g. Siguientes pasos

Qué es lo siguiente

Puede que sea difícil comprenderlos ahora, pero estos conceptos son importantes ya que si algo va mal en su sistema cuando habilite SELinux, pero todo funciona bien cuando se deshabilita, entonces necesitará estudiar más a fondo los contextos de seguridad, las reglas, los tipos y transiciones de dominio para averiguar el motivo del fallo.

En el siguiente capítulo, le ofrecemos información sobre recursos (recursos en línea, libros, preguntas frecuentes, etc.). A continuación, nos sumergeremos en la instalación y configuración de SELinux en su sistema Gentoo Hardened system. Entonces, configuraremos y ajustaremos la directriz SELinux a nuestro antojo.


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


Imprimir

Ver completo

Página actualizada 9 de abril, 2014

Sumario: Para poder trabajar correctamente con SELinux, es vital que comprenda algunos conceptos como dominios, transiciones de dominios y contextos de ficheros. Sin una comprensión básica de estos aspectos, será dificil comprender cómo funcionan las directrices de SELinux y cómo actuar en caso de que las cosas no vayan bien.

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.