composition, reuse, and interaction of stateful aspects. by nathanel mori based on the work of...

Composition, reuse, and interaction of Stateful Aspects.

By Nathanel MoriBased on the work of

Douence, Fradet, and Sudholt.

What are we looking for? Aspect technology is far from maturity.

There is much more work to be done in the theoretical field.

One of the main questions that has to be asked is concerned with different kinds of conflicts.

Aspects are not always orthogonal and aspect interaction is a fundamental problem.

What is proposed Stateful Aspects – A completely

independent, generic framework for the formal definition and interaction analysis of aspects.

3 extensions which enable the interaction of aspects in various ways.

The result – A more precise analysis of aspects and an important step towards an efficient technique of composing, reusing and interacting aspects.

The main idea

We need aspects to know as much info about the base program as possible.

The definition of cross-cuts or join-points as single points in the code is incorrect. A history of the execution process has to be kept. Hence Trace-Based Aspects.

Trace-Based Aspects “Trace-Based Aspects” is a model of

aspects which takes into account the history of program execution.

Weaving is achieved using a monitor that modifies program execution.

Trace-Based Aspects create an important tradeoff between expressiveness and property enforcement/analysis.

Necessity of Trace-Based Aspects: Example An access control code for logged-in

users. The aspect would have to know who is

logged-in right now. The programmer would add an extra

insert (or advice) to set a flag in the base program login code.

The aspect must be modified to recognize this flag.

Low reusability level for such an aspect.

Characteristic of Trace-Based Aspects

There are 3 main characteristics to Trace-Based Aspects: Observable Execution Trace Aspect Language Weaving

Observable Execution Trace A monitor observes the execution

and gives semantic meaning to the join-points.

Example: A join-point can be a term like

login(“Bob”). If the code is login(user) for

user=“Bob”, then the monitor should recognize it.

Aspect Language

3 important terms are defined: Crosscuts Inserts Stateful Aspects

A crosscut is a function. When C is given a crosscut definition, it

returns “fail” if it didn’t satisfy it or a substitution in case it did.

Example: If C should detect Bob logging in, C(logout()) = fail, C(login(“Alice”)) = fail. but C(login(“Bob”))=“Bob”. The substitution is

referred to as uid in the future.

Aspect Language: Crosscuts

C : JP { }Subs fail

Aspect Language: Inserts

An Insert is an executable program (or program fragment) with free variables.

The free variables are bound by the output of the crosscut function.

Example: The insert addLog(uid+”logged in”) prints the name of the logged-in user.

Aspect Language: Stateful

Aspects Intuition: C I is an aspect. It states

that when C matches the current join point and yields a substitution , then I is executed (I bound by ).

Examples: isLogin addLog(uid+”logged in”) While (true) {isLogin

addLog(uid+”logged in”)} This enables us to log all sessions.

Weaving Aspects, as we have seen in the past, can

be composed and woven together. The weaver takes a parallel composition

A1||A2||……||An, and tries to apply each of them at each join point of the execution trace, in no specific order.

The weaver can be regarded conceptually as an execution monitor who dynamically selects which code to run.

Weaving

When a basic aspect Ai has been applied and its insert has been executed, Ai evolves into its next state – hence the title “Stateful Aspects”.

Example: while(true) {isLogin addLog(uid+”logged in”) ;

isLogout addLog(uid+”logged out”)}- The semicolon (“;”) denotes a switch of states.

Instantiation

Up until now, we’ve suggested a general framework to describe Trace-Based Aspects. The framework included a monitor, a language, and a weaving concept.

Now all we have to do is define an instantiation to the framework.

Instantiation We will learn about 3 different instantiations

of the framework, as follows: Expressive Aspects and Equational Reasoning. Detection and Resolution of Aspect Interactions. Static Weaving of Safety Properties.

Each instantiation will include: Definition of crosscuts, inserts, and stateful

aspects. Demonstration of expressiveness vs. property

enforcement/analysis.

Expressive Aspects and Equational Reasoning

Definitions: Crosscuts – A crosscut C may be an

arbitrary predicate. Example: isWeakPassword may recognize

a string that is exposed to dictionary attack. We are not concerned with implementations.

Inserts – Defined as simple program fragments, like in the framework.

Expressive Aspects and Equational Reasoning Definitions cont.

Stateful Aspects – A collection of mutually recursive definitions of the form var = A.

