| gloob | bien, pienso que es momento de empezar esta charla de la tarde |
|---|
| gloob | si tenéis cuestiones podeis hacerlo en #qc |
|---|
| gloob | pienso que habrá una traducción simultanea en #redes (efectivamente) |
|---|
| gloob | para aquellas personas que hablan español |
|---|
| gloob | esta tarde, mi colega y amigo, james morris estuvimos hablando sobre el interesante pero complicado tema de las redes SELinux |
|---|
| gloob | hay muchos aspectos involucrados en esto, por tanto intentaré no confundir con aspectos equivocados en mi introducción |
|---|
| gloob | James Morris ha sido un desarrollador del kernel durante mucho tiempo |
|---|
| gloob | es miembro también del grupo de desarrollo del nucleo de netfilter |
|---|
| gloob | y está contratado, ahora, por red hat para el desarrollo de SElinux |
|---|
| gloob | espero que en esta charla toquemos los dos temas en los que James ha estado involucrado |
|---|
| gloob | Ahora, me reclino para escuchar la charla... |
|---|
| gloob | Hola a todos |
|---|
| gloob | esta introducción será sobre redes bajo SELinux, pero primero voy a ofrecer una pequeña introducción sobre SELinux |
|---|
| gloob | SELinux es un sistema de seguridad desarrollado por la agencia nacional de seguridad estadounidense |
|---|
| gloob | provee un sistema linux con MAC security |
|---|
| gloob | la mayor parte de las decisiones de seguridad son echas de manera transparente al usuario |
|---|
| gloob | por ejemplo |
|---|
| gloob | si un usuario quiere compartir un fichero, lo único que debe de hacer es un chmod 664 al fichero para que se pueda leer por los demás usuarios |
|---|
| gloob | bajo un sistema de seguridad MAC, el kernel es el que realmente decide que fichero se puede o no compartir, en vez del usuario |
|---|
| gloob | una política de seguridad será usada |
|---|
| gloob | para especificar las reglas de seguridad del sistema |
|---|
| gloob | SELinux usa un modelo generalizado de seguridad, donde los objetos del kernel (ej, procesos, ficheros) están cada uno identificados y etiquetados en un contexto de seguridad |
|---|
| gloob | Un contexto de seguridad puede contener un numero de atributos de seguridad para el objeto |
|---|
| gloob | ej.- el rol es un atributo, y puede ser sysadmin |
|---|
| gloob | cuando una decisión de seguridad debe ser tomada, SELinux comprueba el contexto de seguridad de cada objeto y despues se hace una consulta a la política se seguridad para determinar los recursos disponibles |
|---|
| gloob | Por ejemplo, un proceso etiquetado con el rol sysadmin se le puede permitir el acceso en /etc/shadow |
|---|
| gloob | Afortunadamente, esto introduce dos ideas en SELinux: Control de acceso obligatorio (MAC) y contextos de seguridad |
|---|
| gloob | esta es una visión simplificada |
|---|
| gloob | Más información sobre SELinux disponible en |
|---|
| gloob | http://www.nsa.gov/selinux/docs.html |
|---|
| gloob | http://sourceforge.net/docman/display_doc.php?docid=15285&group_id=21266 |
|---|
| gloob | por Faye Coyer |
|---|
| gloob | Coker |
|---|
| gloob | SELinux extiende seguridad MAC al coontexto de redes |
|---|
| gloob | Esto es importante y práctico ya que hoy en día un grán número de sistemas están conectados |
|---|
| gloob | por RED |
|---|
| gloob | SELinux permite a sistemas conectados en red ser endurecidos contra la mayor parte de las vulnerabilidades y errores de usuario |
|---|
| gloob | primeramente, todas las socket system call son controladas por SELinux |
|---|
| gloob | ej.- un proceso debe tener permisos para usar socket(), bind(), listen(), accept(), sendmsg(), rcvmsg(), etc.. |
|---|
| gloob | Esto efectivamente permite a SELinux controlar que aplicaciones pueden hacer uso de recursoso de red |
|---|
| gloob | Si no puedes usar las socket system call, tendrás problemas intentado hacer cualquier aplicación que haga uso de recursos de red |
|---|
| jsolares | Algunos de estos permisos estan aun mas atomicos, por protocolo: TCP, UDP y Raw IP |
|---|
| jsolares | asi que por ejemplo, SElinux es capaz de imponer una politica donde cierta aplicacion, como apache, solo puede realizar llamadas a sockets en TCP. |
|---|
| jsolares | Si apache fuera comprometido, el kernel no dejaria que Apache trabajase con sockets en UDP |
|---|
| jsolares | Aun mas permisos son proveidos para bind(), donde el numero de puerto es especificado (por ejemplo solo escuchar en puerto 80), asi como cuales direcciones de IP local puedan ser usadas. |
|---|
| jsolares | (notemos que ningun cambio se debe de realizar en la aplicacion para llevar a cabo esto, todo esta controlado con politicas de seguridad hechas cumplir a nivel del kernel/nucleo) |
|---|
| jsolares | Tambien se proveen permisos para que con las politicas especifiquemos que trafico de que interfaz de red puedan ser recibido o enviado. |
|---|
| jsolares | esto tambien es aplicado a nivel de protocolo. |
|---|
| jsolares | por ejemplo, se podria escribir una politica que dice que Apache solo puede enviar y recibir trafico de TCP en la interfaz eth1. |
|---|
| gloob | El tráfico de RED puede ser controlado también por direcciones IP para un proceso o protocolo. Combinando estos controles proveen un potente y flexible vía para contener aplicaciones que aceptan concexiones de red. |
|---|
| jsolares | Poniendolo todo junto, un ejemplo simple seria especificar que sshd tiene permitido hacer llamadas de socket para TCP, utilizar el puerto 22, enviar y recibir trafico de TCP sobre una interfaz interna solo a direcciones de intranet. |
|---|
| jsolares | Aplicaciones como ssh, sshd, bind, etc. pueden ser limitadas de igual forma. |
|---|
| jsolares | Una pregunta que se estaran haciendo es, como es esto difirente a iptables? |
|---|
| gloob | Primeramente, el tráfico de red está asociado con un proceso específico (esto se puede hacer de forma limitada con iptables y está sólo presenta en la capa de red) |
|---|
| gloob | [jamesm] Los controles de SELinux son parte de un esquema más general donde las apliciones son reducidas a lo que pueden hacer, por ejemplo hacer uso del sistema de ficheros |
|---|
| gloob | pregunta Nurb: puede un filtro basado en roles de SELinux funcionar con netfilter/iptables (añadido a las propias políticas de SELinux) |
|---|
| gloob | Si, puedes escribir una regla de iptables para el contexto de seguridad, pero sólo funcionará para los paquetes de salida generados localmente |
|---|
| gloob | para los paquetes entrante4s |
|---|
| gloob | , iptables se cuelga de de la capa de red y no puede saber como el paquete está eventualmente asociado con el espacio de usuario (en el caso de que exista) |
|---|
| jsolares | pregunta riel: hay planes para transferir el contexto de seguridad atravez de la red (con ipsec), para que tambien se puedan filtrar los paquetes basandose en el contexto de seguridad tambien? |
|---|
| jsolares | si, miraremos eso dentro de poco |
|---|
| jsolares | Lo que tenemos con SELinux en red actualmente, es una forma de hacer nuestros sistemas mas dificil de ser atacados (de manera interna y externa), en contra de errorers de configuracion, integrados con un sistema de MAC. |
|---|
| gloob | Muchas (si no todas) de esas vulnerabilidades vistas recientemente han sido contenidas por SELinux, aunque SELinux no puede proteger de los fallos (bugs) del propio kernel (ej.- el fallo con do_brk()) o una mala política de seguridad |
|---|
| gloob | Por tanto no es una bala mágica |
|---|
| gloob | SElinux está aún en desarrollo (trabajando en habilidades que puedan ser continuadas cuando después de que el kernel 2.6.0 sea lanzado) |
|---|
| gloob | aahlih pregunta: ¿ Cuál es el consumo de todas las comprobaciones de SELinux ? |
|---|
| gloob | Por mis propias medidas, entre un 5%-15% dependiendo de lo que estés probando. Cuantas más habilidades sean implementadas, la red irá más lenta, pero de todas formas el mayor trabajo en rendimiento y escalabilidad se harán en los próximos 6 meses. |
|---|
| gloob | Por ejemplo, parece haber una cerradura que se lleva la mitad del consumo, esto es algo que puede ser parcheado |
|---|
| gloob | pero siempre habrá algo de consumo por parte de SELinux |
|---|
| jsolares | pregunta Hanna: Que lock es ese? |
|---|
| jsolares | es el avc_lock en avc_has_perm(), el cual es llamado en todo chequeo de permisos de acceso |
|---|
| jsolares | este parece como un cadidato para RCU (read copy update / leer copiar actualizar) |
|---|
| jsolares | pregunta feistel: diferencias entre systrace de openbsd y selinux? |
|---|
| gloob | yo no estoy muy familiarizado con systrace, aunque parece que proporciona |
|---|
| gloob | un control sobre como utilizan las syscall |
|---|
| gloob | SELinuux puede controlar el uso de syscall, como parte de una politica |
|---|
| gloob | integrada de seguridad |
|---|
| gloob | algunas caracteristicas de red planeadas por SELinux incluyen |
|---|
| gloob | - add control para enviar/recibir trafico por un puerto ( yo estoy trabajando |
|---|
| gloob | en eso hoy) |
|---|
| jsolares | - mejorar los sockets locales de Unix para que las aplicaciones se puedan autenticar utilizando credenciales de SELinux. (esto esta implementado y bajo revision de otros desarrolladores) |
|---|
| ducky | - El mejoramiento del socket UNIX |
|---|
| ducky | sera util para integrar al X, y a los procesos |
|---|
| ducky | locales IPC |
|---|
| ducky | tal como el DBUS |
|---|
| ducky | pero eso son topicos |
|---|
| ducky | ya mas profundos |
|---|
| ducky | - Hacer los controles de red, mas expresivos |
|---|
| ducky | (son poderosos) |
|---|
| ducky | pero no de tan facil uso como iptables |
|---|
| ducky | - Modelo de red etiquetado (esto extiende el modelo de seguridad a traves de la red) |
|---|
| ducky | - Mejor soporte para NFS |
|---|
| ducky | - Integracion con IPSEC (ej , la politica de seguridad puede espeficar requerimientos de proteccion para el trafico de la red) |
|---|
| ducky | riel , pregunto antes acerca de la seguridad del transporte |
|---|
| ducky | a traves de la red |
|---|
| ducky | - Esto se llama Modelo de red |
|---|
| ducky | etiquetado |
|---|
| ducky | tipicamente, cada paquete tiene una etiqueta (dentro del contexto de SELinux) |
|---|
| ducky | contexto de seguridad |
|---|
| ducky | o multiples etiquetas (ej ,cada una de ellas indicando el contexto de seguridad del proceso que envia, uno indicando el contexto del mensaje y otro que indoque) |
|---|
| ducky | que indique el contexto de seguridad del destino |
|---|
| ducky | - Esto se implemento usando opciones IP, en una version previa de SELinux |
|---|
| ducky | sin embargo, esto ya ha sido deshechado tal como los hooks |
|---|
| horacio | Una version mas actual se ha implementado antes de SELinux, usando la arquitectura predecesora Flask |
|---|
| horacio | Pero en lugar de etiquetar cada paquete, se etiquetan las conexiones IPSec |
|---|
| horacio | entonces, cada paquete fluyendo en una conexion IPSec dada (mas tecnicamente, cada asociacion de seguridad) tiene una etiqueta implicita |
|---|
| horacio | El etiquetado de seguridad fue negociado via una extension a ISAKMP (el protocolo de manejo de llave/key). |
|---|
| horacio | Futuros etiquetados de paquetes pueden revertirse al metodo basado en IPSec. |
|---|
| horacio | El Metodo de Etiquetado de Red puede ser util probablemente solo en ambientes muy seguros donde los sistemas estan bajo estrictos controles de administracion (ej: telcos) |
|---|
| gloob | pregunta sysbd: ¿ Porqué las cerraduras LSM no son incluidas en la línea principal de desarrollo del kernel (o han sido silenciosamente rechazados) Tiene el método IPSEC muchas desventajas ? |
|---|
| gloob | Las cerraduras LSM para el modelo de red etiquetado han sido rechazadas por el mantenedor ya que se introducen demasiado. Han sido puestas básicamente dentro de los protocolos de red, hemos tenido que implementar básicamente casi todo usando otros medios (Por ejemplo, via Netfilter), así que la decisión para ruidosa. |
|---|
| gloob | El método IPSec tiene dos desventajas (desde mi punto de vista) |
|---|
| gloob | 1) Hace que IPSec sea más complicado, lo que es malo para la seguridad. |
|---|
| gloob | 2) Combina el etiquetado con la protección dentro del mismo mecanismo. |
|---|
| gloob | Esto siginifica que si tu quieres etiquetado, debes de tener IPSec, pienso que esto es probablemente lo que la mayoría de la gente quiere (pero algunos entornos deben tener métodos de encriptación en el cable, por ejemplo) |
|---|
| gloob | Aparte de todo eso, después de ver los dos esquemas, el sistema IPSec tiene algunas interesantes simplicidades de tal forma que sólo tengas que mirar en el SA (Security Association) al cual el paquete pertenece, en vez de identificar las opciones IP. |
|---|
| gloob | Y las opciones IP, probablemente, no funcionen en la internet real ya que la mayoría de los firewall/router lo bloquearán. |
|---|
| gloob | pregunta cdub: en paquetes de entrada (digamos tcp accept) es posible que más de un proceso (o ninguno) esté esperando para sincronizar. Ya que el proceasamiento ocurre en contexto de interrupciones, ¿ Has tenido problemas tomando el contexto correcto a identificar ? |
|---|
| jsolares | si, hay algunos casos que necesitamos revisar, debido a que no hay ganchos en el codigo de TCP |
|---|
| jsolares | esto talvez podria ser resuelto haciendo un lookup (operacion de busqueda), pero necesita mas investigacion |
|---|
| jsolares | bueno, he terminado con el material que planee para la presentacion, hay mas preguntas? |
|---|
| jsolares | pregunta cdub: he tenido problemas con procesos que pueden cambiar de contexto de seguridad, y accesando informacion que no deberian de tener acceso a |
|---|
| jsolares | en SELinux o solo con LSM? |
|---|
| jsolares | para SELinux, se puede cambiar el contexto de seguridad en ejecucion, asi que talvez estas heredando el socket? |
|---|
| jsolares | pregunta riel: como van ipsec & selinux beneficiar administradores de sistemas normales, quienes no pueden poner reglas complejas de seguridad ellos mismos? |
|---|
| jsolares | buena pregunta |
|---|
| jsolares | primeo que nada, para ipsec, deberia de ser posible simplificar la configuracion para usos comunes, por ejemplo VPN's |
|---|
| jsolares | creo que es manejable, ya que IPSec es bastante usado hoy en dia |
|---|
| jsolares | para SELinux, sera mas dificil creo |
|---|
| jsolares | esperemos que las distribuciones provean buenas politicas para las aplicaciones, para que no sean cambiadas regularmente |
|---|
| jsolares | y actualizaciones a las politicas como agregar usuarios, etc. seran implementadas en aplicaciones faciles para el usuario |
|---|
| jsolares | pero creo que esta es la gran incognita para SELinux, y un gran desafio para Red Hat, Debian, Gentoo etc. |
|---|
| jsolares | alguna otra pregunta? |
|---|
| jsolares | pregunta nurbs: que quieres decir por mejor soporte para NFS? |
|---|
| jsolares | esto podria ser simplemente manteniendo el contexto de seguridad de los archivos sobre NFS, o mas complicado, que el server de NFS imponga las politicas de seguridad en el sistema de archivos remoto como si fuera local |
|---|
| jsolares | esto necesita ser implementado usando extensiones para NFSv2/3 |
|---|
| jsolares | NFSv4 tiene una vision mas grande respecto a esto ( se necesitan que los atributos extendidos sean enviados por el canal: asi es como el contexto de seguridad de SELinux esta implementado para archivos) |
|---|
| jsolares | pero igual se necesita hacer trabajo en NFS y SELinux para que esto funcione bien |
|---|
| jsolares | El soporte actual para NFS es minimo: un sistema de archivos montado via nfs aparece con todos los archivos y directorios teniendo el mismo contexto de seguridad, y ningun contexto de seguridad es alamacenado remotamente |
|---|
| jsolares | ok, parece que terminamos :-) |
|---|
| jsolares | <riel> Gracias James! |
|---|
