Preguntas frecuentes (FAQ) sobre SELinux en Gentoo HardenedEl uso de SELinux requiere que los administradores tengan un conocimiento extenso de su sistema y una buena información de como se deben comportar los procesos.. Aparte de nuestro Manual de SELinux para Gentoo Hardened, una serie de preguntas frecuentes nos permite informar y ayudar a los usuarios en su experiencia diaria con SELinux. Estas preguntas es un resumen de las soluciones dadas en IRC, listas de correo, foros o en otros lugares. Se centran en la integración de SELinux integration en Gentoo Hardened, sin embargo, también surgen preguntas generales sobre SELinux que se han ido incorporando igualmente. Preguntas generales sobre soporte SELinux
Utilizar SELinux
Mensajes de error del núcleo SELinux
SELinux y Gentoo
2. Preguntas generales sobre soporte SELinux ¿Fuerza SELinux los límites de los recursos? No, los límites de los recursos están fuera de la gestión de un sistema de control de acceso. Si está buscando soporte en este tipo de cuestiones, eche un vistazo a tecnologías como grsecurity, cgroups, pam y otras del estilo. ¿Puede utilizar SELinux con grsecurity (y PaX)? Por supuesto, de hecho es lo que recomendamos. Si embargo, se recomienda evitar el uso del soporte que tiene grsecurity para ACL ya que podría ser redundante en el control de acceso de SELinux. ¿Puedo utilizar SELinux con el compilador hardened (usando PIE-SSP)? Por supuesto, también recomendamos utilizar PaX para tener todas las ventajas de las características PIE que ofrece el compilador. ¿Puedo utilizar SELinux y RSBAC? Sí, SELinux y RSBAC se pueden utilizar conjuntamente, pero no lo recomendamos. Ambos marcos de trabajo (RSBAC y la implementación de SELinux encima del marco de trabajo de los módulos de seguridad de los sistemas Linux) tienen un pequeño impacto en el rendimiento del sistema. Si se habilitan ambos, se tendrá una penalización en el rendimiento, obteniendo poc valor añadido ya que ambos ofrecen una funcionalidad they both offer similar functionality. En la mayoría de los casos, es más prudente utilizar RSBAC sin SELinux, o SELinux sin RSBAC. ¿Puede utilizar SELinux con cualquier sistema de ficheros? SELinux requiere acceso al contexto de seguridad de los ficheros para funcionar correctamente. Para ello, SELinux utiliza los atributos extendidos de fichero que deben por tanto ofrecer los sistemas de ficheros con los que se opere. Si el sistema de ficheros soporta los atributos extendidos de fichero y ha configurado su núcleo para habilitar este soporte, entonces SELinux funcionará en esos sistemas. Los sistemas de ficheros generales, tales como: ext2, ext3, ext4, jfs, xfs y btrfs ofrecen soporte para atributos extendidos (pero no olvide habilitarlo en la configuración del núcleo), el sistema tmpfs también ofrece este soporte (por ejemplo para que lo utilice udev). Si su colección sistema de ficheros se limita a este conjunto, entonces no debería tener problemas. Se soportan también los sistemas de ficheros anticuados como vfat e iso9660, pero con una importante limitación: todos los ficheros en cada uno de los sistemas de ficheros tendrán la misma información de contexto de seguridad ya que estos sistemas no ofrecen soporte para atributos extendidos de ficheros. Se puede dar soporte a Los sistemas de ficheros en red de la misma forma que a los sistemas de ficheros anticuados (todos los ficheros comparten el mismo contexto de seguridad). Sin embargo, se ha realizado algún esfuerzo de desarrollo para ofrecer atributos extendidos en sistemas populares como NFS. Aunque todavía estamos lejos de que esto se pueda utilizar en un sistema de producción, parece que algún día también se ofrecerá soporte completo para estos sistemas en SELinux. ¿Puedo utilizar SELinux con AMD64 no-multilib? Sí, simplemente utilice el perfil hardened/linux/amd64/no-multilib/selinux y ya estará preparado. UBAC (User Based Access Control) o Control de Acceso Basado en Usuario, introduce límites adicionales cuando se usa la directriz de SELinux. Los dominios o tipos que participan y que han sido ambos marcados como ubac_constrained_type (que es un atributo) tendrán los privilegios permitidos en efecto únicamente si ambos están corriendo con el mismo contexto de usuario SELinux.
Desde luego, este no es siempre el caso. Aparte del requerimiento mencionado anteriormente de que ambos tipos sean ubac_constrained_type, si el dominio origen es sysadm_t, entonces la limitación no tendrá efecto (el dominio sysadm_t está exento de las limitaciones UBAC). También, si el usuario SELinux origen o destino es system_u entonces la limitación tampoco tendrá efecto. Esto se explica en el Manual de SELinux para Gentoo en el capítulo Usar SELinux en Gentoo Hardened. ¿Como cambio entre los modos permissive y enforcing (permisivo y forzado)? La forma más fácil es utilizar la orden setenforce. Con setenforce 0 le indica a SELinux que quiere trabajar en modo permisivo. De igual modo, con setenforce 1 le indica a SELinux para que trabaje en modo forzado. Puede también añadir una opción a l núcleo enforcing=0 o enforcing=1 en la configuración del gestor de arranque (o durante la rutina de inicio del sistema). Esto le permite correr SELinux en modo permisivo o forzado desde que el sistema se inicia. El estado por defecto del sistema se guarda en /etc/selinux/config. ¿Cómo deshabilito SELinux completamente? Puede ocurrir que, ejecutar SELinux en modo permisivo no sea suficiente para corregir apropiadamente los problemas que vayan surgiendo. Para deshabilitar SELinux completely, necesitará editar /etc/selinux/config y ajustar SELINUX=disabled. A continuación, deberá reiniciar su sistema.
¿Cómo averiguo qué regla de contexto de fichero se está utilizando para un fichero en particular? Si utiliza la orden matchpathcon, obtendrá el contexto de seguridad que se debería estar utilizando para una determinada ruta (sea fichero o directorio), sin embargo, esto no le muestra que regla se utiliza para deducirlo. Para ello, puede utilizar findcon:
Cuando las utilidades de SELinux están tratando de aplicar un contexto, intentarán que concuerde la regla más específica, por lo que, en el caso de arriba es la que nos lleva al contexto initrc_state_t. La más específica significa, en el orden de pruebas:
Sin embargo, cuando añada sus propios contextos de fichero (utilizando semanage), estas condiciones no se aplican. En lugar de esto, las herramientas como restorecon ¡tomarán la última coincidencia dentro de los contextos de fichero localmente añadidos! Puede comprobar el contenido de las reglas añadidas localmente en /etc/selinux/strict/contexts/files/file_contexts.local (sustituya strict con su tipo SELinux). ¿Cómo realizo pequeños cambios (adiciones) a la directriz? Si está interesado en el desarrollo de SELinux en Gentoo Hardened, por favor, eche un vistazo a la Guía de desarrollo de SELinux y otra documentación mostrada en la página de proyecto de SELinux (en inglés). Sin embargo, en alguna ocasión, necesitará conservar algunos cambios en su directriz debido a cómo ha configurado su sistema o cuando necesite permitir alguna acción que no vaya a ser aceptada como un cambio en la directriz que afecta a toda la distribución. En ese caso, continúe leyendo. Las actualizaciones de la directriz son posibles únicamente cuando necesite permitir privilegios adicionales. No es posible eliminar reglas de la directriz, solo mejorarlas. Para mantener su propio conjunto de reglas adicionales, cree un fichero en el que conserve sus cambios. En el siguiente ejemplo, usaré el término fixlocal, sustitúyalo por el nombre que desee, pero mantenga ese nombre consistente. En el fichero (fixlocal.te) escriba el siguiente texto (de nuevo, sustituya fixlocal por el nombre que haya elegido):
En este fichero puede añadir las reglas que desee. En el siguiente ejemplo, añadiremos tres reglas:
Si necesita ofrecer sentencias de permisión (como la descrita arriba para el dominio mozilla_t), asegúrese de que el tipo (mozilla_t), clase (process) y privilegio (execmem) se mencionan en el párrafo require { ... }. Cuanto utilice nombres de interfaz, asegúrese de que los tipos (ssh_t y user_t) se mencionan en el párrafo require { ... }. Para encontrar el nombre adecuado de la interfaz (como la corenet_tcp_connect_all_ports de arriba), puede, bien, echar un vistazo en línea a la API de la Directriz de Referencia de SELinux o, si se ha construido sec-policy/selinux-base-policy con el ajuste USE doc, en los ficheros /usr/share/doc/selinux-base-policy-.*/html. Desde luego, también puede pedir ayuda en el canal #gentoo-hardened de irc.freenode.net, la lista de correo, los foros, etc. para encontrar las reglas y sentencias adecuadas para su caso. Una vez creado el fichero de directriz, puede construirla utilizando el fichero Makefile que ofrece el sistema:
A continuación, si la construcción es correcta, puede cargarla en memoria. Una vez cargada, ésta será cargada en cada inicio, de modo que no necesitará repetir esto una y otra vez.
4. Mensajes de error del núcleo SELinux Obtengo un error register_security cuando arranca el sistema Durante el arranque del sistema, se muestra el siguiente mensaje:
No hay nada de lo que preocuparse (es perfectamente normal). Esto significa que el módulo de capacidad LSM no se pudo registrar como módulo principal ya que SELinux es el módulo principal. El tercer mensaje indica que ha registrado SELinux como módulo secundario. Obtengo un mensaje 'Permission ... in class ... not defined' durante el arranque Durante el arranque del sistema, se muestra el siguiente mensaje:
Esto significa que el núcleo Linux que está arrancado ofrece soporte para permisos que no están definidos en la directriz (que a su vez son ofertados a través del paquete sec-policy/selinux-base-policy). Si no aparecen más errores durante las operaciones normales, entonces puede ignorarlo (los permisos formarán parte de las definiciones de directriz que se realicen en adelante). Obtengo un error de que un módulo de SELinux no está presente cuando utilizo emerge Cuando se intenta utilizar emerge, aparece el siguiente error:
Esto indica que el módulo SELinux para portage no se encuentra o está dañado. Las versiones recientes de Portage ofrecen este módulo directamente, pero los contextos de seguridad de los ficheros necesarios pueden ser erróneos para su sistema. Intente etiquetar de nuevo los ficheros de paquete portage:
Aparece el mensaje 'FEATURES variable contains unknown value(s): loadpolicy' Cuando se ejecuta emerge, aparece el siguiente error:
Esto es un remanente del conjunto de módulos de directriz SELinux antiguos en los que se necesitaba que esta CARACTERÍSTICA (FEATURE) estuviera disponible. Hace tiempo que se eliminó del árbol. Por favor, actualice su perfil a uno reciente (uno terminado en /selinux) y asegúrese de que /etc/make.conf no tiene definido FEATURES="loadpolicy". Mientras utilizo rlpkg, obtengo: 'conflicting specifications for ... and ..., using ...' Cuando se trata de etiquetar de nuevo un paquete (rlpkg nombredepaquete) o el propio sistema (rlpkg -a -r) se obtiene un error similar al siguiente:
En la mayoría de las ocasiones esto se debe a ficheros con enlaces duros (hard links). Recuerde, SELinux utiliza los atributos extendidos del sistema de ficheros para almacenar el contexto de seguridad de los ficheros. Si dos rutas distintas apuntan al mismo fichero mediante el uso de enlaces duros (esto es, los ficheros comparten el mismo inodo), entonces ambos ficheros tendrán el mismo contexto de seguridad. La solución depende de cada caso en particular. Se muestran a continuación varias formas de solucionar esto en el orden en el que más probable se obtenga un remedio:
No es mala idea informar (después de comprobar que nadie lo ha hecho ya) de esto en el bugzilla de Gentoo para que se actualicen las directrices correctamente. Cuando se instala un paquete, ld.so protesta: 'object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored' Mientras se instala un paquete, puede aparecer el siguiente mensaje de error:
Este mensaje debería ocurrir únicamente después de que aparezca el mensaje Setting SELinux security labels. Ocurre porque SELinux le indica a glibc que deshabilite LD_PRELOAD (y otras variables de entorno que se consideran dañinas) durante los cambios entre dominios. Aquí, portage invoca la orden setfiles (parte de la instalación de SELinux) cuando cambia desde portage_t a setfiles_t, lo cual limpia la variable de entorno. Creemos que en esta ocasión es más seguro confiar en la directriz de SELinux (ya que setfiles ejecuta de todas formas su propio dominio confinado) en lugar de actualizar la directriz para permitir el cambio desde portage_t a setfiles_t sin limpiar estas variables de entorno. Observe que libsandbox.so no se deshabilita durante las construcciones e instalaciones de paquetes, únicamente durante la actividad en la que Portage etiqueta los ficheros recién instalados. Por lo tanto, este error es cosmético, desde nuestro punto de vista, y se puede ignorar (desafortunadamente no se puede ocultar). Emerge no funciona, muestra el mensaje: 'Permission denied: /etc/make.conf' Esto es de esperar si no está utilizando el rol sysadm_r. Cualquier actividad relacionada con Portage requiere que esté en el rol sysadm_r. Para cambiar a ese rol, en primer lugar valide si actualmente está en staff_u (o, si añadió sus propias identidades SELinux, un usuario que tenga permiso para cambiar al rol sysadm_r). A continuación ejecute newrole -r sysadm_r para hacer el cambio.
Esto es también necesario si ha entrado en el sistema como root pero a través de SSH. El comportamiento por defecto es que SSH define el rol más bajo para un usuario en particular cuando éste se conecta. No debería permitir entrar como root desde un equipo remoto bajo ningún concepto. Cron no puede cargar el crontab de root: '(root) ENTRYPOINT FAILED (crontabs/root)' Cuando obtenga el error mencionado con una crontab de root o una crontab de un usuario administrativo, pero no con una crontab de un usuario normal, entonces deberá comprobar el contexto del fichero crontab:
A continuación, comprueba que el contexto por defecto es para el usuario correcto (en este caso, root) cuando se origina desde el dominio crond_t:
Como puede ver, el contexto por defecto es siempre para el usuario de SELinux root. Sin embargo, el contexto del fichero /var/spool/cron/crontabs/root en el ejemplo de arriba es para el usuario SELinux staff_u. Por lo tanto, cron no podrá leer este fichero (el tipo user_cron_spool_t es un tipo UBAC con limitación). Para corregir esto, cambie el usuario del fichero a root:
Otra forma de corregirlo sería deshabilitar UBAC completamente. Esto se puede hacer con USE="-ubac". Cuando consulto la directriz, obtengo: 'ERROR: could not find datum for type ...' Cuando se utiliza seinfo o sesearch para consultar la directriz en el sistema, se obtienen errores similares a:
Esto, en la mayoría de las ocasiones, sucede porque sus herramientas están utilizando una directriz de un nuevo binario para forzar la directriz, sin embargo, otro binario para realizar la consulta. Puede verificar si este es el caso, listando la última fecha de modificación de los ficheros:
El último fichero modificado debería ser el mismo que el devuelto por /selinux/policyvers:
Si éste no es el caso (que seguramente es la razón principal por la que está leyendo estas preguntas frecuentes) entonces intente forzar la versión de la directriz de utilidades a la versión correcta:
Portage no puede etiquetar los ficheros porque "setfiles" ha dejado de funcionar Portage utiliza la orden setfiles para definir la etiquetas de los ficheros que instala. Sin embargo, esta orden es un ejecutable enlazado dinámicamente, por lo que cualquier actualización, depende de la librerías enlazadas (libselinux.so, libsepol.so, libaudit.so y por supuesto libc.so), las cuales podrían causar que la aplicación fallara. La solución estándar de Gentoo (revdep-rebuild) no funcionará ya que la herramienta intentará reconstruir policycoreutils, que no podrá instalarse porque Portage no puede definir las etiquetas de los ficheros. La solución es reconstruir policycoreutils deshabilitando el soporte selinux de Portage y etiquetar manualmente los ficheros instalados usando chcon, basado en los datos que ofrece matchpathcon.
Ahora, Portage funcionará correctamente, etiquetando los ficheros de la forma correcta. Las aplicaciones no cambian en una partición montada con nosuid Si tiene sistemas de ficheros montados con la opción nosuid, entonces las aplicaciones iniciadas desde estos sistemas de ficheros no cambiarán al dominio apropiado. Esto se ha hecho de forma intencionada. Por tanto, un binario passwd, aunque esté etiquetado de forma correcta con passwd_exec_t, no cambiará al dominio passwd_t si ese binario está almacenado en un sistema de ficheros montado con nosuid. ¿Por qué necesito autenticarme de nuevo cada vez que opero con guiones de inicio? Cuando, como administrador, desee lanzar o parar demonios, necesitará hacerlo como system_u:system_r. Cambiar a este contexto es una operación altamente privilegiada (ya que está abandonando efectivamente el contexto de usuario y entrando en el contexto del sistema) y por lo tanto la configuración por defecto requiere que el usuario tenga que autenticarse de nuevo. Puede cambiar este comportamiento si está utilizando PAM, editando /etc/pam.d/run_init y añadiendo la siguiente línea al principio:
Con esta configuración, puede ahora realizar sus actividades con los guiones de inicio mediante run_init y éste no le pedirá que se autentique una y otra vez:
¿Cómo utilizo SELinux con initramfs? Actualmente no soportamos el arranque en modo forzado con una imagen initramfs (pero estamos trabajando en ello). A fecha de hoy, arranque en modo permisivo. Una vez el sistema haya arrancado, cambie a modo forzado (setenforce 1). Si corre SELinux en un sistema en producción y no quisiera que los atacantes puedan cambiar a modo permisivo (incluso si tuvieran los privilegios necesarios), ajuste el booleano secure_mode_policyload. Cuando lo habilite, el modo forzado ya no podrá ser desactivado (hasta que reinicie).
Los accesos a través de xdm (o similar) fallan Si accede a través de xdm, gdm, kdm, slim o cualquier otro gestor de acceso gráfico, puede que note que en modo permisivo su contexto no está activado, y en modo forzado simplemente no puede acceder. La razón es que se necesita configurar PAM para incluir la presencia de SELinux en la gestión de su sesión:
Replique las llamadas hacia pam_selinux.so en los ficheros /etc/pam.d/gdm* (o similares dependiendo de su gestor de acceso gráfico). ¿Qué es SELinuxfs y dónde debería estar? selinuxfs es, como sugiere su nombre, el sistema de ficheros de SELinux. Se trata de un pseudo-sistema de ficheros, lo que significa que se representa a través de ficheros y directorios, sin embargo, esos ficheros y directorios no están en su disco, sino que son generados por el núcleo Linux cada vez que se accede a los mismos. El sistema de ficheros es usado por las utilidades de SELinux como una interfaz para consultar el estado de SELinux, el cual es mantenido por el núcleo Linux. Historicamente (antes de libselinux-2.1.9), el punto de montaje del sistema de ficheros de SELinux debía ser /selinux. A partir de libselinux-2.1.9, la localización por defecto en la que se busca el sistema de ficheros es /sys/fs/selinux, aunque la librería todavía recurre a la localización original /selinux si no puede encontrarlo en el nuevo lugar. Sin embargo, la localización /sys/fs/selinux actualmente tiene un problema para aquellos sistemas que no utilizan initramfs, esto significa que /sys no se ha montado cuando init intenta montar /sys/fs/selinux. Estamos trabajando en la forma de resolver esta cuestión, por lo que de momento, mantendremos /selinux activo. |
|