Manual de SELinux para GentooContenido:
A. Introducción a Gentoo/Hardened SELinux1. Mejorando la seguridad en LinuxBienvenido al manual de SELinux para Gentoo. Con este recurso queremos presentarle rápidamente la implementación de SELinux y las directrices implicadas. Parte de esta presentación consiste en ayudarle a comprender porqué se creó SELinux y qué conceptos se esconden detrás de los parches de SELinux. Cubriremos los conceptos más importantes de SELinux, las directrices de referencia que utiliza Gentoo Hardened y desarrollaremos el trabajo con algunas herramientas de SELinux. El propósito de este libro no es explicar en detalle el funcionamiento del propio SELinux. Existen muchas referencias disponibles en Internet y en muchos libros que le ayudarán con SELinux. En lugar de esto, nos centraremos en la integración de SELinux en Gentoo Hardened. Desde luego, le ofreceremos una rápida introducción a SELinux para que pueda comprender cómo trabaja, lo que es, y le ayudaremos a identificar las acciones que necesita realizar para asegurar su sistema usando las herramientas de SELinux. La seguridad se ve a menudo como un concepto vago. ¿Qué es la seguridad en general? ¿Cómo se mide? ¿Qué beneficio se obtiene y cómo asegurarse de no poner demasiado esfuerzo en asegurar su sistema? Bien, los fanáticos de la seguridad le contarán que no existe otra cosa salvo el exceso de seguridad. Si se implementa de forma correcta, la seguridad no restrige la funcionalidad o el rendimiento. No le da demasiado trabajo para realizar sus tareas. Pero implementar la seguridad de forma apropiada es una tarea diferente y que conlleva mucho tiempo. Esta es la razón por la que en muchas ocasiones se escucha que la seguridad es tan buena como su administrador. Entonces, ¿Cómo puedo velar por la seguridad?. Una buena práctica consiste en definir sus metas en lo que a seguridad se refiere. Haga una lista de que lo que quiere conseguir y porqué lo quiere hacer. Haciendo un seguimiento de las amenazas que quiere minimizar, podrá construir un modelo de seguridad que es el adecuado para su entorno. Estas amenazas pueden ser muy pretenciosas, como por ejemplo "Asegurarse de que nadie pueda violar nuestras medidas de seguridad". En el caso de un sistema Linux funcionando con SELinux, esto podría significar que desea que nadie o nada, salvo los procesos de confianza, puedan escribir en ficheros críticos del sistema, como por ejemplo, la(s) imagen(es) del núcleo, configuración del gestor de arranque, las contraseñas y el propio binario de SELinux con las directrices. Un control de acceso decente de un sistema (o grupo de sistemas), asegura que únicamente se permite acceso a las personas o procesos autorizados a los recursos con los que quieren trabajar. Antes de que pueda implementar un control de acceso al sistema, necesitará obtener la autorización adecuada. Si sus esquemas de autenticación fallan, su sistema de control de acceso al sistema podría no diferenciar a los usuarios legítimos de los maliciosos. La autenticación de los usuarios en los sistemas Linux se realiza a través de PAM (Módulos de Autenticación Enchufables), un potente mecanismo para integrar esquemas múltiples de autenticación de bajo nivel en una interfaz de alto nivel. Sin embargo, la autorización para el uso de los recursos, se realiza a veces a través de un esquema simple de permisos. La mayoría de los recursos no están ocultos por defecto, aunque existen parches y actualizaciones (tales como las ofrecidas por las fuentes del núcleo Gentoo Hardened con parches grSecurity que incluyen soporte para este tipo de medidas). Puede ocultar la existencia de archivos en todo el sistema de ficheros asegurándose de que el directorio en el que residen no es legible ni "ejecutable" por cuentas no autorizadas. Este esquema de permisos por defecto tiene algunos inconvenientes importantes. No le permite definir autorizaciones flexibles (únicamente permite autorizaciones a tres niveles: propietario, grupo propietario y cualquier otra cuenta) y además está limitada a los permisos lectura/escritura/ejecución (aunque algunos atributos adicionales están disponibles hoy en día). Otro problema es que el esquema de permisos es discrecional, lo que significa que los usuarios y procesos pueden cambiar las directrices de seguridad. Este esquema de permisos es suficiente Para la mayoría de usuarios y ha demostrado ofrecer un método adecuado para gestionar las autorizaciones de acceso. Si embargo, los inconvenientes que presenta han resultado ser un agujero importante en lo que Linux ofrece. 1.c. Control de acceso obligatorio Si el control de acceso discrecional, abreviado DAC, mencionado arriba no es suficiente (y si es riguroso con la seguridad, no lo encontrará suficiente), entonces necesitará un sistema Control de Acceso Obligatorio o MAC. Cuando se usa un sistema MAC, se necesita permitir explícitamente las actividades que un proceso quiere realizar en un recurso. Esto ofrece mayor granularidad con los permisos y los recursos. A menudo ofrecen no sólo soporte para ficheros, sino también para zócalos (sockets), puertos, segmentos de memoria, colas, procesos, servicios del núcleo, llamadas al sistema, dispositivos, sistemas de ficheros y mucho más. La granularidad de las actividades soportadas es también muy grande. Para los ficheros, esto incluye: añadir, crear, ejecutar, escribir, enlazar, llamadas ioctl, obtener atributos (getattr), dar valor a atributos (setattr), lectura, renombrado, bloqueo,... mientras que para los zócalos (sockets) estos pueden ser: añadir, asociar (bind), conectar, crear, escribir, enviar a, aceptar,... También, cuando se utiliza un sistema MAC, ningún usuario ni proceso puede manipular las directrices de seguridad por sí mismo: lo que el administrador ha concedido no puede ser revocado. Aquí es donde SELinux entra en juego. SELinux es una característica del núcleo Linux que implementa, entre otras cosas, un sistema MAC para controlar y gobernar el acceso a varios recursos. Usa un esquema de permisos de denegación por defecto, de forma que se necesita conceder explícitamente el acceso que ha solicitado un proceso. SELinux permite igualmente un modelo de permisos más fino encima del sistema tradicional DAC (el cual se usa también mientras SELinux está en funcionamiento; en otras palabras: si el sistema tradicional no permite ciertas actividades, éstas no serán permitidas incluso si las directrices de SELinux permiten la acción). Para dar soporte a este modelo fino de permisos, es lógico pensar que se deben realizar cambios al núcleo Linux. Sí, gracias a la interfaz del núcleo Linux LSM (Módulos de Seguridad de Linux), el soporte para SELinux se añadió de forma muy sencilla desde el comienzo de las series 2.6 del núcleo. SELinux se ha integrado en el árbol principal del núcleo. Sin embargo, el soporte de SELinux y su utilización son dos cosas muy diferentes. Para identificar adecuadamente los recursos, SELinux necesita asignar etiquetas a estos recursos. Cuando los recursos están en memoria, se realiza principalmente en el núcleo Linux, sin embargo, para recursos persistentes como ficheros, estas etiquetas deben localizarse en algún lugar. En SELinux, se ha elegido usar atributos extendidos del fichero (que son almacenados en el propio sistema de ficheros). La ventaja de este enfoque es que la etiqueta permanece junto al fichero incluso si éste cambia de nombre. Por el contrario, una desventaja de este enfoque es que el sistema de ficheros debe soportar estos atributos extendidos, los cuales no todos los sistemas de ficheros poseen (o tienen activados). SELinux también utiliza roles para gestionar el acceso a los recursos. A un usuario que no tiene el rol de acceso a la administración del sistema no se le debe permitir ejecutar cualquier actividad de administración del sistema incluso si es capaz de escalar sus privilegios (por ejemplo usando una aplicación con la capacidad set-uid). Para el soporte de roles, SELinux requiere cambios en los servicios de autenticación (PAM) y necesita almacenar en algún lugar las definiciones de los roles y las autorizaciones. Aparte del soporte en el núcleo y las etiquetas asignadas a los recursos en el sistema de autorización, SELinux requiere también herramientas específicas para consultar y manipular las etiquetas, gestión de privilegios (por ejemplo la herramienta sudo), servicios del sistema (como SysVInit) etc. Esto se traduce en un conjunto de parches que se aplican a estas herramientas (y más) los cuales no son siempre parte del código fuente principal de la aplicación. Gentoo Hardened ofrece SELinux integrado en la distribución. Cuando se selecciona soporte para SELinux, Gentoo Hardened aplicará los parches necesarios a las aplicaciones y le ayudará a (re)etiquetar sus ficheros y otros recursos para que puedan ser gestionados por SELinux. Gentoo Hardened también integra soporte SELinux en Portage, permitiendo que los nuevos ficheros que se instalen sean etiquetados automáticamente y que se utilice un entorno inofensivo (sandbox) para la construcción segura de los paquetes. Aparte del soporte tecnológico puro, esperamos que encuentre los documentos de soporte, guías, experiencia y soporte en línea necesarios para usar SELinux en Gentoo. No dude en entrar y decir ¡hola! en el canal de chat #gentoo-hardened de la red IRC en Freenode o en nuestra lista de correo. Si piensa que SELinux es apropiado para sus pretensiones y quiere probarlo usando Gentoo Hardened, por favor, continúe leyendo. En el próximo capítulo le informaremos de como se ha "diseñado" la seguridad en SELinux y cómo está estructurada conceptualmente. En capítulos posteriores le ayudaremos con el lenguaje de autorización y las directrices "base" con las que la mayoría de las distribuciones comienzan y finalmente le ayudaremos a instalar, ejecutar y gestionar un sistema SELinux con Gentoo Hardened. 2. Conceptos detrás de SELinuxDebido 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. 3. Recursos de SELinux
Referencias relacionadas con la directriz
3.d. Recursos específicos de Gentoo Los siguientes recursos son específicos de la implementación de SELinux en Gentoo Hardened. B. Usando SELinux Gentoo/Hardened1. Instalación de Gentoo SELinux / Conversión1.a. Instalar Gentoo (Hardened) Instalar el sistema Gentoo con SELinux no requiere acciones extrañas. Lo que se necesita es instalar Gentoo Linux con el perfil correcto, la configuración del núcleo correcta y etiquetar algunos sistemas de ficheros. Recomendamos seriamente usar SELinux junto con otras mejoras que hagan más robusto nuestro sistema (como PaX / grSecurity). Este capítulo describe los pasos para instalar Gentoo con SELinux. Asumimos que tiene un sistema Gentoo Linux ya funcionando que quiere convertir a Gentoo con SELinux. Si no es éste el caso, puede igualmente continuar leyendo: podrá instalar Gentoo con SELinux de forma directa si toma las decisiones correctas, basadas en la información contenida en este capítulo, durante el proceso de instalación. Realizar una instalación estándar Instale Gentoo Linux siguiendo las instrucciones del manual de Gentoo. Recomendamos usar los ficheros tarball hardened de stage3 y el núcleo hardened-sources en lugar de los ficheros estándar, sin embargo, las instalaciones con stages estándar se permiten también en SELinux. Haga una instalación completa hasta el punto en el que debe reiniciar su sistema para obtener una instalación base (primitiva) de Gentoo.
Hasta la fecha, no todas las utilidades de gestión de SELinux son compatibles con Python 3 por lo que le recomendamos cambiar a Python 2 hasta que los paquetes sean actualizados y corregidos.
Elegir un tipo de directriz SELinux Gentoo ofrece soporte a cuatro tipos de directriz en SELinux: strict, targeted, mcs y mls. La diferencia entre strict y targeted es debida al dominio no confinado. Cuando se carga la directriz, los procesos en su sistema que no están confinados específicamente en un módulo de directriz en particular formarán parte de los dominios no confinados cuyo propósito es permitir por defecto la mayoría de las actividades (en lugar de prohibirlas por defecto). Como resultado, los procesos que corren dentro de dominios no confinados no tienen restricciones aparte de aquéllas ya forzadas por la seguridad estándar de Linux. A pesar de que el hecho de trabajar sin dominios no confinados está considerado más seguro, también será un más complicado para el administrador tener la certeza de que el sistema funciona correctamente ya que no hay módulos de directriz para cada una de las aplicaciones "ahí fuera". Aparte de targeted y strict, puede optar por mcs para permitir la categorización de los dominios de los procesos. Esto es útil en sistemas gestionados por múltiples propietarios como servidores Web, equipos de virtualización, etc. en los que muchos procesos están corriendo, la mayoría de ellos en el mismo dominio de seguridad, pero en diferentes categorías. Observe, sin embargo, que para para poder utilizar el soporte de categorías adicionales, bien las propias aplicaciones (como el servidor Web o las herramientas de supervisión) necesitan configurar las categorías SELinux (por lo que deben ofrecer soporte a SELinux), bien se necesitará un guión para arrancar las instancias individuales en categorías diferentes. De lo contrario, mcs es simplemente lo mismo que targeted o strict. Para terminar, puede también elegir mls para diferenciar los dominios de seguridad a un nivel sensible. Sin embargo, MLS aún está considerado experimental en Gentoo y por lo tanto no lo recomendamos. En el caso de mcs o mls, necesitará utilizar el ajuste USE unconfined para habilitar o deshabilitar los dominios no confinados en estos tipos de directriz. El tipo strict (sin dominios no confinados) no ofrece este ajuste USE, y el tipo targeted (dominios no confinados) requiere que el ajuste USE esté habilitado. Cuando haya elegido los tipos de directriz, guárdelos también en su fichero /etc/make.conf. De esta forma, Portage instalará únicamente los módulos SELinux para ese tipo de directriz. Por defecto, los perfile SELinux habilitan strict y targeted (siendo strict el tipo activo por defecto).
Ajustar los contextos del sistema de ficheros Si su directorio /tmp está en un sistema de ficheros tmpfs montado, entonces necesitará indicarle al núcleo que el contexto raíz de esta localización es tmp_t en lugar de tmpfs_t. Muchos objetos en la directriz de SELinux (incluyendo algunas directrices al nivel de servidor) asumen que /tmp es tmp_t. Para configurar el montaje de /tmp, edite su fichero /etc/fstab:
A continuación, ajuste la siguiente línea en su /etc/fstab para configurar el contexto para la localización /run.
Ahora que tiene una instalación de Gentoo Linux funcionando, cambie el perfil de Gentoo al perfil SELinux adecuado (por ejemplo, hardened/linux/amd64/no-multilib/selinux). Observe que los perfiles antiguos (como selinux/v2refpolicy/amd64/hardened) todavía están soportados.
No actualice su sistema aún. Necesitaremos instalar un par de paquetes en las siguientes dos secciones en un orden en particular para el que Portage no está preparado. A continuación, eche un vistazo a los siguientes ajustes USE y decida si quiere habilitarlos o deshabilitarlos.
Elija sus opciones y actualice la variable USE en /etc/make.conf o en una localización apropiada /etc/portage/package.use para el paquete sec-policy/selinux-base. Cambios manuales en el sistema
Los siguientes cambios pueden ser necesarios en su sistema dependiendo de las configuraciones o herramientas implicadas.
Aunque los núcleos Linux por defecto ofrecen soporte SELinux, recomendamos el uso del paquete sys-kernel/hardened-sources.
A continuación, reconfigure su núcleo con los ajustes apropiados de seguridad. Esto incluye (pero no está limitado a):
Debajo encontrará una lista rápida de los ajustes recomendados.
Recomendamos igualmente el uso de PaX. Puede encontrar más información sobre PaX en el contexto Gentoo Hardened en Guía de inicio rápido para usar PaX con Gentoo Hardened. Construya e instale el nuevo núcleo Linux y sus módulos. A continuación, edite /etc/fstab y añada la siguiente línea:
También deberá crear el punto de montaje
Una vez realizados los cambios mencionados arriba, reinicie su sistema. Asegúrese de que ahora está corriendo un núcleo Linux con SELinux habilitado (el sistema de ficheros /selinux deberá estar montado). No se preocupe, todavía no está activado SELinux. Ahora necesitaremos configurar SELinux, para ello, deberemos instalar las utilidades apropiadas, etiquetar nuestro sistema de ficheros y configurar la directriz. Instalar directrices y utilidades En primer lugar, instale los paquetes sys-apps/checkpolicy y sys-apps/policycoreutils. Aunque éstos serán instalados obligatoriamente debido a las dependencias con los paquetes de directriz SELinux, necesitaremos instalarlos en primer lugar, por ello se utiliza la opción -1.
Ahora deberá instalar el paquete de directriz de SELinux (sec-policy/selinux-base-policy). Este paquete contiene la directriz base de SELinux. Ya que Portage intentará etiquetar y recargar las directrices (debido a la instalación de sys-apps/policycoreutils), necesitaremos desactivar temporalmente el soporte de SELinux (ya que Portage no podrá etiquetar nada si todavía no lo comprende).
A continuación, reconstruya aquellos paquetes afectados por el cambio de perfil que hicimos previamente usando una actualización estándar de "world" que tendrá en cuenta los cambios en los ajustes USE (ya que el nuevo perfil cambiará muchos ajustes USE por defecto, incluyendo el ajuste USE selinux). No olvide utilizar después etc-update o dispatch-conf ya que se necesitarán realizar algunos cambios a los ficheros de configuración.
Ahora, instale las herramientas adicionales de SELinux que necesitará en el futuro para depurar o ayudarle con su instalación de SELinux. Estos paquetes son opcionales, pero recomendamos su instalación.
Para terminar, instale los módulos de directrices para aquellas utilidades en las que crea que va a necesitarlas. En un futuro no muy lejano, esta acción se realizará de forma automática (los paquetes tendrán una dependencia opcional producida por el ajustes USE selinux), pero hasta ese momento, necesitará hacer este trabajo manualmente.
Configure la directriz de SELinux Dentro de /etc/selinux/config puede definir cómo se va a configurar SELinux en el momento en que se inicie el sistema.
En este fichero de configuración se pueden definir dos variables:
Reinicie y etiquete el sistema de ficheros
En primer lugar, reinicie su sistema de modo que se carguen las directrices instaladas. Ahora, necesitaremos reetiquetar sus dispositivos y sus ficheros relacionados con openrc. Esto aplicará los contextos de seguridad adecuados (etiquetas) en los ficheros necesarios.
A continuación, si tiene un fichero de intercambio en lugar de una partición, etiquételo de la forma adecuada:
Ahora reetiquete completamente su sistema de ficheros. La orden de abajo aplicará el contexto de seguridad adecuado a los ficheros de su sistema de ficheros basándose en la información de contexto de seguridad que ofrecen los módulos de directrices de SELinux instalados.
Si alguna vez tiene que instalar una directriz de SELinux para un paquete después de haberlo instalado, necesitará ejecutar rlpkg para ese paquete de forma que tenga la certeza de que los contextos de seguridad para los ficheros del paquete se ajustan adecuadamente. Por ejemplo, si ha instalado sec-policy/selinux-screen después de darse cuenta de que tiene instalado screen en su sistema:
Habilitar el servicio selinux_gentoo Gentoo ofrece un guión llamado selinux_gentoo que restaura los contextos de los ficheros y dispositivos creados dinámicamente así como los pseudo sistemas de ficheros (/dev (opcionalmente) y /sys) ya que estos sistemas de ficheros nos pueden persistir en los cambios de contexto que suceden entre reinicios. El guión de inicio también ofrece soporte para iniciar en modo permisivo en primer lugar (por ejemplo si tiene un initramfs creado que no funciona en modo forzado) y cambiar a modo forzado a continuación. Habilite este guión utilizando rc-update add selinux_gentoo boot y actualice la configuración de su gestor de arranque con las siguientes opciones de inicio:
Reinicie y ajuste los booleanos de SELinux Reinicie su sistema. Así, se utilizarán los nuevos contextos de fichero que se aplicaron. Ingrese en el sistema, y, si ha instalado Gentoo usando los fuentes hardened (como hemos recomendado), habilite el booleano SSP de SELinux, permitiendo a cada dominio acceso de lectura al dispositivo /dev/urandom:
Defina las cuentas de administrador Si SELINUXTYPE está definido a strict, entonces necesitamos mapear la(s) cuenta(s) que utiliza para gestionar su sistema (aquéllas que necesitan acceso a Portage) al usuario de SELinux staff_u. Si no, no podrá gestionar correctamente el sistema con ninguna de las cuentas (aparte de root, pero entonces necesitará entrar en el sistema como root directamente y no a través de sudo o su). Por defecto, los usuarios se mapean al usuario SELinux user_u, el cual no tiene los privilegios adecuados (tampoco los roles apropiados de acceso) para gestionar un sistema. Las cuentas que son mapeadas a staff_u pueden hacerlo, pero podrían necesitar cambiar del rol staff_r al rol sysadm_r antes de que se les concedan los privilegios apropiados. Asumiendo que su nombre de cuenta es juan:
Si más tarde ingresa en el sistema como juan y quiere gestionar su sistema, probablemente necesitará cambiar su rol. Puede usar newrole para hacer esto:
Si, por el contrario, utiliza una directriz targeted, entonces el usuario con el que trabaja será de tipo unconfined_t y ya dispondrá de los privilegios necesarios para realizar tareas administrativas del sistema. Cuando haya terminado, disfrute de su trabajo. Acaba de dar sus primeros pasos por el mundo SELinux. Soporte del servicio de administración Por defecto, las directrices de SELinux en Gentoo Hardened permiten al dominio sysadm_t el acceso a todos los servicios. Sin embargo, algunos de estos servicios tienen directrices que les permiten se asignados a usuarios individuales diferentes de root. Esto requiere que se conceda al usuario el rol system_r (lo que implica que el usuario puede, en ciertos casos, obtener este cambio de rol hacia el rol de sistema). Por tanto, se recomienda conceder el rol system_r al usuario SELinux administrador que va a utilizar en mayor medida. Estos son, en la mayoría de los casos, los usuarios root y staff_u.
2. Configurar SELinux para adaptarlo a sus necesidadesA 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. Ejecute semanage login -l para mostrar los mapeos actuales entre las cuentas de usuario Linux y los usuarios SELinux.
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.
Para mapear una cuenta a un usuario especifico de SELinux, utilice la orden semanage login -a:
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:
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:
Verifiquemos como los usuarios SELinux están configurados actualmente:
Ahora que hemos creado un nuevo usuario llamado "sofia", podemos actualizar el mapeo de la cuenta Linux "sofia" hacia el nuevo usuario SELinux "sofia":
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:
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 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.
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.
Analicemos cada una de las partes de este mensaje una a una.
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).
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.
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
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:
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:
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:
En la mayoría de los casos, se debe actuar sobre las denegaciones. Las acciones que entonces necesitará realizar son:
2.c. Utilizar etiquetas (de fichero) 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:
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.
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:
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:
Si tiene permiso, entonces puede utilizar chcon para cambiar (ch) el contexto de un fichero:
Si no posee los privilegios adecuados, obtendrá un mensaje de error descriptivo:
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:
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.
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.
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:
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:
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:
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:
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:
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 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:
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.
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:
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:
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:
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:
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:
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... 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):
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). 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:
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. 3. Órdenes en SELinux3.a. Información sobre las órdenes en SELinux A estas alturas, debería tener un sistema con SELinux habilitado (pero corriendo en modo permisivo (permissive) de modo que no obliga a cumplir las reglas de la directriz). Por lo que antes de introducirle en el mundo de SELinux y describir la forma de añadir más reglas sin perder la funcionalidad cuando cambie al modo forzado (enforcing), echaremos un vistazo rápido a algunas de las órdenes relacionadas con SELinux. Comenzaremos con las órdenes de estado con las cuales puede obtener información global sobre el estado de SELinux (si está corriendo en modo forzado o no, conocer las versiones, etc). Obteniendo el estado de SELinux La primera orden de la que hablaremos es sestatus.
La salida de esta orden indica que SELinux está habilitado y está trabajando actualmente en modo permisivo (permissive). También nos indica que el sistema está configurado para correr en modo estricto (strict) por lo que no existe el dominio unconfined_t. La orden sestatus también ofrece una salida extendida si la ejecuta con la opción -v option. Cuando se indica esta opción, la orden devuelve los contextos de ficheros y procesos importantes:
Otra orden de estado general de SELinux es getenforce, el cual le permite ver rápidamente si su SELinux está corriendo en modo forzado (las directrices de SELinux se fuerzan), permisivo (las directrices de SELinux policies se comprueban y registran pero no se fuerzan) o deshabilitado (la directriz de SELinux no se carga y por lo tanto no se comprueba).
Obteniendo información de los objetos de SELinux En la siguiente tabla se muestra la orden seinfo. Esta orden le permite consultar la directriz en ejecución definida para todos los objetos (tipos, roles, atributos, usuarios, booleanos,...). Algunos usos comunes son los siguientes:
Como ejemplo, consultaremos si se conoce el dominio crontab_t, si el rol user_r puede usar el dominio contab_t y finalmente qué dominios tienen el atributo cron_spool_type activado.
Consultando las reglas de directriz de SELinux Una orden que se usa menudo es sesearch. Esta orden le permite consultar las reglas usadas en la directriz actual y es de gran ayuda cuando queremos averiguar si algo está permitido (o porqué no está permitido). La orden sesearch se usa frecuentemente con un dominio origen (-s), dominio destino (-t) o ambos, la clase sobre la que quiere hacer la consulta permite reglas para: fichero, directorio, zócalo (socket), proceso,... y el privilegio que quiere consultar: lectura, escritura, transición, ejecución... Por ejemplo, para averiguar qué dominios pueden escribir en los ficheros que tienen el dominio shadow_t:
Observará que en algunas ocasiones los resultados están basados en los atributos en lugar de los dominios:
En este caso, al dominio origen (portage_t) se le permite escribir en los ficheros cuyo dominio tengan el atributo file_type activado. Si ya le va cogiendo el tacto a todo esto, se preguntará si la regla de arriba no es un fallo flagrante en la seguridad ya que todos los dominios de los ficheros tienen el atributo file_type activado. Sí y no, si echamos un vistazo a los dominios que tienen privilegios para escribir en los dominios file_type domains, se dará cuenta de que el único es portage:
Observe que tenemos una orden sin la opción -d y otra que usa esta opción. Cuando se indica -d, la búsqueda será realizada de forma exacta sin resolver los atributos. Cuando no se indica -d, entonces se resolverá el atributo. En el último ejemplo, el hecho de no indicar -d podría resultar en cientos de reglas de permisión: para cada dominio que tenga file_type activado, la búsqueda intenta encontrar reglas que permiten acceso de escritura al fichero en ese dominio en particular. Otra interesante funcionalidad de la orden sesearch es mostrarle las reglas que se aplican dependiendo del estado de un booleano. Si quiere consultar un booleano en particular, utilice -b. Si quiere ver la lógica que usa la directriz, utilice, -C (y, sí, ambas opciones se pueden combinar). A modo de ejemplo, comprobaremos qué permitimos (o denegamos) cuando el booleano global_ssp está habilitado.
El prefijo que se muestra al comienzo de las líneas consiste en dos letras, las cuales están relacionadas con dos definiciones importantes:
Obteniendo información del contexto de seguridad Mientras esté realizando labores de administración y especialmente cuando esté comprobando si se está produciendo una denegación SELinux, es importante averiguar qué contexto de seguridad se está empleando para un recurso en particular. Afortunadamente, si se instala adecuadamente, Gentoo Hardened ha modificado algunas herramientas para obtener esta información usando sus herramientas estándar. Para consultar el contexto de seguridad de un fichero, utilice ls -Z:
Para obtener el contexto de seguridad de un proceso, utilice ps -Z:
Para obtener el contexto de seguridad del usuario actual, utilice id -Z:
La gestión de los objetos de SELinux (booleanos, usuarios, puertos, contextos ...) se realiza en la mayoría de las ocasiones usando semanage. Debido a que esta aplicación ofrece la interfaz para varias configuraciones de SELinux, le dedicaremos una sección completa, aunque cubriremos también las órdenes que ofrecen una funcionalidad parecida (y que en algunas ocasiones son más fáciles de recordar). Hemos hablado de los booleanos de SELinux anteriormente en este libro así como de las órdenes getsebool and setsebool. Con semanage puede también gestionar los booleanos y, como valor añadido, al listar los booleanos también se mostrará su descripción (aunque queda aún trabajo por realizar en este área).
Puede definir el valor de un booleano con setsebool y semanage:
Los usuarios y cuentas de SELinux son diferentes de las de Unix. Las cuentas de SELinux le permiten asociar una cuenta Unix a un usuario SELinux:
El comportamiento por defecto es que los usuarios ingresan en el sistema como el usuario user_u de SELinux. Este usuario de SELinux es un usuario no administrador: no tiene privilegios específicos y se debe usar para para cada cuenta que nunca requiera elevar sus privilegios (por lo que no tendrá privilegios su o sudo para nada). La cuenta que use para administrar su sistema debe ser mapeada al usuario SELinux staff_u (o su propio usuario con los roles apropiados). Esto se puede conseguir de la siguiente forma (ejemplo con la cuenta Unix ana):
Como se ha mencionado, los usuarios SELinux están configurados para que puedan unirse a uno o más roles. Para listar los roles disponibles, puede usar semanage user -l:
Incluso los puertos (como el puerto 22 para SSH) están 'protegidos' por SELinux. Para echar un vistazo rápido de qué dominios están asignados a qué puertos (o rangos de puertos) utilice semanage port -l.
Hasta ahora hemos visto cómo obtener información relacionada con SELinux así como la gestión de los ajustes de SELinux. Sin embargo los usuarios de un sistema reforzado con SELinux necesitarán también saber algunas cosas acerca de cómo trabajar con SELinux, incluyendo (pero no limitándose a) roles y transiciones entre roles. Como una forma más del reforzamiento de un sistema de control de acceso, SELinux permite que algunos roles en particular estén en un conjunto de dominios. Si está utilizando un rol que no está permitido en un dominio en particular, no podrá usar ese dominio y se le denegará el acceso a las acciones asignadas a ese dominio. Si sus usuarios estándar son todos usuarios user_u de SELinux (soportándose únicamente el rol user_r), entonces estos usuarios nunca necesitarán cambiar a otro rol (aunque tampoco se les permitiría). Sin embargo, se tiene que dejar bien claro como cambian entre roles los usuarios que son staff_u (u otros usuarios que tienen múltiples roles). Hemos visto cómo asociar estos usuarios al usuario correcto SELinux (mire Usuarios y cuentas de SELinux). La orden que permite cambiar entre roles es newrole. Su uso es bastante lógico.
Cuando se realiza una transición de rol, SELinux pedirá que el usuario vuelva a autenticarse usando su contraseña. 4. Permisivo, no confinado, deshabilitado o lo que no...Cuando SELinux está disponible, normalmente se encontrará en uno de los tres estados de su sistema: deshabilitado, permisivo o forzado. Cuando la orden getenforce devuelve "Disabled", entonces SELinux no está corriendo en su sistema. Incluso aunque está construido en su núcleo, definitivamente está deshabilitado. Su sistema correrá con los controles de acceso discrecionales normales (las reglas de permiso usuales para los entornos Linux estándar), sin embargo, los controles de acceso obligatorio no estarán activos. Cuando SELinux está deshabilitado, esto significa que los ficheros, directorios, etc que se modifican o crean no obtendrán el contexto SELinux correcto que se les debe asignar. Cuando, más adelante, arranque su sistema con SELinux habilitado (permisivo o forzado), algunos problemas podrán surgir ya que el subsistema SELinux no conoce qué etiquetas tienen los ficheros (se usará una etiqueta por defecto que no es accesible por la mayoría de los dominios). La mejor forma de continuar en este caso es iniciar en modo permisivo y etiquetar de nuevo todo el sistema de ficheros:
Cuando se activa SELinux en modo permisivo (getenforce devuelve "Permissive"), entonces SELinux está habilitado y tiene cargada una directriz. Cada acceso que realiza un proceso se comprueba en las reglas de la directriz y, en caso de que un acceso no esté permitido, éste se registrará (a menos que la denegación esté marcada como dontaudit) pero no se prohibirá. El modo permisivo es perfecto para familiarizarse con SELinux y preparar el sistema para el modo "forzado" que se empleará en el futuro. Mientras se trabaja en modo permisivo, las aplicaciones que no están integradas con SELinux funcionará como si SELinux no estuviera instalado. Esta situación es perfecta para validar si un problema es causado por SELinux o no: si estando en modo permisivo el problema aún persiste, entonces el problema no lo está causando SELinux. Sin embargo, hay una salvedad: si la aplicación está integrada con SELinux (es decir, sabe que está corriendo en un entorno con SELinux activado y es capaz de hacer llamadas específicas de SELinux) puede que reaccione de forma diferente. Aunque esto es a menudo (pero no siempre) debido a unas malas prácticas en la programación, algunas aplicaciones comprueban si SELinux está activado y basan su flujo funcional en este resultado, independientemente si el estado es permisivo o forzado. Para averiguar si una aplicación está integrada o no con SELinux, simplemente compruebe si está enlazada con libselinux (haciendo ldd o scanelf, esto es parte del paquete app-misc/pax-utils):
Si la orden getenforce devuelve "Enforcing", entonces SELinux esta cargado y actuará en base a la directriz. Cuando un proceso intenta realizar alguna actividad que no está permitida por la directriz, esta actividad será registrada (a menos que se defina un dontaudit) y no se permitirá la continuidad de la actividad. Este es el único modo en el que puede decir que SELinux está verdaderamente activo, ya que es el único momento en que la directriz está actuando. Dependiendo de su configuración del núcleo Linux, puede conmutar entre estados utilizando los siguientes métodos. La configuración del núcleo puede, sin embargo, hacer que alguna de estas opciones estén deshabilitadas (por ejemplo, un sistema hardened que no permita deshabilitar SELinux de ningún modo). Usar la orden setenforce:
Usar la opción de inicio enforcing del núcleo:
Usar la variable SELINUX /etc/selinux/config:
Cuando quiera cambiar del modo permisivo al forzado, se recomienda hacerlo en el orden descrito arriba:
Puede también optar por marcar un solo dominio permisivo mientras ejecuta el resto del sistema en modo forzado. Por ejemplo, para marcar mplayer_t como un dominio permisivo (lo que implica que SELinux no forzará nada):
Con la opción -d, puede eliminar la marca permisiva de nuevo. 4.b. Tipos de directriz SELinux Aparte del estado de SELinux, también se ofrecen distintos tipos de directriz. Estos tipos se diferencian entre ellos en que tienen características específicas de SELinux habilitadas o deshabilitadas. Dentro de Gentoo, se soportan tres (una cuarta también está disponible, como veremos): targeted, strict, mcs (y mls). El tipo utilizado en un sistema se declara en /etc/selinux/config:
strict (sin dominios no confinados) El tipo de directriz strict es aquél que se describió en capítulos anteriores y casualmente se trata del tipo más fácil de comprender. Con el tipo de directriz strict, todas y cada una de las aplicaciones que se ejecutan lo hacen en un dominio que tiene privilegios limitados. Aunque hay dominios altamente privilegiados, nunca son ilimitados en sus privilegios. targeted (utilizando dominios no confinados) El tipo de directriz targeted es similar al strict con un añadido importante: el soporte para dominios no confinados. Las aplicaciones (o usuarios) que corren en un dominio no confinado prácticamente no tienen límite en sus privilegios. Los dominios no confinados se utilizan normalmente para los usuarios y las aplicaciones de usuario, sin embargo, el inicio del sistema y otros dominios se marcan también como "no confinados". La idea detrás de la directriz targeted es que los servicios orientados a red que están corriendo en dominios (confinados) regulares mientras que el resto utiliza el control de acceso discrecional estándar que ofrece Linux. Estos otros dominios corren como "no confinados". mcs (utiliza categorías múltiples) La introducción de mls y mcs ofrece la capacidad multi-tenancy: varias instancias de la misma aplicación pueden ejecutarse, pero cada instancia se debe confinar respecto a las otras (en lugar de tener todos los procesos en el mismo dominio y por lo tanto los mismo privilegios). Un ejemplo sencillo es la virtualización: una máquina virtual que corre en el dominio qemu_t necesita privilegios de escritura en el fichero imagen que contiene el sistema operativo de la máquina virtual. Sin embargo, si correo dos máquinas, no deseará que una de ellas escriba en el fichero imagen de la otra y viceversa. Con dominios regulares, necesitará ofrecer este comportamiento. Con mcs, puede darle a cada instancia en ejecución una categoría específica (un número) y únicamente conceder privilegios de escritura al fichero de la máquina virtual con la categoría (el número) correcta. mls (utilizando múltiples niveles de seguridad) El tipo de directriz mls está disponible, pero aún no está soportado por Gentoo Hardened. Con este tipo de directriz, es posible ofrecer niveles de sensibilidad a ficheros y recursos así como a dominios. Los niveles de sensibilidad se pueden expresar mejor en los términos public, private, confidential o strictly confidential (público, privado, confidencial o estrictamente confidencial). Con MLS, puede marcar un fichero con un (o un conjunto) nivel de sensibilidad y asegurarse de que únicamente los dominios con el nivel de sensibilidad correcto puede acceder a él. No se recomienda conmutar entre tipos con frecuencia. En el mejor de los casos, elegimos un tipo de directriz en el momento de instalar y nos ajustamos a él. No es imposible (ni tampoco muy difícil) cambiar entre tipos. Asegúrese de que su variable POLICY_TYPES en make.conf ya contiene el tipo de directriz destino y que se han reconstruido los paquetes de la directriz de SELinux. Si este no es su caso, edite la variable POLICY_TYPES para incluir la directriz destino y reconstruya todos los paquetes de directriz SELinux utilizando emerge $(qlist -IC sec-policy). Ahora cambie sus sistema la modo permisivo (permissive) utilizando setenforce 0 o, si su sistema no permite el cambio de modo, edite /etc/selinux/config para que el sistema arranque en modo permisivo. Si no puede utilizar setenforce 0 entonces necesitará reiniciar ahora de modo que el sistema funcione en modo permisivo. A continuación, edite /etc/selinux/config y cambie la variable SELINUXTYPE de la directriz actual a la nueva. Esto le indicará a SELinux que cargue la directriz correcta cuando se inicie el sistema. Ahora vaya a los módulos construidos para la directriz en /usr/share/selinux ya que necesitamos cargar la nueva directriz (ya que actualmente el sistema está corriendo con la antigua). El ejemplo de abajo muestra como hacer esto si viene de un tipo de directriz estricto strict y quiere ir al tipo mcs:
Ahora su sistema está corriendo con la directriz mcs cargada, pero observará que se producen múltiples denegaciones de acceso a la hora de realizar cualquier acción en el sistema de ficheros, ya que los ficheros de su sistema no están etiquetados correctamente: El tipo de directriz mcs requiere a las etiquetas tener una etiqueta de sensibilidad sobre ellas, lo cual no es el caso si utiliza la directriz estricta. Por lo tanto, reetiquetemos completamente el sistema de ficheros, incluyendo aquéllas localizaciones que podrían estar ocultas debido a que otros sistemas de ficheros se han montado sobre ellas.
Para terminar, edite /etc/fstab y actualice los parámetros rootcontext= para incluir también una etiqueta de sensibilidad (en caso de que cambiara a mcs o mls) o ninguna (en caso de que cambiara a targeted o strict).
Una vez realizadas todas estas acciones, reinicie su sistema para asegurarse de que funciona correctamente (también la secuencia de arranque). 5. Modificar la directriz de SELinux en Gentoo Hardened5.a. Lenguaje de la directriz SELinux Por defecto, Gentoo ofrece una directriz genérica aunque altamente controlada que es considerada como una buena directriz de comienzo para todos los usuarios. Sin embargo, el propósito detrás de los sistemas de Control de Acceso Obligatorio es que el administrador de seguridad tome el control. Por lo tanto, un manual sobre SELinux sin información acerca de como escribir directrices no estaría completo. En este capítulo, hablaremos un poco sobre el lenguaje que hay detrás de las directrices SELinux y daremos algunos consejos sobre cómo crear sus propias directrices, roles, etc. Construyendo un módulo SELinux En primer lugar, antes de que descubramos el arte sobre la escritura de directrices SELinux, crearemos un pequeño módulo SELinux con una regla que podamos probar, construiremos el módulo y veremos si las cosas funcionan. A pesar de que estos pasos son muy fáciles de realizar, son muy importantes. Modificar la directriz SELInux tal y como la ofrece Gentoo se lleva a cabo de mejor forma a través de las directrices de módulo adicionales. Solo cuando la directriz principal (la directriz base) no es de su agrado, deberá plantearse el uso de una directriz completamente distinta. Comencemos con un esqueleto para un módulo de directriz que llamaremos testmod. Utilice nombres simples para los módulos ya que la infraestructura de construcción es muy sensible a nombres especiales. Utilice únicamente letras de la a a la z y números, y nunca comience el nombre de un módulo con un número.
Sí, eso es todo. Pero, como puede observar, está prácticamente vacío. Añadamos una regla que permita a un usuario normal (en el dominio user_t) leer ficheros ebuild (de tipo portage_ebuild_t).
Como puede ver, algo tan simple como permitir a un usuario leer ficheros requiere unos cuantos privilegios. Los privilegios de directorio son necesarios para permitir a un usuario navegar por la estructura de árbol de Portage, mientras que los privilegios de fichero son necesarios para que el usuario puede acceder y abrir los ebuilds. Guarde este fichero con el nombre testmod.te. Para construir la directriz y convertirla en un módulo binario que se pueda cargar en el almacén de directriz SELinux, podemos utilizar el fichero Makefile disponible en /usr/share/selinux/strict/include (sustituya strict por el tipo de directriz SELinux que esté utilizando).
El nombre de fichero (testmod.pp) es el nombre para el fichero binario SELinux destino. El Makefile buscará automáticamente el fichero testmod.te que tiene en su directorio de trabajo. Deberá obtener como resultado un fichero llamado testmod.pp. Este fichero de módulo se puede ahora cargar en el almacén de directriz SELinux de la siguiente forma:
¡Enhorabuena! Acaba de construir su primer módulo de directriz SELinux. Si quiere deshabilitarlo, elimínelo usando semodule -r testmod. Este método de construcción de una directriz (utilizando el Makefile y semodule) es algo que necesitará hacer cada vez que actualice la directriz SELinux en su sistema. El contenido de la directriz, sin embargo, cambia como veremos en el resto de este documento. Obtener las interfaces de directriz SELinux Para hacer más rápido el desarrollo de directrices, la directriz SELinux basada en la directriz de referencia utiliza interfaces para acceder a los privilegios dentro de un módulo. Si ha construido selinux-base-policy con USE="doc" entonces esta información está disponible en /usr/share/doc/selinux-base-policy-<versión>/html. Se recomienda tener esta información a mano ya que la mayoría de los desarrollos o actualizaciones se realizarán utilizando las interfaces que ofrece la directriz. Si está interesado, puede también encontrar estas definiciones de interfaz en línea. Recuerde que este recurso en línea es únicamente la directriz de referencia y puede variar un poco de la disponible en Gentoo. El uso de interfaces de directriz le permite actualizar la directriz con funciones más legibles. Por ejemplo, para permitir al dominio user_t domain llamar y utilizar aplicaciones Portage, el módulo podría tener el siguiente aspecto:
Desde luego, esto hace que el dominio user_t tenga más privilegios que las reglas definidas anteriormente para leer fichero ebuild: permite al usuario llamar a portage, actualizar el sistema, etc. Desde luego, el usuario todavía necesita los permisos comunes de Linux apropiados (por lo que necesita pertenecer al grupo portage o poder convertirse en root). Por supuesto, no recomendamos conceder esto a un usuario regular ;-) 5.b. Módulos completos de directriz SELinux Teniendo en cuenta lo de arriba, podemos avanzar un poco más e investigar un módulo de directriz completo, con las reglas de forzado de tipos (fichero .te), los ficheros de contextos (.fc) e interfaces (.if). Debería saber que escribir un módulo requiere familiarizarse con la aplicación. Es cuestión de simplemente esperar lo mejor: como administrador de seguridad, será el responsable de definir qué accesos se permiten y cuáles no. Si olvida alguno, la aplicación se podría romper en las manos de los usuarios. Pero, si añade demasiados, podría estar concediendo privilegios de los cuales se podría abusar en adelante. También sería más complicado hacer un seguimiento y eliminar privilegios más adelante ya que se dudaría de si ese privilegio es necesario o no. En esta sección, no discutiremos como crear uno. Tenemos un excelente recurso: Desarrollo SELinux en Gentoo Hardened que le guía en ese proceso. Sin embargo, echaremos un vistazo a ese módulo completo para explicar otros aspectos del desarrollo de directrices. El fichero .te que escribimos anteriormente es un fichero de forzado de tipos. Se utiliza para definir reglas de acceso al módulo que se está construyendo, pero también, y más importante, define nuevos tipos (e incluso roles). El ejemplo de abajo es un extracto de un módulo para la aplicación skype.
En el ejemplo de arriba, se declaran tres nuevo tipos: skype_t (que se usará para la aplicación), skype_exec_t (que es la etiqueta que se asigna al binario de la aplicación) y skype_home_t (que se utilizará para la ubicación del fichero de usuario ~/.Skype). También, se asignan al dominio skype_t algunos privilegios con respecto a la etiqueta skype_home_t (gestionar directorios y ficheros). Fichero de contexto de ficheros En el fichero .fc (cuya extensión significa file context file o fichero de contexto de ficheros), se definen los recursos del modulo (ficheros, directorios, zócalos, etc.). Una vez se carga el módulo, estas reglas se añaden de forma que el reetiquetado del sistema de ficheros asignará los contextos correctos a cada uno de los ficheros. El ejemplo de abajo es un extracto del fichero de contexto de ficheros del módulo skype.
El formato del fichero tiene la siguiente sintaxis:
En el fichero .if (que significa interface file o fichero de interfaz), se declaran las interfaces que pueden usar otros módulos. Es, mediante el uso de interfaces, la forma en la que una directriz definida se puede construir de forma adecuada sobre otros módulos existentes. Una interfaz podría usarse para permitir a los usuarios llamar y ejecutar una aplicación. Por ejemplo, podemos encontrar en el módulo skype, la siguiente interfaz.
A través de este skype_role, podemos permitir a los usuarios que llamen a skype, tal y como se indica en el fichero unprivuser.te (el cual define el dominio user_t):
La siguiente tabla muestra algunas interfaces comunes que se podrían utilizar. Recomendamos echar un vistazo a las interfaces disponibles cuando cree o mejore sus propios módulos. Asegúrese de elegir la interfaz que añade exactamente lo que necesita y nada más.
Cuando lea los recursos disponibles en línea sobre SELinux, observará que hay muchas referencias a una herramienta llamada audit2allow. El propósito de esta herramienta es leer los mensajes de denegación AVC del registro de auditoría y transformarlos en un módulo de directriz que se pueda cargar. La ventaja aquí es que hace bastante más fácil la escritura de directrices. La parte mala es que la salida (a menos que utilice la opción -R) no se puede utilizar en el fichero Makefile que utilizamos anteriormente para construir módulos. Otra desventaja es que la herramienta no actúa inteligentemente ante los cambios. Acepta las denegaciones a ciegas y las trata como si debieran ser permitidas en lugar de investigar si se deberían asignar otros contextos al fichero, etc. El uso de audit2allow es bastante simple. Se le envían las denegaciones que quiere corregir y se almacena el resultado en un fichero .te. Puede entonces convertir este fichero a un formato intermedio que se puede traducir a un fichero .pp para cargarlo finalmente con semodule. Por ejemplo, para capturar todas las denegaciones y transformarlas en sentencias válidas para las denegaciones relacionadas con firefox:
El nombre del módulo (indicado mediante la opción -m) debe ser sencillo: únicamente utilice caracteres ([a-z]) y números ([0-9]), y comience el nombre del módulo con un carácter. Si desea crear roles adicionales en el sistema, en primer lugar necesitará crear un módulo SELinux que cree ese rol, a la vez que su dominio principal. Abajo se muestra un ejemplo muy sencillo para un rol de administración de base de datos, el cual ofrecemos a través del paquete sec-policy/selinux-dbadm:
Construya y cargue el módulo y verifique que el rol está disponible:
A continuación, asigne a los usuarios el rol que acaba de crear. Puede hacerlo con usuarios SELinux ya existentes, pero, en este caso, crearemos un usuario SELinux adicional para el rol.
Lo siguiente es mapear el usuario(s) a este usuario SELinux.
También se debe cargar la siguiente directriz para dar soporte a la transición hacia el rol dbadm_r para el rol staff_r:
En la primera orden semanage, en la que creamos el usuario dbadm_u, puede observarse que le hemos concedido el rol system_r. Esto se debe a que al usuario se le concede el rol postgresql_admin, permitiendo a ese usuario la manipulación del guión de inicio de postgresql:
Gracias al soporte SELinux en sudo, puede también mencionar el rol y tipo en el fichero sudoers:
Con este ajuste, el usuario puede ejecutar simplemente sudo /etc/init.d/postgresql restart. Utilizando sudo de forma correcta, se puede conceder al usuario derechos completos de administración sobre un demonio (incluyendo la edición de ficheros), con bastante menor riesgo de que el usuario pueda escalar sus privilegios a un rol administrativo con más privilegios sobre el sistema. La idea detrás de este enfoque es que el usuario permanezca en su dominio principal (como staff_t) pero que se le permita realizar acciones administrativas a través de sudo lo que le permite (de forma temporal) realizar la transición al rol dbadm_r. role. 6. Solucionando problemas con SELinux6.a. No se puede cargar la directriz de SELinux Si observa que SELinux no está funcionando, puede ejecutar sestatus para ser informado rápidamente si SELinux está habilitado y cargado o no. Si obtiene la siguiente salida, entonces ninguna directriz de SELinux se ha cargado:
Si éste es el caso, continúe leyendo esta sección para averiguar cómo corregir esta situación. No hay ninguna directriz instalada Una raíz potencial de este problema es que no hay ninguna directriz con la que comenzar. Eche un vistazo a /usr/share/selinux/strict o a /usr/share/selinux/targeted (dependiendo de su configuración) y busque un fichero llamado base.pp. Si no existe este fichero, necesitará instalar la directriz base. Esta directriz se ofrece con el paquete sec-policy/selinux-base-policy, pero es mejor leer el capítulo relacionado con la Instalación de Gentoo SELinux / Conversión ya que podría pasar por alto detalles importantes. Si existe el fichero base.pp en /usr/share/selinux/strict (o en targeted/), eche un vistazo a /etc/selinux/strict/policy. Esta localización también debería contener un módulo de directriz base.pp (cuando se carga una directriz de SELinux, se copia desde la primera localización a la segunda). Si no existe el fichero base.pp, instale la directriz y cárguela:
Esto es una operación que se realiza solo en una ocasión. Una vez instalada y cargada, ésta será recargada en cada reinicio. Init no puede cargar la directriz SELinux Durante el inicio del sistema, el proceso init es el responsable de cargar e interactuar con la directriz SELinux en memoria. Si init no soporta SELinux, su entorno no dispondrá de soporte para SELinux. Para verificar si init soporta SELinux, necesitamos comprobar si utiliza el objeto compartido libselinux.so:
Si éste no es el caso, asegúrese de que emerge --info muestra que el ajuste USE selinux está en su sitio y reinstale sys-apps/sysvinit. Si este ajuste no está definido, compruebe su perfil Gentoo y asegúrese de que apunta a un perfil selinux/v2refpolicy/.... El almacén de directices está corrupto Si aparecen problemas en el inicio del sistema o en operaciones semodule que fallan con problemas en la carga pero no se puede resolver con la solucón de arriba, entonces necesitará reinstalar las directrices una vez eliminado el almacén corrupto.
Esto desactivará efectivamente el almacén corrupto actual de la directriz de SELinux y utilizará Portage para reinstalar todos los paquetes de directriz que se han instalado en el sistema. Cuando haya terminado, los contextos de fichero de /etc/selinux serán restaurados, después de lo cual podrá continuar. 6.b. No se puede ingresar en el sistema Si no puede ingresar en el sistema en una situación en particular (en remoto, en local, como root, como usuario regular,...) puede que se esté encontrando con algún problema sin mucha importancia. Sin embargo, para resolverlo tendrá que ingresar en el sistema como sysadm_r de un modo u otro. Si no puede ingresar como un usuario sysadm_r, deshabilite SELinux (arranque con enforcing=0) de este modo no se realiza ningún forzado SELinux. Los cambios que haga en modo permisivo son igual de efectivos que en el modo forzado (enforcing). En la mayoría de los casos encontrará que el problema es un contexto de seguridad incorrecto. Ejecute sestatus -v y compare los contextos de proceso o los contextos de fichero que observe con los dados en la siguiente tabla.
6.c. No se puede hacer emerge de ningún paquete (OSError: [Errno 22] Invalid argument) Cuando se intenta instalar software con Portage, se obtiene un volcado enorme de la pila de python y finalmente el mensaje de error OSError: [Errno 22] Invalid argument:
El error de arriba se produce cuando se lanza portage (mediante emerge) y no nos encontramos en el contexto sysadm_t. Puede verificar esto con id -Z:
Portage fallarán mientras el contexto utilizado no sea sysadm_t. Esto es debido a que Portage quiere cambiar su contexto de ejecución de portage_t a portage_sandbox_t, sin embargo no puede conseguirlo (para empezar, no está en portage_t debido a que el usuario que lanzó Portage no está en sysadm_t). Por favor, compruebe la sección No se puede ingresar en el sistema de arriba en primer lugar. También, asegúrese de que puede hacer dispatch-conf o etc-update después de instalar SELinux de modo que se actualice /etc/pam.d/system-login con las llamadas correctas a pam_selinux.so. Si necesita forzar a Portage para que continúe a pesar de todo (por ejemplo, se encontraba en medio de una instalación de SELinux por lo que no puede resolver esas cuestiones ahora), ejecute la orden emerge pero con FEATURES="-selinux". Esto deshabilitará efectivamente la integración de SELinux en Portage y permitirá continuar con la instalación del software.
¡Asegúrese de que etiqueta de nuevo todo el sistema de ficheros después de aplicar este enfoque!. Portage no etiquetará correctamente los ficheros instalados en el sistema si deshabilita el soporte SELinux. Para etiquetar de nuevo todo el sistema de ficheros, utilice rlpkg -a -r. 7. Historial de cambiosEste documento ofrece una vista rápida de todos los cambios en SELinux documentados y que se han realizado en fechas particulares y que por tanto pueden ser de importancia para los usuarios hagan un seguimiento de los mismos. Los cambios que únicamente afectan a los usuarios con instalaciones de prueba (~arch) se documentarán abajo y se moverán más arriba en el documento cuando se realice su estabilización. Sin embargo, es posible que estos cambios se "corrijan" de forma automática y por tanto se eliminen de esta página. 7.b. Vista rápida de los cambios para usuarios de instalaciones estables 16/04/2013 - Presentar el guión de inicio selinux_gentoo Con el paquete policycoreutils-2.1.13-r8 y los posteriores, ofrecemos nuestro propio guión de inicio selinux_gentoo, el cual incluye el soporte necesario para los usuarios con initramfs en sus sistemas, también reinicia los contextos de los recursos generados dinámicamente (en pseudo sistemas de ficheros) que son distintos de los ajustes por defecto. El primer usuario a tener en cuenta es /sys/devices/system/cpu/online el cual obtiene labeled cpu_online_t (desde la revisión 13 de la directriz SELinux, o cuando se están utilizando ebuilds live para la directriz). El guión de inicio también restaurará por defecto los contextos de todos los dispositivos /dev (a menos que el sistema se inicie con la opción norestorecon) y cambiará al modo forzado (enforcing) si /etc/selinux/config tiene definido SELINUX=enforcing y el usuario inició el sistema con enforcing=0 (a menos que inicie con la opción nosetenforce). Esto significa que ahora se recomienda a los usuarios que añadan este guión al nivel de ejecución boot:
04/12/2012 - Presentar USE=unconfined A partir de la versión selinux-base-2.20120725-r9, se da soporte al ajuste USE=unconfined. Cuando éste se habilita, configurará su directriz SELinux para dar soporte a dominios no confinados. Si su directriz es targeted, este comportamiento estará implícito, mientras que la directriz strict no considerará este ajuste USE de ningún modo (no activará dominios no confinados en strict). El soporte de este ajuste USE, nos permite diferenciar entre dominios no confinados y dominios regulares cuando utilizamos los tipos de directriz mls o mcs. Cuando está definido, se construirá también el paquete selinux-unconfined, y el módulo se cargará, e igualmente, se actualizará el fichero de directriz seusers (el cual contiene los mapeas de los dominios por defecto para los usuarios) para utilizar el usuario SELinux unconfined_u para root y otros usuarios. 16/08/2012 - Añadir el rol system_r a los administradores Desde la versión selinux-base-2.20120725-r3 y en las posteriores, los guiones de inicio ahora ofrecen soporte al enfoque "etiquetado" (labeled) del guión de inicio ofrecido por el equipo de desarrollo principal. Esto implica que los servicios cuyo guión de inicio siguen la convención de nombres <domain>_initrc_exec_t se pueden asignar ahora a usuarios específicos (permitiendo a éstos gestionar servicios sin necesidad de concederles privilegios de administración del sistema). Lo malo de este enfoque es que el propio administrador del sistema (que utiliza el dominio sysadm_t) ahora necesita que se le conceda el privilegio de gestionar esos servicios. Y el hecho de concederle este privilegio implica que el usuario SELinux (sea root o staff_u) necesita que se le conceda el rol system_r:
24/06/2012 - Definición de /run en fstab Se necesita montar la localización /run con el contexto var_run_t. Para hacer esto, se debe modificar /etc/fstab según las instrucciones dadas en Ajustar los contextos del sistema de ficheros. 26/05/2012 - Soporte de initramfs Los usuarios que inician su sistema con un initramfs necesitarán iniciar en primer lugar en modo permisivo, y a continuación cambiar a modo forzado. Esto se puede realizar de forma automática utilizando un guión de inicio, tal y como se documenta en Usuarios de Initramfs. 26/05/2012 - Soporte para gestores gráficos de ingreso en el sistema Los usuarios que inicien en un entorno gráfico (como GDM) tendrán que editar sus ficheros de configuración PAM de forma adecuada para dar soporte a las definiciones de contexto de seguridad de SELinux. Esto está documentado en Usuarios de entornos gráficos. 18/05/2012 - Ya no es necesario configurar sandbox La edición previa de la documentación de /etc/sandbox.conf para permitir la escritura abierta de /sys/fs/selinux/context se puede eliminar ya que el perfil de SELinux lo hace ahora de forma automática. 29/04/2012 - No es necesario editar los guiones lvm-start/stop Cuando el usuario instala las nuevas directrices estables 2.20120215, la edición documentada de /lib/rcscripts/addons/lvm-st*.sh ya no es necesaria. 21/02/2012 - La línea de montaje /dev en fstab ya no es necesaria La documentación previa de la línea de montaje /dev mount in /etc/fstab ya no es necesaria ya que util-linux-2.20.1-r1 se ha marcado como estable (la cual ya contiene la corrección correcta). 10/12/2011 - Depreciación de los perfiles selinux/v2refpolicy/* Los antiguos perfiles de SELinux (los que comienzan por selinux/v2refpolicy) ya no tienen soporte. Se recomienda encarecidamente a los usuarios que cambien a los nuevos perfiles (los que terminan en /selinux). 22/07/2011 - Introducción del soporte para MLS/MCS Actualmente ofrecemos soporte para MLS y MCS, para los tipos de directriz SELinux targeted y strict SELinux. Cuando utilice MLS o MCS, necesitará actualizar la entrada /tmp en su /etc/fstab para que utilice rootcontext=system_u:object_r:tmp_t:s0 (observe el :s0 al final). 7.c. Vista rápida para los usuarios de instalaciones de prueba (~Arch) 19/04/2013 - Presentar la orden selocal Con la aparición de policycoreutils-2.1.13-r11 y versiones posteriores, se dispone de una nueva orden llamada selocal. Esta orden permite a los usuarios añadir fácilmente a la directriz local, reglas de directriz SELinux adicionales sin tener que realizar la tarea de mantener y construir sus propios ficheros .te. En lugar de eso, esta orden hace todo el trabajo. Las reglas que se añaden a la directriz local (de ahí su nombre, selocal) se pueden acompañar de un pequeño comentario para que los usuarios describan porqué realizan determinado cambio (o para hacer referencia a un identificador de incidencia en el bugzilla de Gentoo).
Con --list se muestran las reglas que se han añadido a la directriz local, y con --delete se pueden eliminar de la directriz local. Cuando quiera que los cambios tengan efecto, ejecute selocal --build --load para construir la nueva directriz local y cargarla en memoria. 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. |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||