N

1
Núcleo de Seguridad para unSistema Operativo
Orientado a Objetos Soportado por una Máquina
Abstracta
Tesis Doctoral

• Autora Mª Ángeles Díaz Fondón
• Director Juan Manuel Cueva Lovelle
• Departamento de Informática
• Universidad de Oviedo

2
Tesis DoctoralÍndice

• Objetivos y Organización
• Fase 1 Estado del arte
• Fase 2 Análisis de requisitos
• Fase 3 Estudio de los sistemas relevantes
• Fase 4 Elaboración del núcleo de seguridad
• Fase 5 Demostración de la idea
• Conclusiones

3
Objetivos y Organización de esta Tesis

• Desarrollo de un núcleo básico de seguridad
  (mecanismo de protección) para un Sistema
  Integral Orientado a Objetos (SIOO) con máquina
  abstracta,permitiendo cooperación segura entre
  objetos.
• Cumplimiento requisitos de diseño de mecanismos
  de seguridad y específicos de SIOO
• Protección total, homogénea y a nivel de métodos
• Solución más elegante y completa de necesidades
  de protección de un SIOO
• Rendimiento adecuado
• Objetivos Básicos
• Uniformidad, Flexibilidad, Integración en el
  modelo

4
Objetivos y Organización de esta Tesis

• Fases del desarrollo

5
Tesis DoctoralÍndice

• Objetivos y Organización
• Fase II Análisis de requisitos
• Fase III Estudio de los sistemas relevantes
• Fase IV Elaboración del núcleo de seguridad
• Fase V Demostración de la idea
• Conclusiones

• Fase I Estado del arte

6
Fase I Estado del arteNecesidad de un Sistema
Integral OO

• Tendencia hacia Sistemas Distribuidos
• Desadaptación de impedancias con el uso de TOO
• Base hardware convencional
• Sistemas Operativos convencionales
• Necesidad de comunicación entre espacios de
  direcciones
• Necesidad de comunicación entre modelos de
  objetos
• Soluciones aportadas con capas intermedias de
  adaptación

7
Fase I Estado del arteSistema Integral
Orientado a Objetos

• Mundo de objetos homogéneos, virtualmente
  infinito en espacio y tiempo, independientes de
  la localización, con soporte exclusivamente OO.

8
Fase I Estado del arteSoluciones de seguridad
existentes

• Heterogeneidad de protección
• Uso de diversos mecanismos
• Base de Computación fiable(BCF) grande
• Agujeros por interacciónno prevista entre
  mecanismos
• Inseguridad en distribución
• Falta de protección para la interoperabilidad de
  objetos distribuidos
• Pocas y malas soluciones de seguridad

9
Fase I Estado del arteSeguridad en un SIOO

• Núcleo de seguridad homogéneo

10
Fase I Estado del arteConceptos Generales

• Aspectos de la seguridad de un sistema
• Seguridad en el acceso al sistema
• Seguridad en el uso de recursos y servicios
• Seguridad en el uso de redes
• Separación entre seguridad y protección
• Política Establece qué accesos son permitidos
• Mecanismo Proporciona cómo se controlan los
  accesos (Protección)
• Objetivo Búsqueda de mecanismo de control de
  acceso a recursos y servicios (objetos en un SIOO)

11
Fase I Estado del arteProblemas relativos a la
seguridad

• Problema de la fuga de información
• 4 casos, dependiendo de
• Existencia o no de canal de comunicación entre
  servidor y espía
• Compinchamiento o no entre servidor y espía

12
Fase I Estado del arte Problemas relativos a la
seguridad

• Denominaciones de problemas de fuga
• Defensa perimetral (canal no, compinches no)
• Representante confuso (canal sí, compinches no)
• Confinamiento (canal no, compinches sí)
• Conspiradores en comunicación (canal sí,
  compinches sí)
• Denominaciones clásicas de los problemas
• Delegación y sospecha mutua
• Confinamiento y Propagación
• El problema de la Revocación

