3.3 Non-Interferent Type System for JVM
3.3.3 Type System
Security levels are given by a lattice (S,≤) where ⊔denotes the lub of two security levels, and for every k ∈ S, liftk is a point-wise extension to stack types of λl.k⊔l.
The policy of a method is also defined relative to a security levelkobs which denotes the capability of an observer to observe values from local variables, fields, and return values whose security levels are belowkobs.The typing rules are defined in terms of
stack types; that is a stack that associates a value in the operand stack to the set S of security levels. The stack type itself takes the form of a stack with corresponding indices from the operand stack, as shown below.
We assume that a method comes with its security policy of the formk⃗a kh
→ ⃗krwhere
⃗
ka represents a list{x1∶k1,y2∶k2, . . . ,xm ∶km} withki ∈ S being the security level of local variablesxi∈ X andkhis the effect of the method on the heap andk⃗ris the return signature, i.e., the security level of the return value. The return signature is in the form of a list to cater for the possibility of an uncaught exception on top of the normal return value. Thek⃗r is a list of the form{Norm∶kNorm,e1∶ke1, . . . ,en∶ken} wherekn is the security level for the normal return value and ei is the class of the uncaught exception thrown by the method andkei is the associated security level. In the sequel, we writek⃗r(Norm) to stand forkNorm andk⃗r(ei)to stand forkei. An example of this policy can be{1∶L, 2∶H}→ {H Norm∶L}where L,H∈ S,L≤kobs,H≰kobs indicating that the method will return a low value and that throughout the execution of the method, the security level of local variable 1 will be low while the security level of local variable 2 will be high.
Compared to the usual object or value, arrays have an extended security level to cater for the security level of the contents. The security level of an array is of the form
k[kc]wherekrepresents the security level of the array, andkcrepresents the security level of its content (this implies that all array elements have the same security level
kc). LetSextbe the extension of security levelsS to define the array’s security level. The partial order onS will also be extended with≤ext :
k≤k′ k,k′∈ S k≤extk′
k≤k′ k,k′∈ S kc∈ Sext
k[kc] ≤extk′[kc]
Generally, in the case of a comparison between extended level k[kc] ∈ Sext and a standard level k′∈ S, we only compare k andk′ w.r.t. the partial order onS. In the case of comparison withkobs, sincekobs∈ S, an extended securityk[kc] is considered low (writtenk[kc] ≤kobs) ifk≤kobs.
The transfer rules come equipped with a security policy for fields ft ∶ F → Sext and at∶ PP → Sextthat maps the creation point of an array with the security level of its content. at(a)will also be used to denote the security level of the content of array
a at its creation point.
The notation Γ is used to define the table of method signatures which will as- sociate a method identifier mID and a security level k ∈ S (of the object invoked) to
a security signature ΓmID[k]. The collection of security signatures of a method m is defined asPoliciesΓ(mID) = {ΓmID[k] ∣k∈ S}.
A method is also parameterized by a control dependence region (CDR) which is defined in terms of two functions: region andjun. The function region ∶ PP ×
§3.3 Non-Interferent Type System for JVM 49
guard of the instruction at the specified program point, i.e., in the case ofregion(i,τ)
the guard will be the program pointi. The functionjun(i,τ)itself can be seen as the
nearest program point which all instructions inregion(i,τ)have to execute (junction
point). A CDR is safe if it satisfies the following SOAP (Safe Over APproximation) properties.
Definition 3.3.1. A CDR structure (region, jun) satisfies the SOAP properties if the follow- ing properties hold :
SOAP1. ∀i,j,k∈ PP and tagτif i↦j and i↦τ k and j≠k (i is hence a branching point)
then k∈region(i,τ)or k=jun(i,τ).
SOAP2. ∀i,j,k∈ PP and tagτ, if j∈region(i,τ)and j↦k, then either k∈region(i,τ)
or k=jun(i,τ).
SOAP3. ∀i,j∈ PP and tag τ, if j∈ region(i,τ) and j is a return point thenjun(i,τ) is
undefined.
SOAP4. ∀i∈ PP and tags τ1,τ2 ifjun(i,τ1) andjun(i,τ2) are defined and jun(i,τ1) ≠
jun(i,τ2)thenjun(i,τ1) ∈region(i,τ2)orjun(i,τ2) ∈region(i,τ1).
SOAP5. ∀i,j∈ PP and tagτ, if j∈region(i,τ)and j is a return point then for all tagsτ′
ifjun(i,τ′)is defined thenjun(i,τ′) ∈region(i,τ).
SOAP6. ∀i∈ PP and tagτ1, if i↦τ1 then for all tagsτ2,region(i,τ2) ⊆region(i,τ1)and ifjun(i,τ2)is defined thenjun(i,τ2) ∈region(i,τ1).
The security environment functionse∶ PP → S is a map from a program point to a security level. The notation⇒represents a relation between the stack type before execution and the stack type after execution of an instruction.
The typing system is formally parameterized by :
Γ: a table of method signatures, needed to define the transfer rules for method invo- cation;
ft: a map from fields to their global policy level; CDR: a structure consisting of (region,jun).
se: a security environment
sgn: the method signature of the current method
Si: stack type annotation at program pointi
st: stack typing after the instruction is executed
thus the complete form of a judgment parameterized by a tagτ∈ {Norm+ C}is
Γ,ft,region,se,sgn,i⊢τ S
Pm[i] =loadx se,i⊢st⇒ ( ⃗ka(x) ⊔se(i)) ∶∶st Pm[i] =store x se(i) ⊔k≤ ⃗ka(x) se,i⊢k∶∶st⇒st Pm[i] =swap i⊢k1∶∶k2∶∶st⇒k2∶∶k1∶∶st Pm[i] =push n se,i⊢st⇒se(i) ∶∶st Pm[i] =pop i⊢k∶∶st⇒st Pm[i] =ifeq j ∀j′∈region(i, Norm),k≤se(j′)
region,se,i⊢k∶∶st⇒liftk(st) Pm[i] =goto j i⊢st⇒st Pm[i] =binopop se,i⊢k1∶∶k2∶∶st⇒ (k1⊔k2⊔se(i)) ∶∶st Pm[i] =return se(i) ⊔k≤ ⃗kr(n) ⃗ ka kh → ⃗kr,se,i⊢k∶∶st⇒ Pm[i] =newC Γ,ft,k⃗a kh → ⃗kr,region,se,i⊢st⇒se(i) ∶∶st Pm[i] =newarrayt k∈ S Γ,ft,k⃗a kh → ⃗kr,region,se,i⊢Normk∶∶st⇒k[at(i)] ∶∶st
Pm[i] =getfield f k∈ S ∀j∈region(i, Norm),k≤se(j)
Γ,ft,k⃗a kh
→ ⃗kr,region,se,i⊢Normk∶∶st⇒liftk(((k⊔se(i)) ⊔extft(f)) ∶∶st)
Pm[i] =getfield f k∈ S ∀j∈region(i, np),k≤se(j) Handler(i, np) =t
Γ,ft,k⃗a kh → ⃗kr,region,se,i⊢npk∶∶st⇒ (k⊔se(i)) ∶∶e Pm[i] =getfield f k∈ S ∀j∈region(i, np),k≤se(j) Handler(i, np) ↑ k≤ ⃗kr(np) Γ,ft,k⃗a kh → ⃗kr,region,se,i⊢npk∶∶st⇒
Pm[i] =putfield f (se(i) ⊔k2) ⊔extk1≤ft(f) k1∈ Sext k2∈ S kh≤ft(f) ∀j∈region(i, Norm),k2≤se(j)
Γ,ft,k⃗a kh
→ ⃗kr,region,se,i⊢Normk1∶∶k2∶∶st⇒liftk2(st) Pm[i] =putfield f (se(i) ⊔k2) ⊔extk1≤ft(f) k1∈ Sext k2∈ S
∀j∈region(i, np),k2≤se(j) Handler(i, np) =t Γ,ft,k⃗a
kh
§3.3 Non-Interferent Type System for JVM 51
Pm[i] =putfield f (se(i) ⊔k2) ⊔extk1≤ft(f) k1∈ Sext k2∈ S
∀j∈region(i, np),k≤se(j) Handler(i, np) ↑ k2≤ ⃗kr(np)
Γ,ft,k⃗a kh
→ ⃗kr,region,se,i⊢npk1∶∶k2∶∶st⇒
Pm[i] =arraylength k∈ S kc∈ Sext ∀j∈region(i, Norm),k≤se(j)
Γ,ft,k⃗a kh
→ ⃗kr,region,se,i⊢Normk[kc] ∶∶st⇒liftk(k∶∶st)
Pm[i] =arraylength k∈ S kc∈ Sext ∀j∈region(i, np),k≤se(j) Handler(i, np) =t
Γ,ft,k⃗a kh
→ ⃗kr,region,se,i⊢npk[kc] ∶∶st⇒ (k⊔se(i)) ∶∶e
Pm[i] =arraylength k∈ S kc∈ Sext ∀j∈region(i, np),k≤se(j) Handler(i, np) ↑ k≤ ⃗kr(np)
Γ,ft,k⃗a kh
→ ⃗kr,region,se,i⊢npk[kc] ∶∶st⇒
Pm[i] =arrayload k1,k2∈ S kc∈ Sext ∀j∈region(i, Norm),k2≤se(j)
Γ,ft,k⃗a kh
→ ⃗kr,region,se,i⊢Normk1∶∶k2[kc] ∶∶st⇒liftk2(((k1⊔k2) ⊔extkc) ∶∶st) Pm[i] =arrayload k1,k2∈ S kc∈ Sext ∀j∈region(i, np),k2≤se(j)
Handler(i, np) =t Γ,ft,k⃗a
kh
→ ⃗kr,region,se,i⊢npk1∶∶k2[kc] ∶∶st⇒ (k2⊔se(i)) ∶∶e
Pm[i] =arrayload k1,k2∈ S kc∈ Sext ∀j∈region(i, np),k2≤se(j)
Handler(i, np) ↑ k2≤ ⃗kr(np)
Γ,ft,k⃗a kh
→ ⃗kr,region,se,i⊢np k1∶∶k2[kc] ∶∶st⇒
Pm[i] =arraystore ((k2⊔k3) ⊔extk1) ≤extkc k2,k3∈ S k1,kc∈ Sext
∀j∈region(i, Norm),k2≤se(j) Γ,ft,k⃗a
kh
→ ⃗kr,region,se,i⊢Normk1∶∶k2∶∶k3[kc] ∶∶st⇒liftk2(st) Pm[i] =arraystore ((k2⊔k3) ⊔extk1) ≤extkc k2,k3∈ S k1,kc∈ Sext
∀j∈region(i, np),k2≤se(j) Handler(i, np) =t Γ,ft,k⃗a
kh
Pm[i] =arraystore ((k2⊔k3) ⊔extk1) ≤extkc k2,k3∈ S k1,kc∈ Sext
∀j∈region(i, np),k2≤se(j) Handler(i, np) ↑ k2≤ ⃗kr(np)
Γ,ft,k⃗a kh
→ ⃗kr,region,se,i⊢npk1∶∶k2∶∶k3[kc] ∶∶st⇒
Pm[i] =invokemID length(st1) =nbArguments(mID) ΓmID[k] = ⃗k′a k′
h
→ ⃗k′r
∀i∈ [0,length(st1) −1].st1[i] ≤ ⃗k′a[i+1] k≤ ⃗k′a[0] k⊔kh⊔se(i) ≤k′h
ke= ⊔ { ⃗k′r(e) ∣e∈excAnalysis(mID)} ∀j∈region(i, Norm),k⊔ke≤se(j)
Γ,ft,k⃗a kh
→ ⃗kr,region,se,i⊢Normst1∶∶k∶∶st2⇒liftk⊔ke(( ⃗k′r(n) ⊔se(i)) ∶∶st2))
Pm[i] =invokemID length(st1) =nbArguments(mID) ΓmID[k] = ⃗k′a k′
h
→ ⃗k′r
∀i∈ [0,length(st1) −1].st1[i] ≤ ⃗k′a[i+1] k≤ ⃗k′a[0] k⊔kh⊔se(i) ≤k′h
e∈excAnalysis(mID) ∪ {np} Handler(i,e) =t ∀j∈region(i,e),k⊔k′r(e) ≤se(j)
Γ,ft,k⃗a kh
→ ⃗kr,region,se,i⊢est1∶∶k∶∶st2⇒ (k⊔ ⃗k′r(e)) ∶∶e
Pm[i] =invokemID length(st1) =nbArguments(mID) ΓmID[k] = ⃗k′a
k′
h
→ ⃗k′r ∀i∈ [0,length(st1) −1].st1[i] ≤ ⃗k′a[i+1]
k≤ ⃗k′a[0] k⊔kh⊔se(i) ≤k′h k⊔se(i) ⊔ ⃗kr′(e) ≤ ⃗kr(e)
e∈excAnalysis(mID) ∪ {np} Handler(i,e) ↑ ∀j∈region(i,e),k⊔k′r(e) ≤se(j)
Γ,ft,k⃗a kh
→ ⃗kr,region,se,i⊢est1∶∶k∶∶st2⇒
Pm[i] =throw e∈classAnalysis(i) ∪ {np} ∀j∈region(i,e),k≤se(j) Handler(i,e) =t Γ,ft,k⃗a kh → ⃗kr,region,se,i⊢ek∶∶st⇒ (k⊔se(i)) ∶∶e Pm[i] =throw e∈classAnalysis(i) ∪ {np} k≤ ⃗kr(e) ∀j∈region(i,e),k≤se(j) Handler(i,e) ↑ Γ,ft,k⃗a kh → ⃗kr,region,se,i⊢ek∶∶st⇒
§3.3 Non-Interferent Type System for JVM 53
In the case where some elements are unnecessary, we may omit some of the param- eters, e.g.,i⊢Si⇒st.
As in the operational semantics, wherever it is clear that the instructions may not throw an exception, we remove the tag Norm to reduce clutter. The transfer rules are contained in Figure 3.4. Using these transfer rules, we can then define the notion of typability:
Definition 3.3.2(Typable method). A method m is typable w.r.t. a method signature table Γ, a global field policyft, a policy sgn, and a CDRregionm∶ PP → ℘(PP)if there exists a security environment se ∶ PP → S and a function S ∶ PP → S∗ s.t. S1 = eand for all
i,j∈ PP, and exception tags e∈ {Norm+ C}:
(a) i ↦e j implies there exists st ∈ S∗ such that Γ,ft,region, se, sgn, i ⊢e Si ⇒st and
st⊑Sj;
(b) i↦eimpliesΓ,ft,region,se,sgn,i⊢eSi⇒,
where ⊑denotes the point-wise partial order on type stack w.r.t. the partial order taken on security levels.
The Non-interference definition relies on the notion of indistinguishability. Loosely speaking, a method is non-interferent if, given indistinguishable inputs, it yields in- distinguishable outputs. Obviously, we have to define what it means to be indistin- guishable.
To define the notions of location, object, and array indistinguishability, Barthe et al. define the notion of aβmapping. βis a bijection on (a partial set of ) locations in
the heap. The bijection maps low objects (objects whose references might be stored in low fields or variables) allocated in the heap of a state to low objects allocated in the heap of subsequent state. Two objects might be indistinguishable, even if their locations are different during execution. Theβfunction is a bijection in the sense that
it is a one to one correspondence on all low objects in the heap, but it is also partial in a sense that high objects are not mapped.
Definition 3.3.3 (Value indistinguishability). Letting v,v1,v2 ∈ V, and given a partial functionβ∈ L ⇀ L, the relation∼β⊆ V × Vis defined by the clauses :
null∼β null
v∈ N v∼β v
v1,v2∈ L β(v1) =v2 v1∼βv2
Definition 3.3.4 (Local variables indistinguishability). For ρ,ρ′ ∶ X ⇀ V, we have ρ ∼k
obs,ka⃗,β ρ
′ if ρ and ρ′ have the same domain and if k⃗
a(x) ≤ kobs then ρ(x) ∼β ρ′(x) for all x∈dom(ρ).
Definition 3.3.5(Object indistinguishability). Two objects o1,o2∈ Oare indistinguishable with respect to a partial functionβ∈ L ⇀ L(written as o1∼kobs,β o2) if and only if o1and o2 are objects of the same class and o1.f ∼β o2.f for all fields f ∈dom(o1)s.t. ft(f) ≤kobs.
Definition 3.3.6(Array indistinguishability). Two arrays a1,a2∈ Aare indistinguishable w.r.t. an attacker level kobs and a partial functionβ∈ L ⇀ L(written as a1∼kobs,β a2) if and only if a1.length = a2.length and, moreover, if at(a1) ≤kobs, then a1[i] ∼β a2[i] for all i such that0≤i<a1.length.
Definition 3.3.7(Heap indistinguishability). Two heaps h1 and h2are indistinguishable, written h1 ∼kobs,β h2, with respect to an attacker level kobsand a partial functionβ∈ L ⇀ L iff:
• βis a bijection betweendom(β)andrng(β);
• dom(β) ⊆dom(h1)andrng(β) ⊆dom(h2);
• ∀l ∈dom(β),h1(l) ∼kobs,β h2(β(l))where h1(l)and h2(β(l)) are either two objects or two arrays.
Definition 3.3.8 (Output indistinguishability). Given an attacker level kobs, a partial functionβ∈ L ⇀ L, an output levelk⃗r, the indistinguishability of two final states in method
m is defined by the clauses below where→indicates logical implication : h1∼kobs,β h2 k⃗r(Norm) ≤kobs→v1∼β v2
(v1,h1) ∼kobs,β,⃗kr (v2,h2)
h1∼kobs,βh2 (class(h1(l1)) ∶k) ∈ ⃗kr k≤kobs l1∼β l2
(⟨l1⟩,h1) ∼kobs,β,kr⃗ (⟨l2⟩,h2)
h1∼kobs,β h2 (class(h1(l1)) ∶k) ∈ ⃗kr k≰kobs
(⟨l1⟩,h1) ∼kobs,β,kr⃗ (v2,h2)
h1∼kobs,β h2 (class(h2(l2)) ∶k) ∈ ⃗kr k≰kobs
(v1,h1) ∼kobs,β,kr⃗ (⟨l2⟩,h2)
h1∼kobs,βh2 (class(h1(l1)) ∶k1) ∈ ⃗kr k1≰kobs (class(h2(l2)) ∶k2) ∈ ⃗kr k2≰kobs
(⟨l1⟩,h1) ∼kobs,β,kr⃗ (⟨l2⟩,h2)
At this point, it is worth mentioning that whenever it is clear from the usage, we may drop some subscript from the indistinguishability relation, e.g., for two indistin- guishable objectso1ando2 w.r.t. a partial functionβ∈ L ⇀ Land observer levelkobs,
instead of writing o1 ∼kobs,β o2 we may dropkobs and write o1∼β o2 if kobsis obvious.
We may also dropkhfrom a policy k⃗a kh
→ ⃗kr and writek⃗a→ ⃗kr ifkh is irrelevant to the discussion.
Definition 3.3.9(Non-interferent JVM method). A method m isnon-interferentw.r.t. a policy k⃗a → ⃗kr, if for every attacker level kobs, every partial function β ∈ L ⇀ Land every