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

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

4
Example SAL Code

• / Macros /
• MethodCall(name) op "invokevirtual"
  param1 name
• FileRead()
• MethodCall("java/io/FileInputStream/read()I")
• Send()
• MethodCall("java/net/SocketOutputStream/write(I)
  V")
• / No Sends after Reads /
• start !FileRead() -gt start FileRead() -gt
• r !Send() -gt r

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)

6
2nd System PoET/PSlang

• PSlang predicate gt 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

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

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-implemen
  tation-details gap.
• Caveats
• need SFI as a baseline to protect IRM
• type safety helps a lot here

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" gt
  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?)