13
Fase I Estado del arteModelos de control de
acceso

• Modelo de Matriz de Acceso (discrecional)
• Listas de control deacceso (LCA)
• Capacidades
• Modelo mixto
• Modelo Take Grant
• Modelo de flujo de información

14
Tesis DoctoralÍndice

• Objetivos y Organización
• Fase I Estado del Arte
• Fase III Estudio de los sistemas relevantes
• Fase IV Elaboración del núcleo de seguridad
• Fase V Demostración de la idea
• Conclusiones

• Fase II Análisis de requisitos

15
Fase II Análisis de RequisitosRequisitos del
mecanismo básico

• 1- Plataforma de desarrollo SIOO
• Requisitos de la plataforma Álv98
• Uniformidad conceptual en torno a la OO
• Modo de trabajo exclusivamente OO
• Homogeneidad de objetos
• Transparencia
• Heterogeneidad y portabilidad
• Seguridad, Concurrencia
• Multilenguaje/Interoperabilidad
• Flexibilidad

16
Fase II Análisis de RequisitosRequisitos del
mecanismo básico

• -Arquitectura SIOO
• Máquina abstractareflectiva OO
• Modelo único de objetosdel sistema
• Sistema Operativo OO
• Conjunto de objetosnormales
• Transparencia persistencia, concurrencia,
  distribución
• Espacio único de objetos sin separación
  usuario/sistema
• Extensibilidad OO, modificación máquina,
  funcionalidad clases básicas, reflectividad

17
Fase II Análisis de RequisitosRequisitos 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

18
Fase II Análisis de RequisitosRequisitos 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

19
Tesis DoctoralÍndice

• Objetivos y Organización
• Fase I Estado del Arte
• Fase III Estudio de los sistemas relevantes
• Fase IV Elaboración del núcleo de seguridad
• Fase V Demostración de la idea
• Conclusiones

• Fase 3 Estudio de los sistemas relevantes

20
Fase III Estudio de Sistemas RelevantesResumen
de características

• Sistemas con soporte para modelo de objetos e
  interoperabilidad

• Sistemas Distribuidos, basados en objetos, de
  grano grueso

• Sistemas para gestión de MGP

• INCONVENIENTES
• Falta de Uniformidad, Flexibilidad, Mínimo
  privilegio y Mediación total

21
Fase III Estudio de Sistemas RelevantesModelo
de Seguridad en Java

• Caja de arena (JDK 1.0-1.1)

Control de acceso Introspección en pila

• Código local / Código remoto
• Firmas digitales código local

• El control se realiza en función del cargador

• Inconvenientes Inflexibilidad y sin mínimo
  privilegio

22
Fase III Estudio de Sistemas RelevantesModelo
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)

23
Fase III Estudio de Sistemas RelevantesInconveni
entes 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

24
Tesis DoctoralÍndice

• Objetivos y Organización
• Fase 1 Estado del arte
• Fase 2 Análisis de requisitos
• Fase 3 Estudio de los sistemas relevantes
• Fase 5 Demostración de la idea
• Conclusiones

• Fase 4 Elaboración del núcleo de seguridad

25
Fase IVElaboración del Núcleo de Seguridad

• Aspectos en que se divide el desarrollo de la
  idea

• 1- Elección del modelo de protección

• 2- Diseño del modelo

• 3- Diseño del mecanismo de comprobación de acceso

26
Fase IV Elaboración del núcleo de
seguridadElecció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

27
Elección del Modelo de Protección 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

28
Elección del Modelo de ProtecciónAná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)

29
Elección del Modelo de Protección 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

30
Elección del Modelo de Protección 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

31
Elección del Modelo de Protección 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

32
Elección del Modelo de Protección 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

33
Elección del Modelo de Protección 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

34
Elección del Modelo de Protección 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

35
Elección del Modelo de Protección Capacidades
Conceptos Generales

