Presentation on theme: "Security through AOSD may harm… Discussion report."— Presentation transcript:
Security through AOSD may harm… Discussion report
AOSD composition and security How can we know whether a composition (Base + securityA + otherA) is acceptable: Really effectively delivering the expected security Not harming the base application?
Can I express order… Limit the specification of orders…. Is this a new problem? –Cfr. Mixin based inheritance
Knowing the exact meaning of composition waaaaw
Opening (unintended) covered channels Prevent leakage Example: sharing information between authentication and authorization module…
Our focus… Intended attacks: not our focus now Unintentional attacks. –Because of aspect interference… –Security solution Probably multiple aspects, to be composed Can this be a (sort of) sand-box?
Headlines of what we need… 1. Principle of least privilige –State what privilige any aspect would have on a given aspect –Then explicitly allow more privilige To certain classes, or instances 2. Order of composition –E.g. Log before decrypt… 3. Aspects sharing state (communicate) –Do not allow leaking/interception.
Adoption Evolution of the applications: –If I compose the new version of the application with the security aspect: –Who confirms that the result is right? Is it worse then what we are used to (without aspects)? Lots of psycho?
Side-track Business rules in aspects?
Core problem Declarative semantics for composition Compiler support.