Such aspects are based on the following grammar:

; basic aspect; sequence; choice; invocation

::

1 2

1 2

A C I

| A ; A

| A A

| var

n

u


This grammar allows us to compose aspects by sequentialization, deterministic choice, and aspect invocation.

The choice option, , is deterministic. Therefore, it selects A1 automatically unless it is not applicable. In that case, A2 is selected iff it is applicable.

Example:

1 2A An

tryOnce=(C I; void) void

void=isAny ; voidskip

nu

u


Note the great expressivity that the language has. The following example elaborates this further.

Example:

log = (isLogin (uid); log; isLogout )

isLogout

logNestedLogin = isLogin ; log; logNestedLogin

addLog skip

skip

skip

n

u u

u

u


The example demonstrated shows how to detect nested logins (non top-level):

logNestedLogin catches the first login and then relies on log to detect and log pairs of logins and logouts.

What happens if an aspect from a different origin interferes with the operation of these aspects?

Expressive Aspects and Equational Reasoning Problem: Consider the following aspect:

It’s very easy to prove that this aspect along with logNestedLogin are equivalent to a single sequential aspect.

The result is obvious:

initAtFirstLogin =

isLogin ; void()initNetworkInfou

initAndLog =

isLogin ; log; logNestedLogin()initNetworkInfou


Here’s your chance to view it all together:

Composed with:

Gives us:

log = (isLogin (uid); log; isLogout )

isLogout

logNestedLogin = isLogin ; log; logNestedLogin

addLog skip

skip

skip

n

u u

u

u

initAtFirstLogin = isLogin ; void()initNetworkInfou

initAndLog = isLogin ; log; logNestedLogin()initNetworkInfou

Detection and Resolution of Aspect Interactions

By restricting the expressiveness of the language, we can automatically prove aspect properties.

This is the second instantiation proposed for the aspect framework which had been introduced.


Definitions: Crosscuts – A crosscut C may be only a

conjunction, disjunction, or a negation of a term. C is denoted formally in this formula:

where T denotes terms with variables.Example:

and or not1 2 1 2C ::= T | C C | C C | C'

or and notlogin(root, m) (login(u,m) ( login(u, server)))

Fluffy

Note that we have lost some expressiveness by regarding join points as term patterns which make the decidability feasible (as opposed to arbitrary predicates from the previous method).


The above regular expression denotes that root can log into any machine, or that any user can log into any machine excluding the server.

Note that we have lost some expressiveness by regarding join points as term patterns which make the decidability feasible (as opposed to arbitrary predicates from the previous method).

or and notlogin(root, m) (login(u,m) ( login(u, server)))


Definitions: Inserts – As before, simply a program

fragment. Stateful Aspects – The main idea in

this definition of stateful aspects is to restrict them to regular expressions using this grammar:

n1 2

A ::= C I ; A : sequence

| C I ; var : end of sequence

| A A : choice

u

u


Example: The following example demonstrates a security aspect logAccess that logs file accesses (calls to read) from a call to login until a call to logout. (non-nested sessions)

X matches the name of the accessed file.

logAccess = (u,m) ; logRead

logRead = ( ; logAccess)

(read( ) ; logRead)

login

logout()

( )

skip

skip

x addLog xn

u

u

u


Aspect Interactions: As you recall, the parallel weaving of aspects doesn’t tell us anything about the order in which they’ll be executed (A1 || A2 || … || An).

Also, we may not always be as lucky as we were in the previous example with the aspect initAtFirstLogin.

Detection and Resolution of Aspect Interactions Aspect Interactions cont.

Example: Consider the following example –

How does it conflict with this?

( ) ( )read x crypt xcryptRead = ; cryptReadu

logAccess = (u,m) ; logRead

logRead = ( ; logAccess)

(read( ) ; logRead)

login

logout()

( )

skip

skip

x addLog xn

u

u

u

Detection and Resolution of Aspect Interactions Aspect Interactions cont. The algorithm to check aspect

interactions: Similar to that of finite state product

automata. The algorithm eliminates the operator “

|| “ by producing all the possible pairs (conjunctions) of crosscuts.

A crosscut with no solution cannot match any join point and therefore is removed from the aspect.

Detection and Resolution of Aspect Interactions Aspect Interactions cont. In our case, the algorithm produces:

The symbol represents conflicts. I1I2 returns either I1;I2 or I2;I1. Here,

