Usage Automata

Massimo Bartoletti

Dipartimento di Matematica e InformaticaUniversità degli Studi di Cagliari

Usage control• Running programs and services requires using

computational resources• Must be done according to a given usage policy• History-based security:

– histories = sequences of security-relevant events– usage policy = predicate on sets of histories

• We are interested in usage policies that can be enforced by execution monitoring

• This coincides with the class of safety properties– deciding rejection of a history must be done in isolation

of other possible histories, and only depends on the past– any rejected history must be rejected in a finite period

Security Automata(Fred B. Schneider. Enforceable Security Policies, 2000)

• Security automata are a class of Büchi automata that exactly characterizes safety properties.

• A security automaton is defined by:– a countable set I of input symbols,– a countable set Q of states,

– a countable set Q0 ⊆ Q of initial states,– a transition function δ : (Q × I) → 2Q

• Using infinite sets for states and symbols is needed when the policy has to control actions on targets ranging over infinite domains – ex: ∀∀∀∀x,y do not allow write(x) after read(“/home/”,y)

The problem

• Security Automata not good for writing policies over infinite domains (requires infinite paper…)

• Schneider uses Dijkstra’s Guarded Commands to write example policies over infinite domains

• Not clear the relation between GC and SA– are GC more expressive than SA ?– do (general) GC allow for execution monitoring ?– how far are GC statically amenable ?

• I would like to have a formalism that allows for:– (finitely) expressing usage policies over ∞ domains– execution monitoring (but no Turing-equivalent)– static reasoning (a program always respect a policy)

A usage automaton

failq0

read(“/home”,y)

q1

write(x)

x, y are universally quantified variables

Another usage automaton

q1q0

fail

read(x,y)

read(z,y) when z!=x

Chinese Wall: reading an object z is denied after h aving read an object x in the same conflict of interest c lass y

read(oil1, Oil) read(bank1, Bank) read(oil2, Oil) violates

Usage automata

• A usage automaton is defined by:– a finite set of labels α(ρ1,…,ρk), ρ∈ Res U Var– a finite set of states Q (with a start state q0∈Q)– a finite set of (offending) states F⊆Q– a finite set of labelled transitions of the form:

α(ρ1,…,ρk) : gq’q

• A guard g expresses a (equality / inequality) relation between variables and resources.

g ::= true | ρ = ρ’ | not g | g and g

Expressible policies

• Usage automata can express a (strict) subset of the policies expressible through security automata

• Main limitation: guards– can only check equality / inequality between resources– compromise between expressive vs. analyseable

• Although limited, can express interesting policies:– Access control : can access a resource is access right

granted and not later revoked– Isolation : can only read/write the files you have created– SecBB : set of policies for a Secure Bulletin Board– Find more at: jalapa.sourceforge.net

• Semantics can be given by a mapping a usage automaton φ into a security automaton

• We prefer to map φ into a finite set of FSA– a history ηηηη respects φ iff ηηηη is accepted by all the

FSA obtained from all the possible instantiations of the variables of φ into actual resources

– nice specification, but may produce an infinite set of automata with finite states (and infinite edges)

Semantics

α(x)q2q0

α(y) : y ≠ xq1

α(r i)q2

q0

α(r0)

q1

α(r i-1)

α(r i+1)

q2

q2Res = { r 0 , r1 , r2 , … }

• To obtain a finite set of FSA, make the mapping dependent on the ηηηη we are checking

• Instantiate ϕϕϕϕ on:– all the resources contained in ηηηη, and– all the resources mentioned in ϕϕϕϕ, and– a finite set of “unborn” resources #1 … #k

(k is the number of variables of ϕϕϕϕ)

• This is sound w.r.t. “instantiate on all the resources in the universe”

• But, is this suitable for execution monitoring ?

Semantics

Execution monitoring

• To decide if ηηηη respects ϕϕϕϕ, we have to inspect the whole ηηηη (and compute k |res( ηηηη)| instantiations)

• But ηηηη = execution history: will grow unbound• Semantics unsuitable for execution monitoring!• Solution: instead of instantiation, “abstract”

execution of usage automata– configurations : S = { (σσσσ1,Q1), … , (σσσσn,Qn) }

where σ : σ : σ : σ : Var →→→→ Res

S0

η[0]S1 S2 Si+1

η[1] η[i]

Execution monitoring

• History accepted as long as states in Qi1,…,Qi

nof Si are disjoint from the offending states

