CS711: Inlined Reference Monitors

Greg MorrisettCornell University

04/19/23 Lang. Based Security 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

04/19/23 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).

04/19/23 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

04/19/23 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)

04/19/23 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

04/19/23 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...

04/19/23 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

04/19/23 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?)