aspectos y seguridad
TRANSCRIPT
Aspectos y Seguridad
CC71P – Objetos y Aspectos
Mauricio Quezada
11/11/10
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
CONTROL DE ACCESO + ASPECTOS1 - Motivación
3
Seguridad y Software
• La seguridad debe ser un hecho durante todas las fases del desarrollo
Motivación - 4
Seguridad y Software
• La seguridad debe ser un hecho durante todas las fases del desarrollo
• Es un cross-cutting concern
Motivación - 5
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
Control de Acceso (AC)
Motivación - 7
Autenticación Autorización
AC con Aspectos
• Identification
– Asignar una identidad a los clientes
Motivación - 8
AC con Aspectos
• Identification
– Asignar una identidad a los clientes
• Authentication
– Afirmar que alguien es quien dice ser
Motivación - 9
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
AC con Aspectos
• Asumiremos una clase Server que implementa service de la interfaz ServerInterface
Motivación - 11
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
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
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
Authentication
...
pointcut authenticationCall(Object caller):
this(caller) &&
serviceRequest() &&
if(Identification.hasAspect(caller));
public Subject getSubject() {
return subject;
}
...
Motivación - 15
Authentication
before(Object caller): authenticationCall(caller) {
Identification id = Identification.aspectOf(caller);
if(id.subject == null) {
<login>
subject = id.subject;
}
}
}
Motivación - 16
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
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
Otras consideraciones
• Generalizar el ejemplo utilizando aspectos abstractos
Motivación - 19
Otras consideraciones
• Generalizar el ejemplo utilizando aspectos abstractos
• Extender los requerimientos:
– Confidencialidad
– Integridad
– No Repudiabilidad
– …etc.
Motivación - 23
Seguridad y AOP
1. Código más mantenible
Motivación - 24
Seguridad y AOP
1. Código más mantenible
2. Separación de responsabilidades (especialización)
Motivación - 25
Seguridad y AOP
1. Código más mantenible
2. Separación de responsabilidades (especialización)
3. Las interacciones framework-applicationestán bien definidas
Motivación - 26
Ejemplo (1)
void around():
execution(String Encrypter.getPrivateKey())
{
if(!Policy.isAllowed( ... ))
throw new RuntimeException(“Denied!”);
else
proceed();
}
27
Ejemplo (2)
privileged aspect Sniffing {
after(Encrypter e):
set(private String Encrypter.privateKey)
&& this(e)
{
System.out.println(“The key is ” + e.privateKey);
}
}
28
HACIA UN SISTEMA DE PERMISOS2 – Aspectos y Seguridad
29
Identificando el problema
• Usar aspectos para mejorar la seguridad puede ser un arma de doble filo
Aspectos y Seguridad - 30
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
1. Invocation Interception
• Parameter Alteration / Invocation hijacking
pointcut polcheck():
execution(boolean Policy.isAllowed(..));
boolean around(): polcheck() {
boolean res = proceed();
return true;
}
32
1. Invocation Interception
• Parameter Alteration / Invocation hijacking
pointcut polcheck():
execution(boolean Policy.isAllowed(..));
boolean around(): polcheck() {
boolean res = proceed();
return true;
}
33
2. Privileged aspects
• Altera propiedades de encapsulación de Java
34
2. Privileged aspects
• Altera propiedades de encapsulación de Java
• ¿Son necesarios los aspectos privileged?
35
Problemas
• Advices, inter-type declarations pueden alterar el estado de un objeto
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
37
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
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
Soluciones propuestas
• Invocation Interception
– Uso de declare precedence
40
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
Soluciones propuestas
• Privileged Aspects
– Eliminarlos por completo
42
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
Soluciones propuestas
• Modificar o extender el lenguaje de aspectos
– Por ejemplo, describir qué partes pueden ser accedidas por cierto módulo
44
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
An Aspect Permission System
• Funcionamiento en tiempo de ejecución (load-time o run-time)
46
An Aspect Permission System
• Funcionamiento en tiempo de ejecución (load-time o run-time)
• Inserción de chequeos de seguridad (weaving)
47
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
HISTORY-BASED ACCESS CONTROL3 – Un sistema de permisos con AOP
49
History-based vs Stack-basedinspection
• Los aspectos son “compilados” (woven) a bytecode
50
History-based vs Stack-basedinspection
• Los aspectos son “compilados” (woven) a bytecode
=> Los advices no dejan trazas en el stack
51
History-based vs Stack-basedinspection
• 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
Contexto y Caso de estudio
55
• jFTPd
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
1) Weaver-based
• Implementación:
– Sólo afecta al weaver de aspectos
– La JVM no sufre modificaciones
– Basado en anotaciones
57
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
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
1) Weaver-based
class Secret {
@CheckAOPPermission(
permission=“SecretPermission”
)
private String secret;
...
}
60
2) History-based
• Permisos actuales dependen de todos los permisos anteriores
61
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
2) History-based
• En load-time (o compile-time) se asignan los SR de cada aspecto
63
2) History-based
• En load-time (o compile-time) se asignan los SR de cada aspecto
• Centrado en la clase PermissionManager
64
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
History-based Access Control
66
67
Ejemplo
PermissionManager mngr =
PermissionManager.getPermissionManager();
AOPPermission perm =
new SensitiveOpPermission();
mngr.demand(perm);
<sensitive operation>
68
Ejemplo
PermissionManager mngr =
PermissionManager.getPermissionManager();
AOPPermission perm =
new SensitiveOpPermission();
mngr.demand(perm);
<sensitive operation>
69
Ejemplo
PermissionManager mngr =
PermissionManager.getPermissionManager();
AOPPermission perm =
new SensitiveOpPermission();
mngr.demand(perm);
<sensitive operation>
70
Ejemplo
PermissionManager mngr =
PermissionManager.getPermissionManager();
AOPPermission perm =
new SensitiveOpPermission();
mngr.demand(perm);
<sensitive operation>
71
Ejemplo
PermissionManager mngr =
PermissionManager.getPermissionManager();
AOPPermission perm =
new SensitiveOpPermission();
mngr.demand(perm);
<sensitive operation>
72
Implicit Modifications
// advice before weaving
before(): ... { <something useful> }
// advice after weaving
before(): ... {
PermissionManager mngr = PM.getPM();
mngr.updateCurrent(<full aspect name>);
<something useful>
}
73
Explicit Modifications
• grant(Permission) { <block> }
– Ejecuta <block> con permisos elevados
• accept(Permission) { <block> }
– Los permisos son elevados si <block> termina normalmente
74
Evaluación del Prototipo
• Modificación del weaver/compiler + librería a run-time (PermissionManager)
• 3 Permisos principales: Config, Auth, CoreLoop
75
Tiempos de Ejecución [seg]
76
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
CLASS-BASED SECURITY4 – AOP y el modelo de seguridad de Java
78
Class-based security
• Al considerar el mecanismo de class-loading, el supuesto de identidad de aspectos ya no es válido
79
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
Dynamic Class Loading
• La carga de clases en Java es de manera dinámica y lazy
81
Dynamic Class Loading
• La carga de clases en Java es de manera dinámica y lazy
• Separa clases confiables de las no confiables
82
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 classloader
83
Dynamic Class Loading
• Objetivos
– Asignación de Protection Domains
– Separación de Namespaces
– …Entre otros
84
Asignación de Protection Domains
• Cada class loader asigna un protectiondomain a las clases que define
85
Asignación de Protection Domains
• Cada class loader asigna un protectiondomain a las clases que define
• Un protection domain encapsula los permisos asignados a las clases del dominio
86
Asignación de Protection Domains
• Por lo tanto, un aspecto también tendrá un protection domain asignado
87
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
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
Separación de namespaces
• Los aspectos también pueden quebrar este principio por medio del inlining
90
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
Evaluación de AspectJ
92
Defining class loader
la : aspectolb : tipo dinámico del llamadorlc : tipo estático del llamadold : tipo dinámico del llamado
Permite el weaving de un advice
No permite el weaving de un advice
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
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
CONCLUSIONES
95
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