real time access control reconfiguration
play

Real-time Access Control Reconfiguration By Ashish Gehani and - PowerPoint PPT Presentation

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


  1. Real-time Access Control Reconfiguration By Ashish Gehani and Gershon Kedem Department of Computer Science, Duke University

  2. Introduction • Internet growth ⇒ Increasingly frequent attacks • Heterogenous deployed software ⇒ More exploitable bugs • Anonymity online ⇒ Attacks spread quickly

  3. 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

  4. 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)

  5. 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

  6. 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

  7. 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) = σ

  8. 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

  9. Design - Activation • Select based on benefit and cost • Cost is frequency in workload • Interface : enableSafeguard(Permission p) disableSafeguard(Permission p)

  10. Implementation - Interposition

  11. 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(); }

  12. 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

  13. Evaluation - Worst Case Impact

  14. 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

  15. 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