LSM talk

viZard
La charla para ahora, esta titulada "El proyecto de Seguridad en Linux por modulos"
viZard
dirigido por Seth Arnold and Chris Wright (WireX Communications, Inc)
viZard
ok es hora de comenzar.
dardhal
Buenas noches
viZard
buenas
viZard
al rato nos ayudas a traducir =)
dardhal
a ver si puedo :)
viZard
los ponentes son sarnold y cdub en el canal #linux
viZard
en un momento comenzamos
viZard
Ahora sí, comenzamos.
viZard
La lectura de esta tarde, luego de la de David Santo
viZard
sera acerca de la infraestrucutura mas flexible y segura en Linux
viZard
mas flexibilidad en algo bueno, por varias razones
viZard
por un lado, los sistemas de grandes servidorees tradicionales de usuario - grupo
viZard
son un problema al manejar la seguridad
viZard
la lectura de hoy, sera dada por Chris Wright and Seth Arnold from WireX Communications
viZard
ellos estan desarrollando el proyecto de modulos de serguridad para Linux
viZard
asi, que les cedo la palabra a ambos.
viZard
Gracias riel, por la introduccion
viZard
Y gracias a uninet por permitirnos participar en este foro
viZard
Primero comenzaremos con algo de historia
viZard
Comenzando con el linux 2.5 kernel summit.
viZard
La Agencia de Seguridad Nacional (USA) hizo una presentacion de su distribucion SELinux y la construccion sobre seguridad en su kernel
viZard
para hacer la historia corta
viZard
Linus y otros acordaron que Linux necesita seguridad avanzada
viZard
Sin embargo, Linus queria algo  flexible
viZard
no quiso aceptar un proyecto de seguridad que desviara el dasarrollo del kernel en otra direccion
viZard
basicamente esto es el proyecto LSM
viZard
Comenzamos definiendo el ambiente abstracto para permitir una variedad de politicas de seguridad para ser implementadas en el kernel
viZard
sin tener que estar parcheando para cada proyecto
viZard
La primera pregunta importante que enfrentamos fue 
viZard
como interponer nuestro ambiente de trabajo
viZard
Hay muchas personas a favor de un sistema de trabajo estricto de llamado de sistema
viZard
eventualmente elegimos el sistema de llamado estricto por interposicion
viZard
solitario
viZard
el cual fue tan bueno como para que Linus nos aconsejara en contra de ello
viZard
Por el contrario escogimos ver cada objeto del kernel que fuese accesible al espacio del usuario como algo que necesita proteccion
viZard
el estado-de-arte en el presente kernel, permite modos de pruebas basicos en bits (pruebas de superusuario)
viZard
asi que comenzamos tratando de crear un ambiente que permitiria el soporte del actual sistema de control de acceso
viZard
en el kernel
viZard
el problema con el sistema de llamado es que esta muy lejos de donde la "accion" toma lugar
viZard
Hay datos de usuario que necesita ser copiado al kernel
viZard
y hay objetos del kernel que necesitan ser buscados
viZard
etc
viZard
Asi que concentrandonos en los mismos objetos del kernel
viZard
como inodos, archivos, task_struct, etc
viZard
sentimos que podemos obtener mejor covertura de control de acceso
dardhal
fijándonos en la situación de los actuales controles check() u super()vimmos que nuestra aproximación no estaba tan alejada de dónde está ahora mismo el kernel
dardhal
de maner a que comenzamos a crear una estructura de callbasck que representan a todos los objetos
dardhal
y todas las accciones quye pueden hacer los usuarios para manipular dichos objetos
dardhal
el propio código del LSM que está en el kernel es un conjunto de ocntroles que protegen el acceso a los objetos del núcleo
dardhal
estos ganchos ejecutan las callbacks, que llaman al código específico del módulo
dardhal
una idea crítica es separar la -política- del -mecanismo-
dardhal
queremos que nuestro marco de seguridad sea lo más independiente de la política de seguridd posible
dardhal
y forzar todas las decisiones de política de seguridad hacia el módulo de seguridad
dardhal
las políticas actuales de seguridad en el núcleo son básicamente DAC (Control de Acceso Discreccional)
dardhal
Pero hay otros grupos muuy importantes de polñiticas de seguridad
dardhal
tales como MAC, DTE, etc....
dardhal
una característica importante de la que carece MAC es el etiquetado de de objetos específics
dardhal
¿ como la infrestructura de netfilter ?. Sí, hasta donde yo sé
dardhal
parte del marco de seguridad soporta el etiquetado de objetos
dardhal
algo que cariñosamente llamamos "burbuja de seguridad opaca"
dardhal
además de proporcionar ganchos (hooks) para el control de acceso
dardhal
proporcionamos los ganchos necesarios de asignación/desasignación de ganchos para dichos "burbujas de seguridad opacas9 (léase void* )
dardhal
entomces la infraestructura puede usar dichas etiquetas para decidir si se permite o no el acceso
dardhal
esta es la vista de nivel general de lo que es LSM
dardhal
¿ preguntas ?
dardhal
¿ como los Large Binary Object ?
dardhal
son simples void*,  el módulo de seguridad puede poner lo que desee ahí
dardhal
¿ qué otros usos se preveen ,es decir, qué módulos ya están, control de recuross, (como los userbeans( ?
dardhal
continua sarnold
dardhal
no sé lo que son los userbeans, aunque los ganchos están situados en lugares estratégicos, y supongo que tendrán un amplio avbanico de usos
dardhal
una cosa que me viene a la cabez son los portable filesystem de BSD
dardhal
una cosa que hemos tratado de evitar es ligarnos a un esquema concreto de ganchos, de manera qye los ganchos son realment egeneéricos
dardhal
Los userbeans son cuotas de usuario pero para recursos del sistema, qur Andrey Savochkin did it and Marcelo Tosatti trabajaron en el pasado
dardhal
Guau,, muy interesante
dardhal
Suena como algo que podría implementarse gracias a LSM
dardhal
Puesto que LSM dispone de ganchos para la creación de objetos
dardhal
Porque un sistema de segurida trambién podría preociparse de gestionar los recursosl
dardhal
¿ tales como  inode->u.generic_ip, netdevice->private, struct sock->protinfo.destruct_hook (estoy sobrecargando la cosa :) ?
dardhal
sí, tenemos inode->security y tal, y llevan asociadas etiquetas especificas del módulo
dardhal
¿ será posible usar múlktiples módulos de seguridad al mismo tiempo ?
dardhal
Esperad, que eso lo voy a contar a continuación
dardhal
ahora que hemos visto el nivel general del marco de seguridad
dardhal
hablemos de los detalles
dardhal
las coallbacks están todas en una estructura, security_operations
ToniSB
dardhal ya sigo sigo si kieres ;)
dardhal
cuando se iniciar el módulo
dardhal
tantoen tiempo de arranque o al argar ek módulo
dardhal
necesita inicaiar la estructura security_ops
dardhal
esto se hace mediante la interfaces estandar del tipo register_security
ToniSB
esto se hace via la interface register_security estandart...
ToniSB
y uno de nuestros primeros objetivos fue
ToniSB
como hacer posibles los modulos de seguridad de pila con esta interface...
ToniSB
(y no hay que olvidar que cadamodulo esta guardando su propia etiqueta en el objeto del kernel)
ToniSB
linus tenia una fuerte opinion sobre esto, como mucha gente en el campo de la seguridad
ToniSB
linus dice en efecto, no hay que diseñar politicas de seguridad
ToniSB
la investigacion de seguridad dice, que en general, las politicas de seguridad no se diseñan
ToniSB
decidimos tomar un punto intermedio aqui
ToniSB
una cosa importante a remarcar es que el super usuario y los chequeos de capacidades se hacen contra datos directamente en task_struc
ToniSB
asi que seria "trivial" diseñar una politica de seguridad arbitraria con el superusuario o el modulo de capacidades, ya que ellos no pisan directamentes los dedos de los otros (via el puntero oscuro)
ToniSB
el unico problema por ahora, es la interface delkernel (la estructura de llamada atras (callback))
ToniSB
asi que tenemos la notacion de un modulo primario. este es el primero que llama a register_security
ToniSB
todos los modules siguientes no se registran con el kernel, sino que lo hacen con el primario
ToniSB
esto permite al kernel ser "clueless"(sin pistas¿?¿) sobre la pila de modulos
ToniSB
y fuerza a los modulos que se estan apilando con otros a permitir explicitamente este comportamiento
ToniSB
de esta manera, pensamos que el diseño arbitrario de politicas de seguridad puede ser un problema inmanejable
ToniSB
xo el diseño de algunas politicas conocidas puede hacerse facilmente
dardhal
hemos considerado la creación de un tipo básico de composición que simplemente permita tregistrar múltiples módulos, y que básicamente && o || los resultados, pero tal módulo no existe ahora mismo. Para recapitular, se pueden apilar módulos, pero hemos intentado que el kernel no sepa de eso, luego el mecanismo de apilado no es completamente genmérico
dardhal
ente restringe el acceso a dicho objeto ? Esto tiene más sentido cuando consideras qué pinta tiene el código del kernel
dardhal
algo como las ACL podrían combinar bien con algo como vserver,. Sí pienso eso , y es algo sobre lo que hablaré en breve. El código del kernel a menudo se parece a los siguiente:
dardhal
<cdub> if (uids != match && !(capable()) goto failed;
dardhal
<cdub> do_action()
dardhal
<cdub> with LSM it looks similar:
dardhal
<cdub> if (uids != match && !(capable()) goto failed;
dardhal
<cdub> if (security_ops->do_action()) goto failed;
dardhal
<cdub> do_action();
dardhal
de manera que tenemos  un problemo, y podríamos queres sobrescribir el acceso a un objeto por parte de determinado sujeto. El gancho de seguridad sólo va a restringir el acceso concedido por la lógica del núcleo. Y hemos dicho acerca de este preciso aspecto y hemos decidido hacer un compromiso
ToniSB
tenemos un gancho en la funciona capable(), asi que esa funciona puede saltarse(este es un comportamiento de las capacidades 'estandards' POSIX.1e)
dardhal
el compromiso es que, la función capable() recibe muy poco contexto, sólo un vector de 32 bits CAP_SYS_ADMIN etc
ToniSB
el compromiso es que, la funcion capable acepta un contexto muy limitado, solo un vector de 32 bits CAP_SYS_ADMIN, etc...
ToniSB
asiq ue mientras podemos restringir el acceso a objetos en un marco muy concreto
ToniSB
(las interfaces restrictivas pueden tener muchos argumentos al callbak, inode, dentry, etc.)
ToniSB
solo podem saltarnos en control de acceso en una granularidad "corarse"(¡?¿?) (vector de 32 bits)
dardhal
elegimos este compromiso porque permite a la mayoría de los módulos de seguridad, con el mínimo de cambios en el kernel
viZard
buena sincronia =)
ToniSB
perfecto, ahora el problema vserver...
ToniSB
vserver es un proyecto para permitur multiples servidores virtuales a ejecutarse en contextos de seguridad aislados
ToniSB
podemos soportar la mayoria de las cosas que deberia hacer el vserver, con dos excepciones
ToniSB
!) vserver toca directamente el codigo temporizador, cosa que nosotros nunca intentamos hacer ;)
dardhal
2) vserver devuelve los datos al usuario en función del su contexto
ToniSB
esto es algo que podemos trabajar para mejorar el marco de trabajo del LSM
ToniSB
oh, he olvidado mencionar que el LSM se esta diseñando para ser aceptado para el 2.5
dardhal
(un ejemplo específico, vserver puede devolver diferente iunformación de uname en diferetes contextos de seguridad) (en la actualidad podemos manejar eso, pero algunas de las otras no, pero ahora no recuerdo cuáles)
ToniSB
otro problema que teniamos deberia haber sido solucionado por los cambios en el VFS anticipados en el 2.5
ToniSB
algunas politicas de seguridad intentarian hacer desiciones de control de acceso basadas en el nombre del archivo, en cambio otras basadas en el numero de inodo
ToniSB
el marco de trabajo de security_ops refleja las inode_operations
dardhal
¿ Como hace LIDS ?.  ¿ te refieres a los nombres de ficheros ?. S¡, exacto
ToniSB
asi que justo antesd de que el sistema de archivos sea llamado para hacer algo, comprobamos que es correcto
ToniSB
algunos discuten que los nombres de archivo no son suficientes, ya que estas intentando protejer realemente el inode, pero esto es una cuestion de discusion de politicas de seguridad ;)
dardhal
intentamos ser agnósticos, luego esperamos soportar proyectos tales como LIDS. Desde nuestro hooks hacemos copia de los inode_operations, y tomamos los mismos argumentos. Para aqulellos que lo hjan probadso
ToniSB
no puedes montar de manera segura una ruta desde un solo inode. realmente necesitas las dos dentry y vfsmount
dardhal
sabeafortunadamente, Al Viro planea canbiar la interface del FS, luego preveemos que esa funcionalidad esté muy pronto. ¿ preguntas ?. Nada, sin descanso para mi mano tecleadora
ToniSB
donde estamos ahora?
ToniSB
hemos implementado un completomarco de trabajo
ToniSB
y hemos implementado modulos que usan este marco, concretamente, superuser y capacidades
ToniSB
adicionalmente, desde la comunidad lsm, tenemos un modulo DTE, un modulo SELInux, y un modulo que implementa mucha parte del parche OpenWall del kernel
ToniSB
estamos inspeccionando muy de cerca el desarrollo del 2.5, y deseamos proponer lsm un tiempo despues de que los cambios al VFS se hayan realizado
ToniSB
no he mencionado mucho sobre la parte de red del LSM
ToniSB
se diseña mayoritariamente desde netfilter, y solo añade lo que falta para cubrirlo por completo
ToniSB
asi que parte de la interface del LSM son una serie de ganchos de netfiltes
dardhal
y es que no queremos reinventar la rueda
ToniSB
;)
ToniSB
ah, si, y por supuesto estamos siguiendo los atributos extendidos y el desarrollo del ACL, ya que EA permite un monton de etiquetas sin tener que usar un archivo de respaldo para una base de datos de atributos
dardhal
 usando la infrwestructura actual de netfilter para la parte de red de LSM es bueno :) ?. Sí, estoy de acuerdo. Pero haciendo esto estamos extendiendo la infraestructura de red y yendo haci algo más genérico
