Composing Security Policies with Polymer

  • View

  • Download

Embed Size (px)


Composing Security Policies with Polymer. Jay Ligatti (Princeton); joint work with: Lujo Bauer (CMU), David Walker (Princeton). Security Policy Enforcement. News flash: Software sometimes does bad stuff Bugs Malicious design One mitigation is run-time monitoring - PowerPoint PPT Presentation

Text of Composing Security Policies with Polymer

  • Composing Security Policies with PolymerJay Ligatti (Princeton); joint work with:Lujo Bauer (CMU), David Walker (Princeton)

  • Security Policy EnforcementNews flash: Software sometimes does bad stuffBugsMalicious designOne mitigation is run-time monitoringEnsure that software adheres to run-time constraints specified by a security policyStack inspection, access control lists, applet sandboxing, firewalls, resource monitors,

  • Policies Become More ComplexAs software becomes more sophisticatedMulti-user and networked systemsElectronic commerceMedical databases (HIPAA)As we tighten overly relaxed policiesInsecure default configurations disallowedDownloading .doc files requires warningAs we relax overly tight policiesAll applets sandboxed (JDK 1.0) vs. only unsigned applets sandboxed (JDK 1.1)

  • Managing Complexity via CentralizationApplication with policy scattered throughoutScattered policy is hard to find and reason aboutApplication with centralized policyCentralized policy is easier to find and reason aboutPolicy contains: - Security code - When to run the security code

  • Beyond Centralization: CompositionPolicy centralization is not enoughNeed methodology for organizing a complex centralized policyPolymer provides a flexible methodology for decomposing complex policies into simpler modulesPolicies are first-class and organized for compositionHigher-order policies (superpolicies) can compose simpler policies (subpolicies)

  • Related WorkGeneral monitoring systems (with centralized policies)Java-MaC [Lee, Kannan, Kim, Sokolsky, Viswanathan 99]Naccio [Evans, Twyman 99]Policy Enforcement Toolkit [Erlingsson, Schneider 00]Aspect-oriented software systems [Kiczales, Hilsdale, Hugunin, Kersten, Palm, Griswold 01; ]Language theorySemantics for AOPLs [Tucker, Krishnamurthi 03; Walker, Zdancewic, Ligatti 03; Wand, Kiczales, Dutchyn 04; ]Automata theorySecurity automata [Schneider 00; Ligatti, Bauer, Walker 05]

  • OutlineMotivation and goalEase specification of run-time policiesPolymer systemPolymer languageFirst-class actions, suggestions, policiesPolicy examplesCase studySummary

  • Polymer ToolsPolicy compiler Converts monitor policies written in the Polymer language into Java source codeThen runs javac to compile the Java sourceBytecode instrumenterAdds calls to the monitor to the core Java libraries and to the untrusted (target) applicationTotal size = 30 core classes (approx. 2500 lines of Java) + JavaCC + Apache BCEL

  • Securing Targets in PolymerCreate a listing of all security-relevant methods (trigger actions)Instrument trigger actions in core Java librariesWrite and compile security policyRun target using instrumented libraries, instrumenting target classes as they load

  • Securing Targets in PolymerTargetLibrariesOriginal applicationInstrumented targetInstrumentedlibrariesCompiled policySecured application

  • OutlineMotivation and goalEase specification of run-time policiesPolymer systemPolymer languageFirst-class actions, suggestions, policiesPolicy examplesCase studySummary

  • First-class Actions

    Action objects contain information about a method invocationStatic method signatureDynamic calling object Dynamic parametersPolicies can analyze actions about to be executed by the targetPolicies can synthesize actions to invoke on behalf of the target

  • Action PatternsAction objects can be matched to patterns in aswitch statements

    Wildcards can appear in action patterns

    aswitch(a) { case : E; }

  • First-class SuggestionsPolicies return Suggestion objects to indicate how to handle trigger actionsIrrSug: action is irrelevantOKSug: action is relevant but safeInsSug: defer judgment until after running and evaluating some auxiliary codeReplSug: replace action (which computes a return value) with another return valueExnSug: raise an exception to notify target that it is not allowed to execute this actionHaltSug: disallow action and halt execution

  • First-class PoliciesPolicies include state and several methods:query() suggests how to deal with trigger actionsaccept() performs bookkeeping before a suggestion is followedresult() performs bookkeeping after an OKd or inserted action returns a resultpublic abstract class Policy { public abstract Sug query(Action a); public void accept(Sug s) { }; public void result(Sug s, Object result, boolean wasExnThn) { };}

  • Compositional Policy Designquery() methods should be effect-freeSuperpolicies test reactions of subpolicies by calling their query() methodsSuperpolicies combine reactions in meaningful waysPolicies cannot assume suggestions will be followedEffects postponed for accept() and result()

  • A Simple Policy That Forbids Runtime.exec(..) methodspublic class DisSysCalls extends Policy { public Sug query(Action a) { aswitch(a) { case : return new HaltSug(this, a); } return new IrrSug(this); } public void accept(Sug s) { if(s.isHalt()) { System.err.println(Illegal exec method called); System.err.println(About to halt target.); } }}

  • Policy CombinatorsPolymer provides library of generic superpolicies (combinators)Policy writers are free to create new combinatorsStandard form:public class Conjunction extends Policy { private Policy p1, p2; public Conjunction(Policy p1, Policy p2) { this.p1 = p1; this.p2 = p2; } public Sug query(Action a) { Sug s1 = p1.query(a), s2 = p2.query(a); //return the conjunction of s1 and s2

  • Policy Combinator I: ConjunctionApply several policies at once, first making any insertions suggested by subpoliciesWhen no subpolicy suggests an insertion, obey most restrictive subpolicy suggestion

    IrrelevantOKReplace(v1)Replace(v2)Replace(v3)ExceptionHaltLeast restrictiveMost restrictive

  • Policy Combinator II: SelectorMake some initial choice about which subpolicy to enforce and forget about the other subpoliciesIsClientSigned: Enforce first subpolicy if and only if target is cryptographically signed Policy sandboxUnsigned = new IsClientSigned( new TrivialPolicy(), new SandboxPolicy());

  • Policy Combinator III: PrecedenceGive one subpolicy precedence over anotherDominates: Obey first subpolicy if it considers the action relevant; otherwise obey whatever second subpolicy suggestsTryWith: Obey first subpolicy if and only if it returns an Irrelevant, OK, or Insertion suggestion

  • Policy Combinator IV: Single-policy ModifierPerform some extra operations while enforcing a single subpolicyAudit: Obey sole subpolicy but also log all actions seen and suggestions madeAutoUpdate: Obey sole subpolicy but also intermittently check for subpolicy updates

  • OutlineMotivation and goalEase specification of run-time policiesPolymer systemPolymer languageFirst-class actions, suggestions, policiesPolicy examplesCase studySummary

  • Case StudyPolymer policy for email clients that use the JavaMail APIApprox. 1800 lines of Polymer codeTested on Pooka []Approx. 50K lines of Java code + libraries (Java standard libraries, JavaMail, JavaBeans Activation Framework, JavaHelp, The Knife mbox provider, Kunststoff Look and Feel, and ICE JNI library)

  • Email Policy HierarchyRelated policy concerns are modularizedEasier to create the policyModules are reusableModules can be written in isolationEasier to understand the policy

  • OutlineMotivation and goalEase specification of run-time policiesPolymer systemPolymer languageFirst-class actions, suggestions, policiesPolicy examplesCase studySummary

  • SummaryA new approach to managing policy complexity:Design policies for compositionComplex policies can be decomposed into simpler subpoliciesEnabling the approachFirst-class actions, suggestions, and policiesPolicy organization (effectless query methods and effectful bookkeeping methods)Implemented end-to-end systemLibrary of useful combinatorsCase study policy hierarchy

  • More InformationLanguage and system details, including a sound formal semantics for the language: PLDI 05 proceedings

    Full source code and example policies:

  • EndThanks / Questions

  • (Unoptimized) PerformanceInstrument all Java core libraries = 107s = 3.7 ms per methodTypical class loading time = 12 ms (vs. 6 ms with default class loader) Monitored method call = 0.6 ms overheadPolicy codes performance typically dominates cost

  • Another Example(logs incoming email and prepends SPAM: to subject lines on messages flagged by a spam filter)