• Modo de Operación

• Problema evitar la falsificación

36
Elección del Modelo de Protecció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

37
Elección del Modelo de Protección 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

38
Elección del Modelo de Protección 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

39
Fase IVElaboración del Núcleo de Seguridad

• Aspectos en que se divide el desarrollo de la
  idea

1- Elección del modelo de protección 3- Diseño
del mecanismo de comprobación de acceso

• 2- Diseño del modelo de protección

40
Diseño del Modelo de Protección 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

41
Diseño del Modelo de Protección 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

42
Diseño del Modelo de Protección Diseño de las
Capacidades

• Operaciones intrínsecas a las capacidades
• Restricción de capacidades
• Operación Restringir ltcapacidadgt ltmétodogt
• Ú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)

43
Fase IVElaboración del Núcleo de Seguridad

• Aspectos en que se divide el desarrollo de la
  idea

1- Elección del modelo de protección 2- Diseño
del modelo de protección

• 3- Diseño del mecanismo de comprobación de acceso

44
Diseño del Mecanismo de control de acceso
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

45
Diseño del Mecanismo de control de acceso
Comprobación de permisos
Integración con la invocación de métodos
46
Fase IV Elaboración del núcleo de seguridad
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

47
Fase IV Elaboración del núcleo de seguridad
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

48
Fase IV Elaboración del núcleo de seguridad
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)

49
Fase IV Elaboración del núcleo de seguridad
Ventajas del Modelo diseñado

• 3- Resolución de problemas de un sistema de
  seguridad
• Defensa perimetral
• Capacidades único canal de comunicación posible
  en el sistema
• Imposibilidad del espía de obtener canal
  comunicación con servidor
• El servidor no está compinchado y nunca le
  pasaría una capacidad para que tuviera acceso a
  él
• Delegación (representante confuso)
• Cliente simplemente pasa capacidad (restringida)
  para los datos privados al servidor
• Espía no puede engañar al servidor puesto
• No puede denominar los datos privados (objeto
  privado)
• Necesitaría previamente una capacidad para ellos
  (las capacidades son el único medio de denominar
  a un objeto en el sistema)

50
Fase IV Elaboración del núcleo de seguridad
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 ltfuentegt ltloggt (graba factura
  en /adm/factura)
• Espía compilar mifichero /adm/factura
  (sobreescribe los datos de facturación con el
  log)

51
Fase IV Elaboración del núcleo de seguridad
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

52
Fase IV Elaboración del núcleo de seguridad
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

53
Tesis DoctoralÍndice

• Objetivos y Organización
• Fase I Estado del arte
• Fase II Análisis de requisitos
• Fase III Estudio de los sistemas relevantes
• Fase IVElaboración del núcleo de seguridad
• Conclusiones

• Fase V Demostración de la idea

54
Fase V Demostración de la ideaPolí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

55
Políticas de seguridad sobre el mecanismo
básicoServidor de Nombres

• 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

56
Políticas de seguridad sobre el mecanismo básico
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

57
Políticas de seguridad sobre el mecanismo básico
Manejo de Permisos

• Dominios privados

58
Políticas de seguridad sobre el mecanismo básico
Manejo de Permisos

• Dominios públicos

59
Políticas de seguridad sobre el mecanismo básico
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

60
Políticas de seguridad sobre el mecanismo básico
Manejo de Permisos

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

61
Políticas de seguridad sobre el mecanismo básico
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.

62
Políticas de seguridad sobre el mecanismo básico
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

63
Fase V Demostración de la Idea El Sistema
Integral Oviedo3
64
Fase V Demostración de la Idea La Máquina
Abstracta Carbayonia
65
Fase V Demostración de la Idea La Máquina
Abstracta Carbayonia

• El Lenguaje Carbayón
• Orientado a objetos puro
• Instrucciones declarativas para descripción de
  clases
