Incremental Analysis of Interference Among Aspects Interference Among Aspects Authors: Emilia Katz, Shmuel Katz Th T The Technion h i 1
Motivation • Multiple aspects are often woven into the same p p system => Unintended interactions among the aspects may occur, even if each aspect is “correct” when woven i h i h alone • Libraries of reusable aspects (example: a library • Libraries of reusable aspects (example: a library implementing the ACID properties for transactional objects) => Usage guidelines for the participating aspects are needed 2
New Interference Type Previously defined interference types: Interference caused by Interference caused by - • Common join-points example example – • Updating shared variables U d i h d i bl soon! • Changing join-points ⇒ Not enough! ⇒ More general definition is needed! Interference caused by the semantics of the aspects! 3
What is a Aspect Specifications prior “correct” … because model- b work k d l aspect? checking is used in Pair of LTL formulas proof method p Specification of aspect A is (P A , R A ) automatization … The principle: assume – guarantee (generalized) A assumes: P A holds in the base system in any reasonable base system for A – what’s true at joinpoints unusual! – global properties of base system in any woven – properties of aspect parameters system with A A guarantees: R A is true in the woven system R i t i th t A t – new properties added by A possibly global ! – properties of base system maintained in woven system properties of base system maintained in woven system 4
Semantic Interference Among g Aspects pairwise definition; pairwise definition; will be generalized to N aspects… One aspect “causes” another to not give the desired result (violate its guarantee): • Aspect A satisfies its specification (P A , R A ) • Aspect B satisfies its specification (P B , R B ) p p ( B , B ) • Base system satisfies both P A and P B 5
From now on: assume all the Aspect Interference Aspect Interference aspects are “correct” A B A, B – aspects; S – underlying system aspects; S underlying system (S + A) +B � WRONG � WRONG (S A) S + A � OK OR (S + B) +A � WRONG S + B � OK S + B � OK OR OR S + (A,B) � WRONG This (“joint”) weaving 6 will be discussed later
Interference Example p General description: • Two aspects – part of a security-aspects library, to Two aspects part of a security aspects library, to be used in password-protected systems • Aspect E encrypts passwords Whenever a password is sent from the login screen of the system, it is encrypted (there is also a decryption part, but we ignore it here) yp p , g ) • Aspect F for retrieving forgotten passwords Adds a button to report that the password is f forgotten. When the button is pressed, security tt Wh th b tt i d it questions are asked. If the answers are correct, the password is sent to the user. 7
Example Usage: Internet Access to Bank Accounts Underlying system: Underlying system: send (login, password) Internet Internet Server terminal grant_access (info) 8
Adding Password Encryption Adding Password Encryption Aspect E, responsible for encryption. E’s pointcut: a password is sent from login screen E’s assumption, P E : password-containing messages are sent only from login screen messages are sent only from login screen E’s guarantee, R E : each time a password is sent it is encrypted sent, it is encrypted 9
Later addition: aspect F Aspect F, retrieving forgotten passwords: F’s pointcut: “forgot_password” button is pressed p F’s assumption, P F : true (no assumption needed) needed) F’s guarantee, R F : each time a password is forgotten it’s e mailed to the user provided forgotten, it s e-mailed to the user, provided the security questions are answered 10
Example – contd.(3) p ( ) Unencrypted!!! ( S+E)+F: F send (login, d (l i “forgot_psw.” encr(password) ) e-mail psw. pressed Internet Server terminal terminal grant_access (info) 11
Cause of the problem • Common join-points? – No. • Updating shared variables? • Updating shared variables? – No. No • Changing join-points? – Not as written. • The semantics of E and F? – Yes! Th ti f E d F? Y ! 1. The presence of F (resulting in e-mailed passwords) violates the guarantee of E (all passwords encrypted) violates the guarantee of E (all passwords encrypted) � F cannot be woven after E. 2 The presence of F (e mailed passwords) violates the 2. The presence of F (e-mailed passwords) violates the assumption of E (passwords sent from Login Screen only) � E cannot be woven after F y) 12
Semantic Interference – more formally Semantic Interference – more formally We assume both A – aspect specified by (P A , R A ) A aspect, specified by (P A , R A ) aspects are correct aspects are correct B – aspect, specified by (P B , R B ) Definition: A does not interfere with B if for every system S system S, = ∧ → + + = ∧ (*) ( | ) (( ) | ) S P P S A B R R A B A B both assumptions both guarantees hold hold (*) Notation: OK (*) Notation: OK AB 13
Non-Interference in a Library • Generalization of the definition to a library of N aspects: The aspect library is interference free if for every subset of the aspects, when they are woven into a system f h h h i that satisfies all their assumptions, the resulting system satisfies all the guarantees system satisfies all the guarantees • We detect interference or prove interference freedom • We detect interference or prove interference-freedom using model-checking, where advice is modeled as state-transition system state transition system 14
Proving Non-Interference g • Need to prove: OK AB and OK BA • Intuitive method: Direct proof. • For every system S satisfying P A ∧ P B , For every system S satisfying P A ∧ P B , show that ((S+A)+B) and ((S+B)+A) satisfy R A ∧ R B • But: What about N aspects in a library? But: What about N aspects in a library? • Pairwise checks are not enough! Need to prove for every subset of aspects separately! Need to prove for every subset of aspects separately! (for all the subsets of 2,3,…N aspects) 15
Incremental Non-Interference Proof A keeps the Theorem (dividing the proof task): Theorem (dividing the proof task): assumption assumption of B To prove OK AB , it’s enough to show ∀ ∀ = ∧ → → + + = (( | (( | ) ) ( ( | | )) )) [ KP AB ] [ KP ] S S S S P P P P S S A A P P A B B And ∀ = ∧ → + = (( | ) ( | )) [ KR AB ] S S R P S B R A B A B keeps the guarantee of A 16
The Incremental Method Generalizes to N G li • If N aspects pairwise satisfy KP and KR in both directions, for any combination of m ≤ N aspects from that set, there is no semantic interference. • Each one preserves the assumption and guarantee of all the others, so no matter how many are f ll h h h applied, all guarantees will hold if all assumptions held in the base held in the base • The above generalization does NOT hold for the Direct method Direct method. example – soon! 17
Adding an Aspect to a Library new aspect t library of aspects A A1, A2, … An P A , A’s assume- R A guarantee ? ? “offline specification A A1 P A , R A P A1 , R A1 ? ” A2 … P A2 , R A2 checks! checks! <A, Ai> ; <Ai, A> - refinement refinement ? ? … … pairwise interference An checks, based on P An , R An model-checking <A, Ai> or <Ai, A> A, Ai or Ai, A all checks succeeded check failed extended library unavoidable A, A1, A2, … An counterexample interference (A added) usage guidelines: error analysis extended interference free interference free guidelines guidelines (i (including A) l di A) subsets; permissible weaving orders 18
Non-generalization of Direct: Example • Aspect A: Encrypts “secret” data sent in the system – In the bank system, encrypts passwords sent from login screen • Aspect B: Adds a possibility to “remember” the password of the user password of the user – Adds a private variable “password” to the User class, and stores the password there if needed. • Aspect C: “Publishes” data of specified non-secret objects [objects with no “secret” fields] – sends all the object data (including private fields) upon request object data (including private fields) upon request. – In the bank system – sends user data. 19
Aspect Specifications: • Aspect A: – Assumes the password are the only type of secret data, and ssu es t e passwo d a e t e o y type o sec et data, a d the passwords are sent only from the login screen – Guarantees all the secret data is sent encrypted • Aspect B: A t B – Assumes nothing (adds the “save_password” button itself) – Guarantees the password is stored in the user data if it was Guarantees the password is stored in the user data if it was requested • Aspect C: – Assumes user objects store no secret data – Guarantees all stored user data is sent 20
Recommend
More recommend
