4. Seguridad y Software
• La seguridad debe ser un hecho durante todas
las fases del desarrollo
Motivación - 4
5. Seguridad y Software
• La seguridad debe ser un hecho durante todas
las fases del desarrollo
• Es un cross-cutting concern
Motivación - 5
6. Seguridad y Software
• La seguridad debe ser un hecho durante todas
las fases del desarrollo
• Es un cross-cutting concern
• Veremos un ejemplo utilizando AspectJ
Motivación - 6
8. AC con Aspectos
• Identification
– Asignar una identidad a los clientes
Motivación - 8
9. AC con Aspectos
• Identification
– Asignar una identidad a los clientes
• Authentication
– Afirmar que alguien es quien dice ser
Motivación - 9
10. AC con Aspectos
• Identification
– Asignar una identidad a los clientes
• Authentication
– Afirmar que alguien es quien dice ser
• Authorization
– Asegurar que tiene los permisos necesarios
Motivación - 10
11. AC con Aspectos
• Asumiremos una clase Server que
implementa service de la interfaz
ServerInterface
Motivación - 11
22. Seguridad y AOP
1. Código más mantenible
2. Separación de responsabilidades
(especialización)
Motivación - 25
23. Seguridad y AOP
1. Código más mantenible
2. Separación de responsabilidades
(especialización)
3. Las interacciones framework-application
están bien definidas
Motivación - 26
26. 2 – Aspectos y Seguridad
HACIA UN SISTEMA DE PERMISOS
29
27. Identificando el problema
• Usar aspectos para mejorar la seguridad
puede ser un arma de doble filo
Aspectos y Seguridad - 30
28. Identificando el problema
• Usar aspectos para mejorar la seguridad
puede ser un arma de doble filo
1. Invocation Interception
2. Privileged Aspects
Aspectos y Seguridad - 31
34. Problemas
• Advices, inter-type declarations pueden
alterar el estado de un objeto
• La interacción de dos o más módulos puede
ser influenciada
37
35. Problemas
• Advices, inter-type declarations pueden
alterar el estado de un objeto
• La interacción de dos o más módulos puede
ser influenciada
• Un programa “seguro” sin aspectos no lo es
necesariamente con aspectos.
38
36. Problemas
• Advices, inter-type declarations pueden
alterar el estado de un objeto
• La interacción de dos o más módulos puede
ser influenciada
• Un programa “seguro” sin aspectos no lo es
necesariamente con aspectos.
• …intencional o accidentalmente
39
38. Soluciones propuestas
• Invocation Interception
– Uso de declare precedence
• No es suficiente!
– Se vuelve intratable con muchos aspectos
– No hay un aspecto en el tope de la jerarquía
41
40. Soluciones propuestas
• Privileged Aspects
– Eliminarlos por completo
• No es suficiente!
– Adaptar un módulo no diseñado para ser “seguro”
– Una política puede depender del estado interno
de un módulo
43
41. Soluciones propuestas
• Modificar o extender el lenguaje de aspectos
– Por ejemplo, describir qué partes pueden ser
accedidas por cierto módulo
44
42. Soluciones propuestas
• Modificar o extender el lenguaje de aspectos
– Por ejemplo, describir qué partes pueden ser
accedidas por cierto módulo
• No es suficiente!
– Abstracciones de aspectos son “compiladas” en
abstracciones de objetos
• Los aspectos desaparecen
45
43. An Aspect Permission System
• Funcionamiento en tiempo de ejecución
(load-time o run-time)
46
44. An Aspect Permission System
• Funcionamiento en tiempo de ejecución
(load-time o run-time)
• Inserción de chequeos de seguridad (weaving)
47
45. An Aspect Permission System
• Funcionamiento en tiempo de ejecución
(load-time o run-time)
• Inserción de chequeos de seguridad (weaving)
• Mantener una identidad de los aspectos (en
caso de inlining)
48
46. 3 – Un sistema de permisos con AOP
HISTORY-BASED ACCESS CONTROL
49
48. History-based vs Stack-based
inspection
• Los aspectos son “compilados” (woven) a
bytecode
=> Los advices no dejan trazas en el stack
51
49. History-based vs Stack-based
inspection
• Los aspectos son “compilados” (woven) a
bytecode
=> Los advices no dejan trazas en el stack
• Por lo tanto, necesitamos mirar algo más que
el Stack en presencia de Aspectos
54
53. 1) Weaver-based
• Implementación:
– Sólo afecta al weaver de aspectos
– La JVM no sufre modificaciones
– Basado en anotaciones
• Independiente de la estrategia y del momento
del weaving
58
54. 1) Weaver-based
• Implementación:
– Sólo afecta al weaver de aspectos
– La JVM no sufre modificaciones
– Basado en anotaciones
• Independiente de la estrategia y del momento
del weaving
• Los aspectos no pueden interferir con el
modelo de seguridad
59
57. 2) History-based
• Permisos actuales dependen de todos los
permisos anteriores
1. Derechos estáticos (static rights, SR)
2. Derechos actuales (current rights, CR)
CR0 = SR
CRi ≤ ∩k<i CRk
62
58. 2) History-based
• En load-time (o compile-time) se asignan los
SR de cada aspecto
63
59. 2) History-based
• En load-time (o compile-time) se asignan los
SR de cada aspecto
• Centrado en la clase PermissionManager
64
60. 2) History-based
• En load-time (o compile-time) se asignan los
SR de cada aspecto
• Centrado en la clase PermissionManager
• Cuando corresponda, se llama a
demand(Permission p) para chequear
CR = p v p => CR
65
72. Evaluación de este enfoque
• El modelo History-based es muy estricto
comparado con uno Stack-based
• Una implementación ideal requeriría integrar
el sistema al compilador y al lenguaje base
• No toma en cuenta el mecanismo de
class-loading
77
73. 4 – AOP y el modelo de seguridad de Java
CLASS-BASED SECURITY
78
74. Class-based security
• Al considerar el mecanismo de class-loading,
el supuesto de identidad de aspectos ya no es
válido
79
75. Class-based security
• Al considerar el mecanismo de class-loading,
el supuesto de identidad de aspectos ya no es
válido
• ¿Cómo integrar aspectos con el modelo de
clases de Java?
80
77. Dynamic Class Loading
• La carga de clases en Java es de manera
dinámica y lazy
• Separa clases confiables de las no confiables
82
78. Dynamic Class Loading
• La carga de clases en Java es de manera
dinámica y lazy
• Separa clases confiables de las no confiables
• La identidad de una clase está dada por su
full-qualified name más su defining class
loader
83
79. Dynamic Class Loading
• Objetivos
– Asignación de Protection Domains
– Separación de Namespaces
– …Entre otros
84
80. Asignación de Protection Domains
• Cada class loader asigna un protection
domain a las clases que define
85
81. Asignación de Protection Domains
• Cada class loader asigna un protection
domain a las clases que define
• Un protection domain encapsula los permisos
asignados a las clases del dominio
86
82. Asignación de Protection Domains
• Por lo tanto, un aspecto también tendrá un
protection domain asignado
87
83. Asignación de Protection Domains
• Por lo tanto, un aspecto también tendrá un
protection domain asignado
• Al usar inlining, un aspecto puede “compilar”
un advice dentro de una clase confiable
88
84. Asignación de Protection Domains
• Por lo tanto, un aspecto también tendrá un
protection domain asignado
• Al usar inlining, un aspecto puede “compilar”
un advice dentro de una clase confiable
• Por lo que el protection domain del aspecto
no se conserva en algunos casos
89
86. Separación de namespaces
• Los aspectos también pueden quebrar este
principio por medio del inlining
• Al resolver una clase, un advice puede usar el
defining class-loader del join point shadow en
vez del class-loader que define al aspecto
91
87. Evaluación de AspectJ
Defining class loader
la : aspecto
lb : tipo dinámico del llamador
lc : tipo estático del llamado
ld : tipo dinámico del llamado
Permite el weaving de un
advice
No permite el weaving de
un advice
92
88. Evaluación de AspectJ
• lb ≤ lc y lc ≥ ld (por restricciones de JVM)
• Si la es ancestro de lb lc ld entonces es posible
hacer un advice (lo cual no es deseable)
• Hacer un advice a partir de b requiere la ≥ lb
• Caso especial cuando la < o ≠ lb , la < lc, la ≥ ld
asdf - 93
89. Observación
• Load-time weaving de AspectJ usa su propio
class-loader, lo que impide tener separación
de namespaces efectiva
• Sin embargo, AspectJ ofrece otras formas de
weaving en compile o post-compile time
94
91. Conclusiones
• AOSD permite una buena separación de intereses
en cuanto a Seguridad
• Sin embargo, es un arma de doble filo
• La inserción de untrusted aspects requiere una
arquitectura más elaborada
• Aun así, AspectJ por ejemplo, no está 100%
integrado al modelo de clases de Java
96