• Herencia múltiple, asociación y agregación
• Definición de métodos referencias e instancias
• Pequeño número de instrucciones (15)
• Instrucciones de asignación creación, invocación,
  eliminación, control de flujo, manejo de
  excepciones
• Jerarquía de clases básicas

66
Fase V Demostración de la Idea Diseño del
Prototipo dela Máquina
67
Fase V Demostración de la Idea Diseño del
Prototipo de la Máquina
68
Fase V Demostración de la Idea Implantación del
Mecanismo

• Integración de Capacidades con Referencias
• Respecto el diseño
• Actualización operaciones referencias contemplar
  permisos
• New, Assign, Copy, Delete,
• Actualización invocación métodos (instrucción
  call)
• Creación de una nueva instrucción ForbidExec
• Respecto a la implementación
• Adición de nuevos métodos a la clase TRef
• CanExec(), SkipProtection(), FindMethod(),
  ClonePerms(), ClearSecurity()
• GetMethoIndex
• GetName
• ...

69
Fase V Demostración de la Idea Implantación del
Mecanismo

• Adición de la instrucción ForbidExec (restricción
  permisos)

70
Fase V Demostración de la Idea Implantación del
Mecanismo

• Ejecución de la instrucción ForbidExec
• Restringir el permiso de acceso al método indicado

71
Fase V Demostración de la Idea Implantación del
Mecanismo

• Comprobación de permisos (instrucción Call)

72
Fase V Demostración de la idea 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

73
Fase V Demostración de la idea Análisis del
rendimiento
74
Fase V Demostración de la idea Análisis del
rendimiento

• Conclusiones del análisis
• Sobrecarga del salto de protección casi nula
  (016)
• Sobrecarga de la comprobación de permisos
• Llamadas elementales (14 y 24)
• Llamadas a métodos de usuario (0,26)
• Consideraciones de rendimiento
• Protección siempre implica sobrecarga
• Optimizaciones en el rendimiento

75
Fase V Demostración de la idea Análisis del
rendimiento

• Disolución del impacto global de la protección en
  aplicaciones reales
• Número reducido de llamadas a proteger
• Operaciones protegidas sobre objetos de usuario
  en su mayoría (sobrecarga relativa protección
  menor en éstas)
• Tiempo de ejecución de los métodos protegidos muy
  grande en comparación con el tiempo de protección
• Técnicas de análisis estático
• Comparativa con Java
• Sobrecarga introducida del mismo orden que
  nuestro sistema (03 mínimo)

76
Fase V Demostración de Flexibilidad Elaboración
de un Entorno Operativo

• Desarrollo de un entorno operativo de ejemplo
• Manipulación de capacidades a nivel de interfaz
  de usuario
• Establecimiento de un servicio de denominación de
  objetos seguro
• Establecimiento de usuarios y autenticación de
  los mismos
• Establecimiento de interfaz de trabajo tipo
  Intérprete de comandos

77
Fase V Demostración de Flexibilidad Entorno
Operativo con política de seguridad

• Directorio privado por usuario objetos privados
• Ejemplo de compartición
• directorio público compartido por todos usuarios
  (tablón anuncios)
• Inserción de objetos, restringiendo previamente
  las operaciones que no pueda invocar el público
  en general
• Shell de usuario se inicia con referencias a
  estos directorios
• Imposible acceder a objetos privados de otros
  usuarios

78
Fase V Demostración de Flexibilidad Elaboración
de un Entorno Operativo

• Algunas operaciones del shell
• Cargar y descargar clases
• Crear objetos
• Restringir permisos sobre un objeto
• Enviar objetos a un directorio público
• Ejecutar métodos de objetos (con o sin permisos
  restringidos)
• Gestionar usuarios

79
Fase V Demostración de Flexibilidad Elaboración
de un Entorno Operativo

• Diagrama de clases

80
Tesis DoctoralÍndice

