|
[ << ] [ < ] [ Inicio ] [ > ] [ >> ] 2. Configurar SELinux para adaptarlo a sus necesidadesContenido:
A lo largo de la instalación, hemos hablado de como mapear un usuario Linux a uno SELinux. En el ejemplo, hemos utilizado un usuario hipotético llamado "juan" y lo hemos mapeado al usuario SELinux "staff_u". Si está corriendo un sistema multiusuario, la gestión de los mapeos de derechos es importante. Un usuario que se mapea al usuario "user_u" no obtendrá ningún derecho adicional. Incluso si le concediera derechos adicionales a través de órdenes como sudo, la directriz de SELinux no le permitiría a este usuario hacer nada que esté relacionado con la administración. Por esta razón, es importante tratar los mapeos de usuarios en SELinux y los usuarios Linux de su sistema. 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. [ << ] [ < ] [ Inicio ] [ > ] [ >> ] El contenido de este documento, a no ser que se especifique expresamente, está registrado bajo los términos de la licencia CC-BY-SA-2.5. Se aplican las Pautas de Utilización del logotipo y nombre de Gentoo. |
|