Real-time Access Control Reconfiguration By Ashish Gehani and Gershon Kedem Department of Computer Science, Duke University
Introduction • Internet growth ⇒ Increasingly frequent attacks • Heterogenous deployed software ⇒ More exploitable bugs • Anonymity online ⇒ Attacks spread quickly
Motivation • Automate intrusion response • Tighten access control ⇒ Reduce exposure • Dynamically reconfigure ⇒ Minimize mean time to response • Decreases system usability ⇒ Deny only when risk warrants it
Design - User Space Response • Intrusion detector ⇒ Application ⇒ Change permissions • Problems : – Granularity : Exactly which permissions? – Overhead : Frequent reconfiguration – Temporal Gap : Allows race conditions (Time of use < Time of reconfiguration)
Design - OS Support • Instrumented Linux 2.2.12 kernel • Instrumented Sun Java 1.2 runtime • Trapped all calls • Overhead unacceptable • Limited to extant security subsystem • Permissions are predicated • Result : Active Reference Monitor
Design - Security Policy • Specified using: L : Formal language X : Axioms I : Rules of inference Q : Proof technique • Can verify statement σ ∈ L – Start with X , use I according to Q , derive σ • In principle, can specificy and verify • Problems in practice : – Complex for “real” system – Part of system outside administrative domain – Gap between abstraction and implementation
Design - Permission Semantics • Focus on subset of security policy • Authorization policy : σ → p (ermission) • Given : i ∈ S(ubjects), j ∈ O(bjects), k ∈ A(uthorization types) • Instead of p(i,j,k) = 0 or p(i,j,k) = 1, Use p(i,j,k) = σ
Design - Temporal Constraints • Applications do not expect: – Variable length permission checks – Access control configuration changes • Q bounded to constant t steps ⇒ Choice of L not material • Permission check time : O(t) = O(1) • Permission denial ⇒ Signal with buffer b • Signal handler can get (p, σ ) from b
Design - Activation • Select based on benefit and cost • Cost is frequency in workload • Interface : enableSafeguard(Permission p) disableSafeguard(Permission p)
Implementation - Interposition
Implementation - Invocation public abstract class PredicateThread extends Thread{ protected PredicateThread(Permission permission, Object lock); public void run(){ if( condition ) result=true; synchronized(lock){ lock.notify(); } } public boolean getResult(); }
Evaluation - Primitive times Access Type Time getSystemLoad() 0.34 ms getTransmitted(eth0) 1.02 ms getReceived(eth0) 1.01 ms getFreeSwap() 0.39 ms getFreeRAM() 0.39 ms
Evaluation - Worst Case Impact
Related Work • Active Capabilities, FLASK, RS-BAC … • Differences : – Constant running time guarantee – Expose denial semantics programmatically ⇒ Allow application adaptation – Activation based on cost and benefit – Predicates activatable at permission granularity ⇒ Minimizes impact
Conclusion • Argued for predicated permissions • Used temporal constraints • Described changes in semantics • Showed programmatic access • Dynamic reconfigurability ⇒ Needed for real-time response • Demonstrated acceptable performance
Recommend
More recommend