11
Monitor de Referencias (2)
Características
Tamperproof.
Siempre invocado. Todos los accesos deben ser examinados.
Suficientemente pequeño como para ser analizado. La certeza de correctitud decrece cuando la complejidad y tamaño aumenta.
Colección de controles de acceso a: archivos, dispositivos, memoria, IPC y otros objetos.
12
Trusted Computing Base (TCB)
Es todo lo necesario en un S.O. Confiable para asegurar que se cumpla una política de seguridad.
Es la parte del S.O. donde recae toda nuestra confianza acerca de la seguridad de todo el sistema.
13
Funciones de Monitoreo del TCB
Activación de Procesos: los cambios de contexto, crear y destruir procesos requiere información sensitiva.
Cambio de Dominio de ejecución: procesos en un dominio pueden llamar a un proceso de otro dominio para obtener datos o servicios más confidenciales.
Protección de Memoria: cada dominio tiene código y datos, por lo tanto la confidencialidad y la integridad de cada dominio es importante.
Operaciones de I/O: pueden atravesar dominios y puede haber software involucrado.
14
Ventajas de Diseño del TCB
La separación del TCB de lo no-TCB es conveniente.
El código TCB debe correr en un estado protegido que lo proteja.
Items fuera del TCB pueden ser cambiados a voluntad: utilidades, compiladores, GUI, etc.
Mediante técnicas de Separación se simplifica la evaluación de código confiable.
15
Agregando un TCB
Tomar los módulos existentes del S.O.
Los módulos incluyen funciones referidas a la seguridad y otras funciones.
Reunir todas las funciones que tengan que ver con la seguridad en algo llamado TCB.
16
Empezando con un TCB
Diseñar primero el security kernel.
Diseñar el S.O. alrededor de él.
El security kernel es una capa de interfase con el hw.
Monitorea todos los accesos del S.O. al hw y realiza todas las funciones de protección.
Pequeño y eficiente.
Dominios: security kernel, S.O. y usuario.
17
Separación/Aislamiento
Separación física de procesos:
los procesos utilizan hardware separado.
Separación temporal de procesos:
los procesos “confidenciales” corren en distintos momentos que el resto de los procesos.
Separación criptográfica de procesos:
se usa la criptografía para proteger los datos de un proceso.
Separación lógica de procesos:
Aislamiento: monitor de referencias separa los objetos de usuarios distintos.
18
Virtualización (1)
La máquina real es emulada en una “máquina virtual”.
Funcionalidad del S.O. sobre la máquina virtual.
Buena protección
y Aislamiento.
Difícil emular hw.
19
Virtualización (2)
20
Diseño por Capas
Sistemas por capas.
Una o más capas se ejecutan en modo kernel.
Buena performance, modular, extensible, estructura rígida.
Difícil hacer un buen diseño de capas.
21
Diseño Seguro por Capas
Ejemplos:
hardware,
kernel,
S.O,
usuario
22
Diseño por Capas
Las operaciones más “sensitivas” están en los círculos más internos.
Una única función lógica implementada en varios módulos es un ej. de diseño por capas.
La figura muestra una función realizada por un conjunto de módulos que operan en distintas capas.
23
Control de Daños mediante Capas
La estructura jerárquica permite la identificación de las partes más críticas.
Las porciones críticas pueden ser analizadas (correctitud).
El aislamiento limita los efectos de los problemas y fallas.
24
Estructura de Anillos (1)
Los anillos más bajos tienen mayor privilegio.
Cada proceso corre en un nivel de anillo particular.
El Anillo I incluye los privilegios de todos los anillos J con J > I.
Cada área de datos de procedimiento se denomina segmento.
25
Estructura de Anillos (2)
Un segmento es protegido por b1, b2 y b3, donde b1 ? b2 ? b3.
Ring bracket: (b1, b2, b3).
Indica grado de confianza de un segmento.
Access bracket: (b1, b2)
Conjunto de anillos de procesos que pueden acceder al segmento libremente.
Segmentos menos confiables tienen access bracket que empieza en números más altos.
Call bracket: (b2, b3)
Conjunto de anillos que pueden llamar en este segmento solamente en ciertos puntos.
26
Certeza en Sistemas Confiables
El entorno afecta las necesidades, ¿es apropiado el S.O. para cierto conjunto de necesidades?
Testeo
Verificación Formal
Validación Informal
27
Fallas Conocidas en S.O.s Típicos
Procesamiento de I/O
Frecuentemente escapan a las restricciones del security kernel.
Dependencias de I/O, código dependiente del hw.
Ambigüedad en la Política de Acceso
Acceso separado de protección/sharing de recursos.
Mediación incompleta
Tradeoff entre performance y mediación completa.
Generalidad
Cabos sueltos (pueden ser trapdoors!) que se dejan en el sistema para que sea más flexible.
Nivel de privilegio para software de instalación.
28
Métodos de Confianza: Testing
Puede demostrar la existencia de una falla, pero que pase los tests no me asegura que no existan.
La cantidad de posibles entradas y el gigantesco estado interno hacen que sea una tarea difícil.
El testeo de efectos observables en lugar de analizar las estructuras internas no asegura completitud.
El testeo basado en agregar código que haga evidente el estado interno de un producto afecta su comportamiento y luego puede ser el punto de partida de nuevas vulnerabilidades.
29
Técnicas de Testing
Funcional
Unidad
Integridad
Regresión
Cobertura (Ingeniería del SW)
Penetración o Tiger teams:
expertos tratan de “hackear” el S.O o sistema.
si un sistema resiste este tipo de ataques no quiere decir que esté libre de errores.
30
Verificación Formal
Un S.O. se reduce a un teorema que debe ser probado:
Tarea formidable.
Meses o años de esfuerzo.
Los probadores de teoremas pueden ayudar, pero la mayor parte del trabajo requiere esfuerzo humano.
Temas a considerar:
La verificación lleva más tiempo que escribir el propio algoritmo del producto.
Las verificaciones llevan muchísimo tiempo.
Es un proceso muy complejo: en ciertos sistemas no vale la pena ni intentarlo.
 Página anterior | Volver al principio del trabajo | Página siguiente  |