CS711: Inlined Reference Monitors

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