ToniSB
bien, esto es una manera de verlo ;) cuando vino el soporte de red del LSM fue obvio que se necesitaba acutualizar (¿?) netfilter
ToniSB
asi que imagino netfilter como una mejora de LSM ;)
dardhal
Entonces netfilter, LSM, EA, userbeans, etc....podrían ser tofdo una gran infraestructiura basada en ganchos
dardhal
Lo que queremos es centrarnois en la seguridad y en el control de acceso, auqnque LSM permita hacer más cosa
dardhal
¿ pero no hay partes de las que otros proyectos puede veneficiarse ?
dardhal
sí,m pero no pretendemos resolver todos los problemas
dardhal
pero de igual manera que hemos usado netfilter, los demás pueden usar LSM
dardhal
para satisfacer sis necesidades
dardhal
¿ le preocupa a LSM la identificación ?
dardhal
¿ de dónde obtiene las credenciales ?
dardhal
¿ o está fuera del ámbito de LSM ?
dardhal
Estro lo consiuderamos como una politica que debe ser aplicada por un módul
dardhal
El núcleo de LSM ni sabe ni se preocupa
dardhal
Los ganchos de LSM son como fork y exec
dardhal
Durante ese tiempo el módulo puede conceder credenciales  de la tarea
dardhal
Recientemente leí una entrevista donde se dice que el HURD puede ejecutar uin proceso sin un contexro asociado , por ejemplo sin derecjhos
dardhal
Esto permite a un servidor de FTP funcionar sin derechos, justo lo contrario que funcionar como root en UNIX
dardhal
hasta que un usuario entra en el servidor
dardhal
¿ se puede conseguir algo similar con LSM?
dardhal
sí, y de hecho el uso astuto de las capabilities permitirán este tipo  de cosas
dardhal
¿ qué modiles están ya disponibles ?
dardhal
<cdub> DTE, SELinux, Openwall, capability, superuser son los módulos ya disponibles
dardhal
el módulo root=god module, POSIX1.e capabilities un módulo de enforcement de dominoi y tipos, el SElinux, el solar designers, et.c...
dardhal
SElinux es una infraestructura que permite muchas politicas 
E-D-W-I-N
SELinux es sí mismo en la infraestructura que permite las políticas múltiples (MAC, los etc.) tan hay absolutamente un dígito binario disponibles ahora
dardhal
La egnt4 de LIDS dice que quiere portat LSM cuando este se estabilice
dardhal
Y yo tengo un ódulod e vserver parcialmente funcional
dardhal
No pretendemos que se acepten en 2.5. todos los módulos de LSM
dardhal
Sólo queremos que entren el núcleo de LSM así como algunos módulos
dardhal
Mientras tanto habrá un repositorio de todos los módulos para poder ser descargados y como servicio a la comiunidad
dardhal
van Riel preguntaba sobre cómo combinar ACLs y vserver
dardhal
y estew es quizás un ejemplo de cómo los módulos genéricos pueden no combinar bien
dardhal
por ejemlpo, las ACL podrinan implementarse completamente dentro del propio contexto de vsercer
dardhal
proporcionando control de acceso obligatorio adiciional
dardhal
gracias a vserver
dardhal
perio las ACL tambien se pueden implementar fuera de vserver, para propotcionmar una mayor granularidad
dardhal
entre los servidores de vserver
dardhal
diferentes políticas de seguridad perfectamente válidas vienen de enfoiques diferentes para componerlas en dos módulos
dardhal
¿ más preguntas ?
dardhal
NT: espero que no ;)
dardhal
algunos detalles del proyecto.-.
dardhal
pueden encontrar los parches en lsm.immunix.org
dardhal
vayam esto parece ahora bastanmte tranquilo
dardhal
disponemos de una lista de corre, 
dardhal
para aquellos que se preguntan por LTT; http://www.opersys.com/LTT/
dardhal
<cdub> http://mail.wirex.com/mailman/listinfo/linux-security-module <<--- lista de correo
dardhal
Y nos reunimos habitualamente en irc.openprojects.net #lsm-dev
dardhal
¿ está dentro del ambito de LSM el lucahr contra los covert channels (canales encubiertos) ?
dardhal
Buena pregunta....no completamrnte, puesto que es una batalla perdida
dardhal
sí,como tiempos de busqueda de I/O, etc.
dardhal
no disponemos de la posibilidad de cerrar todos los canales encubiertos
dardhal
Pero hay varios hooks de LSM que permiten cerrar muchos de estos canales
dardhal
Es una respuesta un poco vaga, pero los canales encubiertos son difíciles
dardhal
gracias a los ponentes (cdub y sarnold) por esta conferencia
dardhal
En 30 minutos comenzará otra conferencia (afortunadamente en castellano. NT)
dardhal
Bueno, creo que eso es todo por mi parte (dardhal)
dardhal
Espero que hayáis entendido algo de lo que he traducido, que hoy andaba espeso :(