• Objetivos y Organización
• Fase I Estado del arte
• Fase II Análisis de requisitos
• Fase III Estudio de los sistemas relevantes
• Fase IVElaboración del núcleo de seguridad
• Fase V Demostración de la idea

• Conclusiones

81
Conclusiones Resultados a destacar

• Modelo de capacidades el más adecuado para SIOO
• Capacidades más adecuadas que LCA
• Peligro de las LCA
• Ventajas del modelo propuesto capacidades OO
• Cumplimiento principios diseño sistemas seguridad
• Otros objetivos y ventajas alcanzados
• Uniformidad en la OO, homogeneidad, flexibilidad,
  adpatabilidad
• Sencillez conceptual y de implementación
• Rendimiento adecuado
• Permisos de longitud arbitraria
• Protección automática de capacidades

82
Conclusiones Resultados a destacar

• Aplicación resultados a otros sistemas
• Insuficiencia mecanismos protección plataforma
  Java
• Mejora de la plataforma Java
• Implementación de prototipos
• Flexibilidad del concepto de SIOO
• Importancia de la reflectividad para la
  extensibilidad

83
Conclusiones Futuras Líneas de Investigación

• Estudio de patrones de comportamiento en
  aplicaciones
• Desarrollo completo de un entorno de usuario
• Mejora en la implementación de la máquina
• Ampliación de la reflectividad de la máquina para
  soporte de monitores de referencia
• Aplicación a la plataforma Java

84
Conclusiones Aportaciones a la investigación

• Capability-Based Protection for Integral
  Object-Oriented Systems . Díaz Fondón, M.A., D.
  Álvarez Gutiérrez, L.Tajes Martínez, F. Álvarez
  García y J.M. Cueva Lovelle. Proceedings of the
  COMPSAC'98, 22 Conference in Computer Software
  and Applications, pp. 344-349. IEEE Computer
  Society Press. 1998.
• Merging Capabilities with the Object Model of an
  Object-Oriented Abstract Machine. Díaz Fondón,
  M.A., D. Álvarez Gutiérrez, A. García-Mendoza
  Sánchez, F. Álvarez García, L. Tajes. Martínez y
  J.M. Cueva Lovelle. Proceedings of the ECOOP'98
  Workshop on Distributed Object Security and the
  4th Workshop on Mobile Object Systems, pp. 9-13.
  Inria Rhône-Alpes, Julio de 1998.
• A Protection Mechanism for an Object-Oriented
  Operating System Based on an Abstract Machine.
  Díaz Fondón, M.A. Bosch, I. y S. Mitchell (Eds.)
  Object-Oriented Technology. Lecture Notes in
  Computer Science 1357, pp. 410. Springer-Verlag,
  1998. ISBN 3-540-64039-8
• Integrating Capabilities into the Object Model
  to Protect Distributed Object Systems Díaz
  Fondón, M.A., D. Álvarez Gutiérrez, A.
  García-Mendoza Sánchez, F. Álvarez García, L.
  Tajes Martínez y J.M. Cueva Lovelle. Tari, Z.,
  R. Meersman, R. Soley y O. Bukhres (Eds.).
  Proceedings of the International Symposium on
  Distributed Objects and Applications (DOA99),
  pp. 374-383. IEEE Computer Society Press, 1999.

85
Conclusiones Resumen

• Mecanismo de protección basado en capacidades
• Diseñado para un Sistema Integral Orientado a
  Objetos (SIOO)
• Cumple requisitos generales de diseño de
  mecanismo de seguridad y específicos para SIOO
• Propiedades adicionales protección automática de
  capacidades y número variable permisos
• Sistema que soluciona de manera más elegante y
  completa las necesidades de protección de un
  SIOO, con un rendimiento adecuado.

86
Tesis Doctoral

• Núcleo de Seguridad para unSistema Operativo
  Orientado a Objetos Soportado por una Máquina
  Abstracta
• Fin de la Exposición
• (c) Marián Díaz Fondón
• Marzo de 2000