login

( ) ( )

logout()

skip

read x crypt x

skip

logAccess || cryptRead

= (u,m) ; logCrypt

; logAccess || cryptRead

logCrypt = ; logAccess || cryptRead

n

u

u

u

( ) ( ) ( )read x addLog x crypt x ( ) ; logCryptn uu

Detection and Resolution of Aspect Interactions Aspect Interactions cont. Note that spurious conflicts have

been eliminated using the rule:

The analysis does not depend on the program to be woven. This static analysis is enough to prove there is an aspect interaction.

skip skipu u(I ) = ( I) = I

Detection and Resolution of Aspect Interactions Support for Conflict Resolution: Obviously, if no conflicts have been

detected, then the aspect may be composed in parallel without modification.

In case conflicts are detected, then here are a few linguistic suggestions on how to handle this case: Creating an Insert: For a conflict like C(I1I2),

the programmer may create an insert I3, who solves the non-determinism by choosing what to do – a solution which can get pretty tedious.

Solution at aspect level 1: The operator ||seq indicates that whenever a conflict involving I1 and I2 occurs, it should be replaced by I1 ; I2.

Solution at aspect level 2: The operator ||fst replaces (I1I2) with I1 only.


Let’s examine the following examples:

logAccess ||seq cryptRead This would generate plaintext logs for

superusers.

cryptRead ||seq logAccess This would generate encrypted logs for user

accesses.

Static Weaving of Safety Properties The previous restrictions were

unable to detect semantic interactions.

In other words, the code inserted by the aspect may still influence the application of another aspect, without our detecting it.

Therefore, we have to restrict the inserts language as well.

Static Weaving of Safety Properties

Definitions: Crosscuts – As in the previous section. Stateful Aspects – As in the previous

section. Inserts – Are generated by the

following grammar:

skip abortI ::= |

Static Weaving of Safety Properties In other words, these aspects can only

make sure that no “bad things” happen during the execution.

Shortly, these are Safety Properties. The benefits:

Aspects are semantic properties and therefore the impact of weaving processes are clear.

There are no interactions between aspects, which means they can now be composed freely in parallel. (the ultimate goal!)


The downside: Executions have the aspects “watch

from above” and throw an exception when the security policy is violated. However, that “watching from above” costs a terrible amount of run-time.

Static Weaving of Safety Properties Example:

A critical action must have the clearance of the accountant and the manager.

Safe = ;

( ; ; Safe

; Safe)

;

( ;

accountant() skip

manager() skip critical() skip

critical() abort

manager() skip

accountant() skip

n

n

u

u u

u

u

u ; Safe

; Safe)

; Safe

critical() skip

critical() abort

critical() abort

n

n

u

u

u


Let’s examine the equivalent automaton:

a = accountant() m = manager() c = critical()

m

m

c

c

c

c

a

a

Static Weaving of Safety Properties Weaving Phases:

Base Program Annotation. Since the aspect is regarded by the weaver as an automaton, then the weaver’s phase would be to create a “connection” between code lines from the base program and the transition of the automaton. There are various techniques to optimize this process.

Base Program Abstraction. The base program is abstracted into a graph G=(V,E).

V (the nodes) represents program points. E (the edges) represents instructions (events). This phase makes the next 2 phases independent

of a specific programming language.

Static Weaving of Safety Properties Weaving Phases cont.

Instrumentation. This phase transforms the graph in order to rule out forbidden sequences of events. Intuitively, this phase inserts the automaton transitions right before the very code it mimics, hence it creates the effect of checking whether the property is about to be violated.

Optimizations. The instrumented graph is refined in three steps:

Step 1 – Since the automaton defines a property independent of the program, then we need to specialize the automaton with respect to the base program.

Step 2 – Classical automaton minimization could really come in handy here.

Step 3 – Static analysis is performed to eliminate obvious and useless checks.

Static Weaving of Safety Properties Weaving Phases cont.

Concretization. The optimized graph is now translated back into a program. Note that the new program is pretty close to the base program since the graph represented program points and instructions. We just need a global way to fetch, store, and test values – which could easily be done using global variables (to represent the automaton states).


Base Program Aspect

Graph

Instrumented Graph

Instrumented Graph

Program

Annotation&

Abstraction

Instrumentation

Optimization

Concretization

composition, reuse, and interaction of stateful aspects. by nathanel mori based on the work of...

Documents