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

1.02 ms getTransmitted(eth0) 0.39 ms getFreeRAM() 0.39 ms getFreeSwap() 1.01 ms getReceived(eth0) 0.34 ms getSystemLoad() Time Access Type

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