Requisitos del mecanismo básico 2- Requisitos de protección Uniformidad en la protección Igual protección para todos los objetos Protección de granularidad fina A nivel de métodos individuales Flexibilidad Base de diferentes políticas sobre el núcleo básico Movilidad No deben producirse restricciones de movilidad de objetos Uniformidad en la orientación a objetos No introducir abstracciones adicionales
Requisitos del mecanismo básico 3- Principios básicos de diseño (Saltzer y Shroeder 1975) Mínimo Privilegio Permitir lo estrictamente necesario Ahorro de Mecanismos Sencillez de conceptos, diseño e implementación Aceptación por el usuario Mediación Total Ninguna operación escapa al control de seguridad Diseño Abierto
Resumen de características Sistemas con soporte para modelo de objetos e interoperabilidad
INCONVENIENTES Falta de Uniformidad, Flexibilidad, Mínimo privilegio y Mediación total Sistemas Distribuidos, basados en objetos, de grano grueso Sistemas para gestión de MGP
Modelo de Seguridad en Java Caja de arena (JDK 1.0-1.1)
Código local / Código remoto Firmas digitales = código local
Control de acceso Introspección en pila El control se realiza en función del cargador Inconvenientes: Inflexibilidad y sin mínimo privilegio
Modelo de Seguridad en Java Arquitectura seguridad (JDK 1.2) La política asocia clases con dominios Control de acceso: Introspección en pila En las operaciones peligrosas se llama al controlador de acceso Con introspección (1.2) se comprueban permisos (intersección dominios)
Inconvenientes de Java Base de computación fiable muy grande y compleja Granularidad no al nivel de objetos individuales Falta de uniformidad y generalidad del mecanismo: responsabilidad del usuario en la implementación de la protección Falta de flexibilidad para introducir protección a posteriori ¿? Falta de adaptabilidad. Mecanismo “pesado”¿? Sin mediación total Aceptación difícil por el usuario
Elección del Modelo de Protección Análisis de modelos existentes Modo de trabajo Cumplimiento de requisitos Comportamiento respecto a problemas de seguridad Modelos Listas de Control de Acceso Capacidades Modelo Mixto Retículo, Introspección de pila Elección de Capacidades: modelo más adecuado
Análisis de Listas de Control de Acceso Control de acceso a través de la búsqueda en una lista de clientes En un SIOO cada objeto (recurso) llevará asociada una LCA En un sistema discrecional cada objeto puede añadir clientes a su LCA a voluntad
Análisis de Listas de Control de Acceso Problema: Falta de escalabilidad En espacio, tiempo, movilidad de objetos Intento de reducción de problemas escalabilidad Del número de listas: agrupación en ámbitos (Guide) Del número de entradas de cada lista: grupos (Unix)
Análisis de Listas de Control de Acceso Problemas de la reducción: disminuye la seguridad Mediación parcial con la creación de ámbitos Sin mínimo privilegio con la creación de grupos. Otros problemas de las LCAs Dominio de protección asociado al usuario Dependencia entre objetos Sobrecarga del mecanismo de protección Comprobación única primer acceso: imposible revocar (Unix) Complejidad No soluciona el problema del confinamiento
Análisis de Capacidades Control de acceso a través de “entrada” o “llave” al servidor Capacidad: Token que da autoridad para realizar operaciones sobre los objetos
Análisis de Capacidades Independencia entre objetos respecto al mecanismo. Control anónimo a la identidad del poseedor. Facilita la distribución Facilita la escalabilidad en espacio y tiempo Posibilita el control de grano fino Facilita la movilidad Integración en el modelo de objetos Transmisión de capacidad en el intercambio de mensaje Flexibilidad: independencia del concepto usuario
Análisis de otros modelos Modelo Mixto Inconvenientes de las LCA Modelo reticular Control no discrecional Exclusivo de ámbitos especializados Introspección de pila Específico de una implementación particular. No portable
Elección de Capacidades Adaptación capacidades como mecanismo protección Adecuado para un SIOO Objetos como entidades autónomas y autocontenidas Adecuado para un Sistema Distribuido Protección a nivel de cualquier granularidad Capacidades modelo idóneo Integración en el modelo de objetos
Capacidades: Conceptos Generales Qué es una capacidad Una referencia a un objeto junto con un conjunto de permisos sobre las operaciones de ese objeto. La posesión de una capacidad es condición necesaria y suficiente para tener acceso al objeto al que se refiere
Capacidades: Conceptos Generales Modo de Operación
Problema: evitar la falsificación
Capacidades: Conceptos Generales Implementación de capacidades Etiquetado Hardware y Segregación (zona protegida) Capacidades dispersas (encriptadas) Flexibilidad estructuras usuario vs. esfuerzo control falsificación Permisos sobre los métodos Todo/nada (acceso total o acceso denegado) Número fijo de permisos (métodos a proteger) Permisos relativos a la propia capacidad Copia, eliminación de instancias, eliminación de capacidades
Capacidades: Conceptos Generales Operaciones intrínsecas a las capacidades Restricción de permisos (mínimo privilegio) Copia de capacidad, creación de capacidades, incialización, revocación. Implantación del Mecanismo En el Sistema Operativo En los servidores de usuario sin mediación total, responsabilidad del usuario En el compilador y soporte en tiempo de ejecución Dependencia de un lenguaje y posibilidad de agujeros en espacio de usuario
Capacidades: Conceptos Generales Puntos a favor de las capacidades Denominación y protección combinadas Independencia cliente/servidor Eficiencia, simplicidad Flexibilidad, escalabilidad Inconvenientes de las capacidades Control de la propagación (también con LCA) Solución: Monitor de referencia (análisis invocaciones) Revisión y revocación de permisos Solución: Indirección con fachadas
Diseño de las Capacidades Nuevo tipo de capacidades: Orientadas a Objetos Se integra la información de protección con las referenciasa objetos de la máquina abstracta Combina las ventajas de lostipos existentes, evitando susinconvenientes Protección automática decapacidades
| Página siguiente |