1 / 9

Enhancing Security through Inlined Reference Monitors and Declarative Policy Specification

This paper discusses the implementation of Inlined Reference Monitors (IRMs) that generalize Software Fault Isolation (SFI) by allowing policies to be specified in declarative languages. It evaluates various approaches to policy specification, including finite-state automata and aspect-oriented programming, while emphasizing the importance of memory and jump safety to maintain code integrity. The study compares multiple systems, such as SASI and Naccio, and addresses the complexities of resource mapping and policy composition. Key insights into policy expression and performance implications are also highlighted.

rooney-chaney
Télécharger la présentation

Enhancing Security through Inlined Reference Monitors and Declarative Policy Specification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS711: Inlined Reference Monitors Greg Morrisett Cornell University

  2. IRM = Inlined Ref. Monitor • Generalizes SFI • specify policy in some declarative lang. • finite-state automata (bad idea) • if code matches predicate => insert action • aspect-oriented programming? • rewrite the interpreter for the lang. and use partial evaluation as suggested last time? • "weave" the policy into the code • must ensure SFI memory/jump safety to protect the integrity of the code • TCB issues – don't want this to be complicated Lang. Based Security

  3. 1st System: SASI • specified policy using finite-state autom. • rewriter for x86 code • rewriter for JVM code • compared against: • misfit SFI implementation • original Java sandbox implementation (not stack inspection). Lang. Based Security

  4. Example SAL Code /* Macros */ MethodCall(name) ::= op == "invokevirtual" && param[1] == name FileRead() ::= MethodCall("java/io/FileInputStream/read()I"); Send() ::= MethodCall("java/net/SocketOutputStream/write(I)V") /* No Sends after Reads */ start ::= !FileRead() -> start | FileRead() -> r ::= !Send() -> r Lang. Based Security

  5. Notes (Last Section of Paper) • Finite-state automata are a lousy programming language. • end up encoding state in an awkward way • just add variables (instance?) • Predicates for "events" are really dictated by lang. • x86: insts & operands – must synthesize things like a "function call" • JVML: insts & operands & types & class info & ... • the added structure of the JVML makes it easier to express certain policies (no need to synthesize events) • but doing things at the x86 level is convenient (e.g., native methods) • Performance was reasonable relative to specialized implementations (e.g., Misfit) Lang. Based Security

  6. 2nd System: PoET/PSlang • PSlang: predicate => insert code • could insert state, predicates and inserted code could be arbitrary Java. • Policy was stack inspection • naive way: using security-passing style • fancier way: using reflection hack Lang. Based Security

  7. 3rd System: Naccio • Specify platform independent resources • e.g., network, windows, space, time • give mapping down to implementation • (e.g., network: all those Win32 calls that send messages.) • Specify policies in terms of resources • an expert has hunted down all the API calls that you need to wrap • IRM away... Lang. Based Security

  8. Stepping Back • Really good features of IRMs: • 3rd party specifies policy in a declarative language • policies compose (e.g., SFI + Stack Insp.) • higher-level abstractions (resources) can help bridge the high-level-policy-to-low-level-implementation-details gap. • Caveats: • need SFI as a baseline to protect IRM • type safety helps a lot here Lang. Based Security

  9. Caveats contd. • What should the pattern language look like for describing policies? • need to be able to synthesize events if IRM'ing a low-level language. • aspect-oriented programming? • pattern language and inserted code "pure" => easier time partially evaluating it away, but restricts or makes awkward the policies. • given a policy, can we (statically) tell a developer whether or not their code will fail? (or at least warn them?) Lang. Based Security

More Related