|
[ << ] [ < ] [ Inicio ] [ > ] [ >> ] 2. Conceptos detrás de SELinuxContenido:
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. 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):
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.
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:
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:
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.
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:
La regla más común de SELinux para el control de acceso (allow) se describe de la siguiente forma:
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.
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:
Desde le punto de vista de los permisos estándar de Linux, el usuario tiene permiso para escribir. Pero, ¿Le permitirá SELinux hacerlo?
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 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.
Las reglas que identifican las acciones permitidas para un dominio ya se han descrito anteriormente, las citamos de nuevo:
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).
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. 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:
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. 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.
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. 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:
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. 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.
Los usuarios Linux estándar están vinculados a estos usuarios SELinux:
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 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. 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. 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). 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. 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.
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.
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).
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.
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 ] [ > ] [ >> ] El contenido de este documento, a no ser que se especifique expresamente, está registrado bajo los términos de la licencia CC-BY-SA-2.5. Se aplican las Pautas de Utilización del logotipo y nombre de Gentoo. |
|