Descargar

Sistema Operativo Orientado a Objetos (página 3)

Enviado por Pablo Turmero


Partes: 1, 2, 3, 4
edu.red Diseño de las Capacidades Permisos sobre los métodos que portan las capacidades: Número de permisos variable Tantos como métodos tenga el objeto Permisos relativos a la propia capacidad: Salto de protección Equivale a tener todos los permisos: comprobación no necesaria Optimización de llamadas a objetos no compartidos Alivia la sobrecarga de protección Activado inicialmente en la creación de un objeto

edu.red Diseño de las Capacidades Operaciones intrínsecas a las capacidades Restricción de capacidades Operación Restringir Única funcionalidad exclusiva de la protección Elegida por su sencillez frente a uso de máscara Implantada como instrucción de la máquina o como método de la clase raíz Resto de operaciones sobre capacidades Las ya existentes para las referencias No se incorpora directamente la revocación Posibilidad de extender el sistema incluyéndola si fuera preciso (fachadas)

edu.red Comprobación de permisos Diseño del mecanismo de comprobación de permisos: Implementación en la máquina abstracta Otras implementaciones descartadas por inconvenientes Se ajusta a la integración con el paso mensajes: Máquina Ahora además comprobará los permisos en la referencia Mediación total: todas las operaciones controladas El paso de mensajes es la única forma de operar en el sistemas Referencias son abstracciones del sistema Permite número variable de permisos igual al de métodos del objeto

edu.red Comprobación de permisos Integración con la invocación de métodos

edu.red Resumen del Diseño Uso de capacidades para la protección: control de acceso discrecional Nuevo tipo de capacidades: Capacidades Orientadas a Objetos Fusión de las capacidades y las referencias a objetos de la máquina Diseño de las capacidades: Capacidades Orientadas a Objetos Permisos al nivel de métodos individuales de los objetos Número variable de permisos (tantos como métodos tenga el objeto) Permisos relativos a la propia capacidad: Salto de protección (Todos los permisos activos, no se necesita comprobar) Operaciones intrínsecas a las capacidades: Restricción de métodos Diseño del mecanismo: implantación en la máquina abstracta Integración de la comprobación en el mecanismo de envío de mensajes de la máquina

edu.red Ventajas del Modelo diseñado 1- Cumplimiento de los principios básicos de diseño Mínimo privilegio Granularidad fina de protección: métodos individuales desde objetos individuales Ahorro de mecanismos: robustez Sencillez conceptual y de implementación (menos agujeros por errores) Aceptación Misma semántica del sistema anterior Mediación total Todas las operaciones (invocaciones) son controladas Diseño abierto

edu.red Ventajas del Modelo diseñado 2- Cumplimiento requisitos protección para un SIOO Uniformidad en la Orientación a Objetos y homogeneidad Integración fluida en el modelo del sistema, misma semántica Único mecanismo de protección protege todos objetos por igual Flexibilidad Extensibilidad SIOO: Múltiples políticas posibles sobre mecanismo básico Desarrollo (y sobrecarga) extensiones sólo usado si se necesita Movilidad Objetos autónomos: encapsulan también su información de protección en las capacidades Protección de granularidad fina Permisos de longitud variable: protección de métodos individuales (mínimo privilegio)

edu.red Ventajas del Modelo diseñado Problema característico generado por las listas de control de acceso Dominio protección asociado al usuario (cada proceso tiene el máximo de privilegios del usuario) Espía puede denominar cualquier objeto en general (ej. Fichero de datos privados) y engañar al servidor comunicándoselo El proceso servidor actúa con todos los permisos de su usuario, incluyendo el acceso al objeto privado (al que el espía no debería poder acceder) Servidor : compilar (graba factura en /adm/factura) Espía: compilar mifichero /adm/factura (sobreescribe los datos de facturación con el log)

edu.red Ventajas del Modelo diseñado Confinamiento (propagación) Inexistencia canal comunicación entre servidor y espía compinchados Servidor no tiene capacidad hacia el espía (canal de acceso) y vvsa. Imposible que el espía (o el servidor) cree de la nada esa capacidad Con listas de control de acceso no se confina (e.d. no evita propagación) El servidor puede añadir en cualquier momento al espía a su lista de control de acceso (acceso indirecto del espía al dato a través del servidor) Puede crear de la nada el canal de comunicación Caso complejo confinamiento (evitar conspiradores en comunicación) Evitar que si hay una vía inicial de comunicación se convierta en un canal de comunicación de los datos privados Monitor de referencia: Aunque haya capacidad hacia el espía, control de las invocaciones la capacidad de acceso al objeto privado Mediante la reflectividad de la máquina abstracta

edu.red Ventajas del Modelo diseñado 4- Ventajas adicionales Facilidad de uso por su total transparencia Obtención, donación, y presentación de capacidades es transparente Protección automática de capacidades Imposibilidad falsificación y uso como referencias de usuario Permisos de longitud arbitraria Abstracción del sistema, implementación oculta: permisos arbitrarios Extensibilidad del sistema con seguridad y flexibilidad Todos objetos protegidos uniformemente con las capacidades: control de quién y qué extiende el sistema Abstracciones adicionales para la protección innecesarias Innecesarios otros conceptos (usuario, superusuario, dominio, etc.) Posible construirlas fuera del núcleo, sólo si necesario

edu.red Políticas de seguridad Ejemplos de políticas que muestran la flexibilidad del mecanismo Tres situaciones diferentes Manejo de la restricción de permisos Manejo de la revocación de autoridad Manejo de la propagación de autoridad Estructura General del Sistema Usuarios con objetos propios Login y shell Servidor de nombres

edu.red

Servidor de nombres = directorio = dominio (conjunto de objetos) Asocia un nombre simbólico con un objeto a través de una referencia (capacidad) al mismo Servidor de Nombres

edu.red Manejo de Permisos Ejemplos de posibilidades Dominios privados Dominios públicos Dominios asociados a clases Dominios arbitrarios Otros Políticas asociadas a usuarios Dominios gestionados por un gestor de seguridad

edu.red Manejo de Permisos Dominios privados

edu.red Manejo de Permisos Dominios públicos

edu.red Manejo de Permisos Dominios asociados a clases

Cada clase tiene asociado el conjunto de objetos permitido (dominio) a través de una política Ambos (política y dominio) se implementan con un servidor de nombres

edu.red Manejo de Permisos Dominios arbitrarios

Las políticas se pueden escoger arbitrariamente Repositorio de políticas Implementado en otro servidor de nombres

edu.red Manejo de Revocación Revocación con fachadas

Un gestor de fachadas devuelve referencias a fachadas En lugar de dar acceso directo al objeto se pasa la fachada Posibilita la revocación selectiva del acceso eliminando la fachada (o su acceso al objeto) Fachadas más “inteligentes”: un solo uso, etc.

edu.red Control de Propagación Control mediante una política (monitor de referencia)

Control de todas las invocaciones Comprobación de que parámetros, etc. cumplen política de seguridad Monitor de referencia: implementación usando reflectividad

edu.red Análisis del rendimiento Objetivo de las pruebas Cálculo del tiempo adicional que supone la protección en la invocación de un método (50000 iteraciones) Tipos de invocaciones Método de clase básica (entero, real) Método vacío de usuario Método arbitrario de usuario Comparativa de pruebas Máquina base / Máquina con protección Con / Sin comprobación de permisos

Partes: 1, 2, 3, 4
 Página anterior Volver al principio del trabajoPágina siguiente