1. Aspectos y Seguridad
CC71P – Objetos y Aspectos
Mauricio Quezada
11/11/10

2. Agenda
1. Motivación
2. Aspectos y Seguridad
3. Un sistema de permisos con AOP
4. AOP y el modelo de seguridad de Java
5. Conclusiones
2

3. 1 - Motivación
CONTROL DE ACCESO + ASPECTOS
3

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

7. Control de Acceso (AC)
Autenticación Autorización
Motivación - 7

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

12. Identification & Authentication
aspect Identification perthis(this(Client)) {
public Subject subject = null;
}
aspect Authentication percflow(serviceRequest()) {
private Subject subject;
pointcut serviceRequest():
call(* ServerInterface+.service(..));
...
Motivación - 12

13. Identification & Authentication
aspect Identification perthis(this(Client)) {
public Subject subject = null;
}
aspect Authentication percflow(serviceRequest()) {
private Subject subject;
pointcut serviceRequest():
call(* ServerInterface+.service(..));
...
Motivación - 13

14. Identification & Authentication
aspect Identification perthis(this(Client)) {
public Subject subject = null;
}
aspect Authentication percflow(serviceRequest()) {
private Subject subject;
pointcut serviceRequest():
call(* ServerInterface+.service(..));
...
Motivación - 14

15. Authentication
...
pointcut authenticationCall(Object caller):
this(caller) &&
serviceRequest() &&
if(Identification.hasAspect(caller));
public Subject getSubject() {
return subject;
}
...
Motivación - 15

16. Authentication
before(Object caller): authenticationCall(caller) {
Identification id =
Identification.aspectOf(caller);
if(id.subject == null) {
<login>
subject = id.subject;
}
}
}
Motivación - 16

17. Authorization
aspect Authorization {
pointcut checkedMethods():
within(Server) && execution(* service(..));
Object around(): checkedMethods() {
Authentication auth = Authentication.aspectOf();
Subject subject = auth.getSubject();
boolean allowed = <check access control>;
if(allowed) return proceed();
else <access denied>
}
}
Motivación - 17

18. Authorization
aspect Authorization {
pointcut checkedMethods():
within(Server) && execution(* service(..));
Object around(): checkedMethods() {
Authentication auth = Authentication.aspectOf();
Subject subject = auth.getSubject();
boolean allowed = <check access control>;
if(allowed) return proceed();
else <access denied>
}
}
Motivación - 18

19. Otras consideraciones
• Generalizar el ejemplo utilizando aspectos
abstractos
Motivación - 19

20. Otras consideraciones
• Generalizar el ejemplo utilizando aspectos
abstractos
• Extender los requerimientos:
– Confidencialidad
– Integridad
– No Repudiabilidad
– …etc.
Motivación - 23

21. Seguridad y AOP
1. Código más mantenible
Motivación - 24

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

24. Ejemplo (1)
void around():
execution(String Encrypter.getPrivateKey())
{
if(!Policy.isAllowed( ... ))
throw new RuntimeException(“Denied!”);
else
proceed();
}
27

25. Ejemplo (2)
privileged aspect Sniffing {
after(Encrypter e):
set(private String Encrypter.privateKey)
&& this(e)
{
System.out.println(“The key is ”
+ e.privateKey);
}
}
28

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

29. 1. Invocation Interception
• Parameter Alteration / Invocation hijacking
pointcut polcheck():
execution(boolean Policy.isAllowed(..));
boolean around(): polcheck() {
boolean res = proceed();
return true;
}
32

30. 1. Invocation Interception
• Parameter Alteration / Invocation hijacking
pointcut polcheck():
execution(boolean Policy.isAllowed(..));
boolean around(): polcheck() {
boolean res = proceed();
return true;
}
33

31. 2. Privileged aspects
• Altera propiedades de encapsulación de Java
34

32. 2. Privileged aspects
• Altera propiedades de encapsulación de Java
• ¿Son necesarios los aspectos privileged?
35

33. Problemas
• Advices, inter-type declarations pueden
alterar el estado de un objeto
36

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

37. Soluciones propuestas
• Invocation Interception
– Uso de declare precedence
40

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

39. Soluciones propuestas
• Privileged Aspects
– Eliminarlos por completo
42

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

47. History-based vs Stack-based
inspection
• Los aspectos son “compilados” (woven) a
bytecode
50

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

50. Contexto y Caso de estudio
• jFTPd
55

51. History-based Access Control
1) Weaver-based para reforzar los chequeos en
run-time
2) History-based para el modelo de control de
acceso
56

52. 1) Weaver-based
• Implementación:
– Sólo afecta al weaver de aspectos
– La JVM no sufre modificaciones
– Basado en anotaciones
57

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

55. 1) Weaver-based
class Secret {
@CheckAOPPermission(
permission=“SecretPermission”
)
private String secret;
...
}
60

56. 2) History-based
• Permisos actuales dependen de todos los
permisos anteriores
61

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

61. History-based Access Control
66

62. 67

63. Ejemplo
PermissionManager mngr =
PermissionManager.getPermissionManager();
AOPPermission perm =
new SensitiveOpPermission();
mngr.demand(perm);
<sensitive operation>
68

64. Ejemplo
PermissionManager mngr =
PermissionManager.getPermissionManager();
AOPPermission perm =
new SensitiveOpPermission();
mngr.demand(perm);
<sensitive operation>
69

65. Ejemplo
PermissionManager mngr =
PermissionManager.getPermissionManager();
AOPPermission perm =
new SensitiveOpPermission();
mngr.demand(perm);
<sensitive operation>
70

66. Ejemplo
PermissionManager mngr =
PermissionManager.getPermissionManager();
AOPPermission perm =
new SensitiveOpPermission();
mngr.demand(perm);
<sensitive operation>
71

67. Ejemplo
PermissionManager mngr =
PermissionManager.getPermissionManager();
AOPPermission perm =
new SensitiveOpPermission();
mngr.demand(perm);
<sensitive operation>
72

68. Implicit Modifications
// advice before weaving
before(): ... { <something useful> }
// advice after weaving
before(): ... {
PermissionManager mngr = PM.getPM();
mngr.updateCurrent(<full aspect name>);
<something useful>
}
73

69. Explicit Modifications
• grant(Permission) { <block> }
– Ejecuta <block> con permisos elevados
• accept(Permission) { <block> }
– Los permisos son elevados si <block> termina
normalmente
74

70. Evaluación del Prototipo
• Modificación del weaver/compiler + librería a
run-time (PermissionManager)
• 3 Permisos principales: Config, Auth, CoreLoop
75

71. Tiempos de Ejecución [seg]
76

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

76. Dynamic Class Loading
• La carga de clases en Java es de manera
dinámica y lazy
81

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

85. Separación de namespaces
• Los aspectos también pueden quebrar este
principio por medio del inlining
90

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

90. CONCLUSIONES
95

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