| alberto | un miembro del SELinux team, Pete Loscoco, presento SELinux a la cumbre del kernel para su inclusion en el mismo |
|---|
| alberto | <raul> mas tarde, miembros de varios proyectos de seguridad empezaron a colaborar y diseñar un framework para soportar varios de los proyectos de seguiridad existentes |
|---|
| alberto | pequeño parentesis: si hay alguna duda a: #qc ( lo siento) |
|---|
| alberto | 1. el framework deberia de ser lo sufciientemente generico para que pueda soportar varios modelos de seguridad |
|---|
| alberto | 2. debe de ser ligero y no imponer complejidades excesivas |
|---|
| alberto | 3. debe de soportar solo modelos de control de acceso (cosas como auditorias completas, a menudo necesarias para una acerditacion, no serian soportadas) |
|---|
| alberto | 4. Necesita soportar capacidades preexistentes |
|---|
| alberto | otro aspecto de la certificacion es a menudo la abilidad de auditar en tiempo real las transaccciones de un sistema |
|---|
| alberto | a menudo cosas como el Common Criteria o certificaciones Orange Book requieren un especial nombramiento |
|---|
| alberto | una es muy obvia, el control de acceso |
|---|
| alberto | otro aspecto es revisar las transacciones en tiempo real en un sistema |
|---|
| alberto | entonces, es necesario hacer logs sobre los accesos |
|---|
| alberto | esta auditoria/logging esta mas alla del los objetivos actuales de del proyecto LSM |
|---|
| alberto | el registro es muy simple, el modulo simplemente responde a las llamadas requeridas, y llama a register_security() |
|---|
| alberto | asique permitidme comenzar a explicar algunos de los aspectos del diseño de LSM |
|---|
| alberto | pero primero, una pregunta |
|---|
| alberto | hay una lista de objetos para los cuales los modulos de seguridad puedan ser escritos ? |
|---|
| alberto | puede LSM soportar la funcionalidad mencionada por la gente de OpenBSD que conocemos como Separacion de privilegios? |
|---|
| alberto | Es eso una lista de objetos para los que pueden escribirse modulos de seguridad? |
|---|
| alberto | Eso es lo q estaba pensando ;) |
|---|
| alberto | si |
|---|
| alberto | ;-) |
|---|
| alberto | esta bien, asique aqui estan algunas de las cualidades basicas del marco de LSM |
|---|
| alberto | 1. Provee la abilidad de registrar un nuevo modulo de seguridad |
|---|
| alberto | permiteme echarle un rapido vistazo a la lista de objetos q estan protejidos, entonces mira a la respesta del syscall. |
|---|
| alberto | 3. Trata de romper el kernel en sus objetos "core", y fundamentalmente proteje contra accessos a los datos del objeto |
|---|
| alberto | por eso, no es muy comun ver un LSM hook que parezca sospechosamente similar al punto de entrada del syscall |
|---|
| alberto | el registro es muy simple, el modulo simplemente rellena los callbacks que se necesitan y llama a la función register_security() |
|---|
| alberto | de echo, la api interna de sockets es basicamente solo la api del syscall para socket... |
|---|
| alberto | < rene:#qc> cdub: puedes mostrarme un ejemplo de una carrera aqui? |
|---|
| alberto | foo es copiado dentro dle kernel, y encerrado. Si la interface LSM fuera antes de la traduccion, esto podria colgar foo, ganando acceso. |
|---|
| alberto | entonces otro thread puede modificar foo. y el kernel podria entonces ver "nuevofoo", sabiendo q paso el LSM, guardandolo .... |
|---|
| alberto | blam... |
|---|
| alberto | bien, solo una recapitulacion, ya que hay cuestiones espacidas... |
|---|
| * slack is away: I'm busy |
| alberto | el framework del LSM es un simple api enlazado. Provee de registro y rellamadas a dentro del kernel |
|---|
| alberto | < rene:#qc> cdub: otra capa del kernel? de lo contrario no entiendo |
|---|
| alberto | no, espacio de usuario. |
|---|
| alberto | < nab:#qc> es posible usar muchos modulos de seguridad al mismo tiempo, y si ocurre, que limitaciones hay |
|---|
| alberto | nab: esa es otra pregunt interesante |
|---|
| alberto | permiteme posponerlo antes de responder |
|---|
| alberto | una de las cosas que la interface LSM permiete es la abilidad de etiquetar los objetos del kernel con identificadores de seguridad |
|---|
| alberto | este es el principio de la abilidad para decir si una accion es segura. |
|---|
| alberto | el modulo LSM podra compara el id de la tarea de seguridad con el ide de seguridad del inode, por ejemplo. |
|---|
| alberto | porque la clasifiaccion y etiquetado de seguridad es dificil para varios modulos de seguridad el compartir el espacio del LSM a la misma vez. |
|---|
| alberto | (sin añadir algunas inteligentes capacidades a la interface que sabe que modulo esta siendo llamado el objeto). |
|---|
| alberto | linus no queria especificamente eso |
|---|
| alberto | linus no queria esto especialmente. |
|---|
| alberto | y de hecho, la investigacion en seguridad demuestra que los modelos arbitrarios de seguridad componen? y producen resultados aleatorios |
|---|
| alberto | no es satisfactorio para la seguridad |
|---|
| alberto | asique....LSM provee la capacidad de apilar modulos, pero requiere un modulo para gestionar el apilado. Basicamente alghien se encarga de decidir como componer los resultados en las varias decisiones de segur |
|---|
| alberto | semejante modulo ha sido escrito, aunque no es parte de LS |
|---|
| alberto | este es eun area donde el desarrollo futuro cambiara el comportamiento actual |
|---|
| alberto | pero por ahora, seguimos, KISS |
|---|
| alberto | < zanshin:#qc> son los enlaces a llamadas de sistema y los punteros "callbacks?" lo que uno deberia rellenar a la hora de registrar un modulo LSM? |
|---|
| alberto | La interfaz LSM es una estructura de punteros "callback-->y eso?". Esto es lo que tienes que rellenar para registrar |
|---|
| alberto | algunos de los punteros "callback" imitan a l punto de entrada de la llamada del sistema que estan protegiendo, pero no todos |
|---|
| alberto | podemos mirar un ejemplo de llamada para ver como parece esto en terminos de codigo |
|---|
| alberto | la mayoria de los modelos de seguridad se preocuparan, por ejemplo, de la creacion de una nueva tarea, y especificamente execve() que puede cambiar tus dominios de ejecucion |
|---|
| Arador | < nab:#qc> cdub: cuanta sobrecarda esta asociada usando varios enlaces, en que parte del ekrnel (operacions de fs, de sockets, etc) se hacen las mentiras(perdidas?) mas grandes de rendimiento? |
|---|
| Arador | nab: la sobrecarga medida en bechmarks de macro es muy baja |
|---|
| Arador | nab: en el rango 0-2% |
|---|
| Arador | < nab:#qc> cdub: o estaria esto relacionado mas con la implementacion de enlaces dentro del modulo de seguridad? |
|---|
| Arador | totalmente |
|---|
| Arador | los enlaces de red tienden a causar mas sobrecarga |
|---|
| Arador | pero un enlace pobremente diseñado podria serializar la operacion que debe ser altamente concurrente y optimizada |
|---|
| Arador | asique el modulo mismo es critico en la medicion del rendimiento del sistema |
|---|
| Arador | pero, es posible crear un modulo muy simple para presionar el marco de trabajo |
|---|
| AAA | se colapsooo internet |
|---|
| garoeda | i hope everybody gets back |
|---|
| Ocell | juer que mal trago!!! |
|---|
| Arador | ahi vemos, como mencione, que el stack de red tiene mas impacto |
|---|
| Arador | tambien, nuestros numeros muestran que los estados de apertura/cierre y desenlace son mayores que otros enlaces del sistema de ficheros |
|---|
| Arador | considera cualquier cosas que tenga q colgar el buscar el camino del kernel (o entrar) podra hacer varias comprobaciones de permisos, en cada directorio, ademas de una comprobacion en el final del objeto, asi que esto no es una sorpresa. |
|---|
| alberto | considera cualquier cosas que tenga q colgar el buscar el camino del kernel (o entrar) podra hacer varias comprobaciones de permisos, en cada directorio, ademas de una comprobacion en el final del objeto, asi que esto no es una sorpresa. |
|---|
| alberto | quieto, que esto ya lo tenemos |
|---|
| alberto | bien, aqui voy a mostrar un simple flujo de llamada... |
|---|
| alberto | execve("/bin/foo") |
|---|
| alberto | para ver esto en codigo, uno debe de mirar los enlaces LSM basados en bprm. |
|---|
| alberto | cuando la tarea es etiquetada, ya sea via fork o exec, todos los accesos futuros a los objetos del kernel (superbloques via mount(2), ficheros via abrir/leer/escribir.., redes via api de sockets) |
|---|
| alberto | deben de ir a traves del modulo LSM, y las etiquetas en los objetos del kernel son comparadas con la etiqueta de la tarea, esta es la conducta fundamental del LSM. |
|---|
| alberto | < pdp:#qc> pero porque se permite subir de nivel de seguridad desde un "nivel de seguridad inseguro" por el principal nivel de seguridad? |
|---|
| alberto | no estoy seguro de haber entendido tu pregunta. esto es una cuestion de politicas de seguridad. |
|---|
| Arador | <despues de execve("/bin/foo")> |
|---|
| Arador | esto echara un vistazo al objeto bin/foo y devolvera este dentro de un puntero de fichero del kernel |
|---|
| Arador | este vistazo disparara una pareja de comprobaciones de permisos en "/" y "/bin" y "/bin/foo" |
|---|
| Arador | entonces, asumiendo que uno tiene acceso al path completo, los manejadores del binformat seran consultados. |
|---|
| Arador | durante esta fase, una estructura binprm es creada, y las etiquetas LSM. |
|---|
| Arador | esto llega a ser limpio si piensas en un programa setuidado de UNIX |
|---|
| Arador | la tarea puede tener una sola etiqueta (uid 500 == chris, por ejemplo) |
|---|
| Arador | pero la estructura binprm puede tener otra etiqueta (uid 0, por ejemplo). |
|---|
| Arador | despues al modulo se le pregunta si es correcto ejecutar el nuevo programa. Esto incluye ademas transiciones de la tarea actual a un nuevo dominio. |
|---|
| Arador | ste puede ser mas elevado o menos... |
|---|
| Arador | para ver esto en codigo, uno debe de mirar los enlaces LSM basados en bprm. |
|---|
| Arador | cuando la tarea es etiquetada, ya sea via fork o exec, todos los accesos futuros a los objetos del kernel (superbloques via mount(2), ficheros via abrir/leer/escribir.., redes via api de sockets) |
|---|
| Arador | deben de ir a traves del modulo LSM, y las etiquetas en los objetos del kernel son comparadas con la etiqueta de la tarea, esta es la conducta fundamental del LSM. |
|---|
| Arador | < pdp:#qc> pero porque se permite subir de nivel de seguridad desde un "nivel de seguridad inseguro" por el principal nivel de seguridad? |
|---|
| Arador | no estoy seguro de haver entendido tu pregunta. esto es una cuestion de politicas de seguridad. |
|---|
| Arador | por ejemplo, puede ser correcto para el dominio de seguridad de /bin/foo (desde execve ("/bin/foo") el llamar a /bin/bar |
|---|
| Arador | y de acuerdo con la politica d seguridad, puede ser una manera para aumentar privilegios. pero de otra forma no. esto esta todo determinado por la politica asignada al modulo de seguridad. |
|---|
| Arador | de echo, esto es una de las caracteristicas criticas del LSM. |
|---|
| Arador | toda la politica esta dentro de un modulo |
|---|
| Arador | el framework simplemente no le presta atencion |
|---|
| Arador | <@riel_:#qc> cdub: el LSM maneja pasandole descriptores de ficheros via unix domain sockets? |
|---|
| * slack is back (gone 00:37:03) |
| Arador | si, es posible controlar el paso de fd's (descriptores de ficheros) |
|---|
| Arador | algunas politicas pueden permitir esto, pero si quieres tener un niverl de seguridad menor de fd, quizas tus dominio de tareas de seguridad sera menor |
|---|
| Arador | o quizas simplemente no permitirias pasar el descriptor en absoluto |
|---|
| Arador | una pregunta comun: "¿no son los modulos inseguros?" |
|---|
| Arador | esta es una pregunta debatible. Pero LSM no tiene que ser modular. Puede ser compilado estaticamente, como otros modulos, asique no es un problema real |
|---|
| Arador | y por supuesto, el modulo de seguridad controla la carga/descarga de modulos, asique puede ejecutar un barco colgante |
|---|
| Arador | bien, como mencione antes, LSM es para el control de accessos |
|---|
| Arador | es ampliamente utilizado para Mandatory Access Control (MAC) (Control de accessos olbligatorio), pero no se limita a esto |
|---|
| Arador | como tal, el mecanismo Discretionary Access Control (DAC) (control de accessos discrecional) estandar de unix esta todavia en tacto |
|---|
| Arador | y hay un problema de ordenacion entre DAC y MAC |
|---|
| Arador | en general, colocamos los enlaces LSM donde ya existe una logica de comprobacion de permisos |
|---|
| Arador | y comprobamos que LSM antes de recaer en las comprobaciones DAC (como se requiere tipicamente en MAC) |
|---|
| Arador | andre tiene un par de preguntas que me gustaria discutir |
|---|
| Arador | < andre:#qc> cdub: como es la adiccion de LSM contra otro tipo de cierres? |
|---|
| Arador | la API se diferente, sin tener en cuenta si esta adoptada nativamente |
|---|
| Arador | bien, la diferencia principal es el nivel de intrusismo |
|---|
| Arador | la mayoria de las APIs son pequeñas y viven en su propia esquina del kernel |
|---|
| Arador | sin embargo, dada la naturaleza de LSM, toca mucho codigo "core" (basico) del kernel |
|---|
| Arador | y por lo tanto es diferente, especialmente cuando se refiere a la GPL y el codigo del kernel |
|---|
| Arador | la mayoria de los desarrolladores del kernel estan muy concienciados de la GPL y no quieren que su codigo sea explotado de una forma no-GPL |
|---|
| Arador | asique la API LSM es exportada solo como API solamente GPL |
|---|
| Arador | esto es porque toca mucho codigo basico del kernel, es importante dejar claro que el modulo de seguridad esta en el codigo basico del kernel |
|---|
| Arador | y es un trabajo derivado del kernel linux |
|---|
| Arador | insertad el apropiado "No soy abogado" aqui |
|---|
| Arador | no se cuanta gente habremos perdido en los slpits |
|---|
| Arador | asique tomare algunas preguntas |
|---|
| raul | < andre:#qc> ahora todos los añadidos al LSM son procedentes de trabajos y estan forzados a ser GPL entonces se elimina la viable naturaleza secreta de las operaciones de LSM |
|---|
| raul | < andre:#qc> ahora si el secreto de cada modulo LSM es desvelado, cual es el uso del LSM |
|---|
| raul | bien, esto es una cuestion importante, pero espero no caer en la batalla de las licencias |
|---|
| raul | primero de todo, el uso de la interface LSM por si misma es muy proxima al kerne linux. |
|---|
| raul | este enlaza alrededor de los objetos principales del nucleo linux, y habilita/Desabilita accesos |
|---|
| raul | esto puede argumentar que el uso de la interface LSM es claramente un derivado del trabajo del kernel linux |
|---|
| raul | ademas... |
|---|
| raul | en este caso, estamos hablando de seguridad |
|---|
| raul | es bien conocida la preocupacion en seguridad de que los secretos no son buenos para la seguridad |
|---|
| raul | mientras que no se dicte que el codigo por si mismo debe de ser abierto, al menos el algoritmo debe de ser divulgado y bien entendido |
|---|
| raul | de otra forma estas en el borde de la seguridad a traves de la oscuridad |
|---|
| Arador | asique, si revelar los compromisos de tu modulo de seguridad compromete la seguridad del modulo, entonces es que el modulo es inseguro para comenzar(licencias aparte) |
|---|
| Arador | volviendo al asunto de licencias...el proyecto LSM no se preocupa de un camino o otro |
|---|
| Arador | nos preocupamos sobre añadir la infraestructura de seguridad en el kernel linux |
|---|
| Arador | Linus dijo que lo queria, y se lo dimos |
|---|
| Arador | y el piensa que la API LSM deberia exportarse solo como GPL_ONLY |
|---|
| Arador | es un sacrificio que queremos hacer, para asegurar que LSM no se quita del kernel |
|---|
| Arador | creo que esto resuelve la pregunta. Es un tema muy contencioso, a menudo chispas emocionales en vez de argumentos tecnicos |
|---|
| Arador | < andre:#qc> cdub: argumento no valido, solo las futuras versiones pueden ser quitadas no las kviejas |
|---|
| Arador | todo bien, punto tomado |
|---|
| sarnold | (anyone have questions?) |
|---|
| Arador | sin embargo, considera que LSM esta en gran parte fuera del kernel |
|---|
| Arador | estamos a mitad de camino de incluirlo |
|---|
| Arador | asique de lo que nos preocupamos es de incluirlo enteramente |
|---|
| Arador | y 2.5 todavia no es 2.6, asique las cosas todavia pueden cambiar |
|---|
| Arador | Linus tambien dijo, o es GPL_ONLY o lo quitare. periodo. es su arbol y hacemos lo que el (y otras cuestiones de copyright) quieren |
|---|
| Arador | y las cosas que hay en en el arbol LSM existen como un parche al kernel. Y las restricciones de licencia tiende a ser considerada GPL por definicion |
|---|
| Arador | bien, hay otras preguntas |
|---|
| Arador | la charla se ha fragmentado, asique sentiros libres de hablar si no hay cosas claras |
|---|
| Arador | < rene:#qc> cdub: mencionastes la compatibilidad con las capacidades como requerimiento; como encajan ahi? otra policia? |
|---|
| Arador | rene: esa es una buena pregutna |
|---|
| Arador | linux (antes de LSM) soporto parte de POSIX.1e para Capacidades |
|---|
| Arador | asique tenemos que preservar eso |
|---|
| Arador | las capacidades son una ligera mejor a la politica UID == 0 (politica de superusuario) |
|---|
| Arador | sin embargo, las capacidades son razonablemente estaticas |
|---|
| Arador | asique, la compatibilidad de capacidades ha hecho un API de LSM diferente al imaginado originalmente |
|---|
| Arador | <viXard> supongo que existe una pequeña área que no he cubierto. |
|---|
| Arador | LSM intenta mantenerse en el kernel. |
|---|
| Arador | esto quiere decir que no está ampliamente presents en drivers, sistemas de archivoos, etc. |
|---|
| Arador | (claro está, la excepción es capable() que está presente por todos lados ;-) |
|---|
| Arador | y, casi todos los ganchos de LSM son llamados desde el contexto de procesosdic 10 23:40:03 <viXard> sin embargo son llamados en contexto de interrupción |
|---|
| Arador | específicamente, algunoos de los async io data ready events son entregados (y LSM filtrado) allí |
|---|
| Arador | también, llegando paquetes de redes |
|---|
| Arador | asique, cuando uno codifica un módulo LSM se necesita estar al tanto de los contextos de los ganchos que pueden ser llamados |
|---|
| Arador | supongo que debo mencionar lo que tenemos hasta hoy. |
|---|
| Arador | la interfaz LSM es robusta y soporta hasta 150 llamadas |
|---|
| Arador | casi la mitad de las mismas están integradas en el árbol de Linus. |
|---|
| Arador | el código para redes está a punto de ser integrado, pero será un reto hacerlo, debido a cosas derivadas del procesamiento y eso |
|---|
| Arador | además, existen al menos 5 modulos que han sido desarrollados. |
|---|
| Arador | los dos primeros son simples: super usuario, y capacidades |
|---|
| Arador | el tercero añade algo de código de openwall |
|---|
| Arador | (ok, son 6 ;) |
|---|
| Arador | los otros 3 son mucho más complejos |
|---|
| Arador | ok, son 7 XD |
|---|
| Arador | gregkh escribió un modulo ejemplo, mostrando como se puede reforzar una política |
|---|
| Arador | requiriendo un dispositivo USB específico para poder obtener permisos root |
|---|
| Arador | los últimos 3, LIDS, DTE y SELinux son ejemplos más complicados del uso de LSM |
|---|
| Arador | SELinux usa la mayor parte de la interfaz. |
|---|
| Arador | y eso le permite controlar efectivamente cada acceso a cada objet |
|---|
| Arador | permite hacer MAC, TE, MSL. cosas que son importante cuando muchos usuarios tienen acceso a una maquina, |
|---|
| Arador | y ésta posee información confidencial. |
|---|
| Arador | < rene:#qc> TE/MLS? |
|---|
| Arador | Type Enforcement (Tipo de reforzamiento) |
|---|
| Arador | Multi Level Security (Securidad de multi nivel) |
|---|
| Arador | < zanshin:#qc> Podrías explicar la parte acerca de los IDs y el registro de IDs una vez más... cuando un objeto es registrado? |
|---|
| Arador | y cuando este es referenciado cuando un syscall es generado? |
|---|
| Arador | y como son enganchados los ganchos internos en la zona de usuarios? |
|---|
| viXard | bueno, te daré un vista rápida. |
|---|
| viXard | o podemos hablar en privado |
|---|
| viXard | la interfaz LSM proveé una estructura de llamados (punteros de funciones) |
|---|
| viXard | uf, teléfono |
|---|
| Arador | el modulo rellena una estructura con sus llamados especificos de politicas |
|---|
| Arador | entonces se registra en el marco de trabajo |
|---|
| Arador | desde ese punto en adelante, los enganches LSM estan en el kernel |
|---|
| Arador | llamaran (a traves del puntero de la funcion) al modulo |
|---|
| Arador | las llamadas hacen cosas como decir al modulo que un nuevo objeto se esta creando |
|---|
| Arador | uno esta siendo destruido |
|---|
| Arador | o otro esta siendo accedido |
|---|
| Arador | cuando un nuevo objeto se esta creando (un inodo por ejemplo) |
|---|
| Arador | el kernel crea el objeto, entonces llama el modulo para asignar el espacio especifico del modulo |
|---|
| Arador | en el objeto para que el modulo mantenga la etiqueta de seguridad |
|---|
| Arador | la etiqueta es tipicamente el ID de seguridad |
|---|
| Arador | y despues, cuando el objeto sea accedido |
|---|
| Arador | el dominio de seguridad actual (tipicamente ese del proceso que se esta ejecutando actualmente que hizo la llamada por ejemplo) |
|---|
| Arador | puede ser comparado con las etiqueta del objeto |
|---|
| Arador | dependiendo de la politica, esta informatcion es usada para conceder/denegar accesso al objeto |
|---|
| Arador | eso es en resumidads cuentas |
|---|
| Arador | espero que fuera claro |
|---|
| Arador | asique, LSM esta lejos de ser terminado |
|---|
| Arador | aparte de continuar limpiando, e incluir en el kernel |
|---|
| Arador | estamos bucsando maneras para incluirlo mas limpiamente en la infraestructura del kernel |
|---|
| Arador | esto podria mantener la interfaz del modulo limpia, y facl de mantener |
|---|
| Arador | mientras que ahora esta muy desbocado |
|---|
| Arador | (como andre dijo) |
|---|
| viXard | además esperamos incorporar más módulos e ideas de proyectos similares. Por ejemplo RSBAC (para linux) y TrustedBSD |
|---|
| viXard | tienen algunas muy buenas ideas que queremos ver si funcionan y como podemos usarlas. |
|---|
| viXard | Si están interesados en ayudar, por favor péguense una vuelta por lsm.immunix.org. |
|---|
| viXard | allí hay código, documentación, listas de correo, enlaces, enlaces a irc, etc |
|---|
| viXard | Muchas gracias por su tiempo. |
|---|
| viXard | Gracias a todos los traductores y a las personas que han organizado este evento, etc etc etc. |
|---|
| viXard | XD |
|---|
| Arador | plas plas plas etc XD |
|---|