Aspectos y seguridad

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



• Es un cross-cutting concern

Motivación - 5



• 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


• Authentication

– Afirmar que alguien es quien dice ser

Motivación - 9

AC con Aspectos

• Identification


• 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




}





...

Motivación - 13




}





...

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


2. Separación de responsabilidades (especialización)

Motivación - 25

Seguridad y AOP


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


• Parameter Alteration / Invocation hijacking

pointcut polcheck():

execution(boolean Policy.isAllowed(..));

boolean around(): polcheck() {

boolean res = proceed();

return true;

}

32


• 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


• La interacción de dos o más módulos puede ser influenciada

37

Problemas



• Un programa “seguro” sin aspectos no lo es necesariamente con aspectos.

38

Problemas



• Un programa “seguro” sin aspectos no lo es necesariamente con aspectos.

• …intencional o accidentalmente

39

Soluciones propuestas

• Invocation Interception

– Uso de declare precedence

40


• 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


• Privileged Aspects

– Eliminarlos por completo

42


• Privileged Aspects

– Eliminarlos por completo


– Adaptar un módulo no diseñado para ser “seguro”

– Una política puede depender del estado interno de un módulo

43


• Modificar o extender el lenguaje de aspectos

– Por ejemplo, describir qué partes pueden ser accedidas por cierto módulo

44


• Modificar o extender el lenguaje de aspectos

– Por ejemplo, describir qué partes pueden ser accedidas por cierto módulo


– 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



• Inserción de chequeos de seguridad (weaving)

47



• 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



=> Los advices no dejan trazas en el stack

51



=> 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





• Independiente de la estrategia y del momento del weaving

58

1) Weaver-based





• 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


• Centrado en la clase PermissionManager

64

2) History-based


• 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





mngr.demand(perm);


69

Ejemplo





mngr.demand(perm);


70

Ejemplo





mngr.demand(perm);


71

Ejemplo





mngr.demand(perm);


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



• Separa clases confiables de las no confiables

82



• 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


• 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


• Cada class loader asigna un protectiondomain a las clases que define

• Un protection domain encapsula los permisos asignados a las clases del dominio

86


• Por lo tanto, un aspecto también tendrá un protection domain asignado

87



• Al usar inlining, un aspecto puede “compilar” un advice dentro de una clase confiable

88



• 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

Documents

Aspectos y seguridad