• Coherent w.r.t. semantics of usage automata• Consumes one event at each step (keeping the

full history no longer required)• Still, configurations may grow large!

– typed variables and resources– use wildcards *, - in usage automata

– lazy instantiation of new σσσσ– garbage collection of disposed resources– factorization of states

Some expressiveness issues

• Polyadic α(r1,…,rn) vs. monadic α(r) events– polyadic can be encoded into monadic

• Different choices for relational operators:– α(¬¬¬¬x), α(x,¬¬¬¬y)

– wildcards α(*,y), α(x,-)

– guards: α(z) when z ≠≠≠≠x

– expressive power not comparable

• Arity of usage automata vs. expressive power– the expressive power increases as the number of

variables increases

Deflating Lemma

• Let φ be a usage automaton with k variables

• If η violates φ, you can “collapse” the resources of η to k resources and still obtain a violation

• Consider e.g. the policy Diff(k) “a program cannot use more than k distinct resources”.

• Diff(k) can be expressed by a UA with k+1 vars.

α(x0)q2q0

α(x1) : x1 ≠ x0q1 q k+1

α(xk) : xk ≠ xk-1 ∧∧∧∧ … ∧∧∧∧ x1 ≠ x0

• By the deflating lemma, Diff(k) not expressible withk’<k+1 variables

Dynamic vs. static enforcement

• Run-time enforcement may be inefficient• Alternative: static enforcement

– only run programs that are guaranteed to obey the policies on demand, for each possible execution

– then, you can safely turn off the run-time monitor

• Static approximation of programs: usages– a sort of behavioural types– inferred through type & effect systems, CFA, …– independent from the actual calculus/language

used for writing programs

Usages

U,V ::= εεεεhαααα(r1,…,rk)U ⋅⋅⋅⋅ VU + Vµµµµh.Uννννn.Uϕϕϕϕ[U]

emptyvariable

eventsequencechoice

recursion

restrictionlocal policy

Model checking usage automata(joint work with P.Degano, G.L. Ferrari, R. Zunino)

• We want to reuse standard, efficient techniques for model checking Basic Process Algebras w.r.t. Finite State Automata

[[ BPA(U) ]] ∩ [[ FSA( ϕϕϕϕ) ]] = 0

• Problem: validity is non-regular!

µµµµh. ννννn. ( ( ( ( new(n) ⋅⋅⋅⋅ αααα(n) + h ⋅⋅⋅⋅ h + ϕϕϕϕ[[[[h]]]] )

– unbounded balanced parentheses ϕϕϕϕ[..[..[..[..ϕϕϕϕ[..[..[..[..ϕϕϕϕ[[[[..]..]..]]..]..]]..]..]]..]..]– infinite number of freshly generated resources

– BPAs have no restriction ννννn

Model checking usage automata

• Model checking recovered in two steps:– usages are transformed to remove the redundant

nestings ϕϕϕϕ[⋅⋅ϕ⋅⋅ϕ⋅⋅ϕ⋅⋅ϕ[⋅⋅⋅⋅⋅⋅⋅⋅]⋅⋅⋅⋅⋅⋅⋅⋅]– usages are “Skolemized” to remove the restrictions ννννn.

For ϕϕϕϕ with arity k, it suffices to use k+1 witnesses.

• A correct and complete model checking technique for deciding the validity of usageg– all the approximations done while constructing U

• The computational complexity is PTIME in the size of U (but EXPTIME in the arity of ϕϕϕϕ)

Securing Java with usage automata(joint work with G. Costa and R. Zunino)

UsagePolicies

JiselJiselJavacJavac

JVMJVM

SecuredExecution

SecuredBytecode

Bytecode

Javasourcecode

Javasourcecode

Javasourcecode

Securing Java with usage automata(joint work with G. Costa and R. Zunino)

UsagePolicies

JiselJisel

LocUsTLocUsT

JavacJavac

ActivePolicies

JVMJVM

SecuredExecution

StaticStaticAnalyserAnalyser

SecuredBytecode

Bytecode

Javasourcecode

Javasourcecode

Javasourcecode

UU

Conclusions• A new formalism for specifying usage policies

• An execution monitor coherent with semantics

• An efficient verification algorithm for deciding when a usage respects the policies on demand

• A tool for model checking usage automata

• Applied to define a new security model for Java

• Unexplored issues:

– existential quantification (for delegation policies)

– tracking calls and returns (for checking return values)