software verification, весна 2008: automated verification of security policies in mobile code

Automated Verification of Security Policies inMobile Code

Natasha Sharygina

University of Lugano, Switzerland

and Carnegie Mellon University, USA

Joint work with Chiara Braghin and Katerina Barone-Adesi

Automated Verification of Security Policies in Mobile Code – p. 1/25

Motivation (1)

GSMPhone

Mobile Node DataAdapter

PCMCIA

GSM Network

Modem Pool

LAN

LAN Host

9600 bps

MODEM

MODEM

DialupServer

Router

WAN Host

BaseTransceiverStation

Mobile ServicesSwitching Center

IWF MODEM

MODEM

Public Switched Telephone Network (PSTN)

Internet

Formal methods are needed for the specification and verification ofmobile distributed systems, focusing onsecurity issues.


Motivation (2)

Mobile systems are aspecial case of multi-threaded distributedprograms.

Differences:Threads may run in different locations (e.g., administrativedomains, hosts, physical locations);Threads may migrate from one location to another;Thread communication takes into account geographicaldistribution:

distinction among local and global (remote) communication;remote communication may be restricted by security policies(migration can occur only between directly linked net locations).


Objectives

Expressive formalism for specifying mobile systems:explicit specification of thethread locationandlocation netformalization of different synchronization and communicationmechanisms

Formal analysis of mobile systems by model checking of security andsafety properties:

not restricted to a single security policyabstraction-based approach for efficiencysound modeling of unbounded thread creation.


Outline of Talk

Part I: PreliminariesExisting programming languages for mobile codeVerification: possible techniquesSoftware model checking in a nutshell

Part II:ModelingExplicit notion of locationLocation-aware threads as LKS

Part III: VerificationA language for specifying different security policiesA model-checking framework for verification of mobile programsA location-based efficient abstraction


State of the Art

Programming languagesfor mobile code:Special purpose languages: Telescript, Obliq, Klaim,· · ·

General purpose languages: Java, C,· · ·

Currentvalidation techniques:Testing and simulationType system or Abstract Interpretation:

on process algebrae (π-calculus, Mobile Ambients, Dpi, etc.)on very small fragments of programming languages

Dynamic policy verification (e.g., Java sandbox)Model checking


Software Model Checking

Software verification with model checking:fully automateddiagnostic counter-examplesstate space explosion problem

Different model checking techniques:explicit model checkingsymbolic model checkingbounded model checkingCEGAR-based model checking


CEGAR-based Model Checking (1)


CEGAR-based Model Checking (2)

Build Abstract ModelUsing predicate abstraction and initial set of predicates P

Model Check the abstract modelGenerate reachable states explicitly/symbolicallyObtain a counterexample

Check if the counterexample is spuriousSimulate the counterexample on the concrete model

Abstraction RefinementFind new predicates to add to P in order to eliminate thecounterexampleUse the spurious counterexample to refine the abstraction


Location-aware Threads (2)

Explicit notion oflocation( ℓ[[T ]] ).

Ability to capture the geographical distribution of the Web:location netis used to encapsulates the hierarchical nesting

location net: a tree, with nodes labeled by unique locationnames;mobility: updates of the location net;

the structure of the location net can be constrained to formalizevarious security policies.

Ability to locate multi-threaded programs.


Location Net - Example

Consider a system with the following set of locations:

Loc = {env, ℓ0, ℓ1, ℓ2, ℓ3, ℓ4}.

The location net is:

{env.ℓ0.ℓ1, env.ℓ2, env.ℓ3, env.ℓ4},

which corresponds to the following tree:


The Computational Model (1)

A location-aware thread is a Labeled Kripke StructureT = (S, Init, AP,L,Σ,R), with:

The set of statesS = (Vl, Vg, pc, ϕ, η):Vl evaluation of local variables,Vg evaluation of global variables,pc the program counter,ϕ : Loc → Loc is a partial order function denoting thelocationnet (whereLoc is the set of location names),η : N → Loc is a partial function denoting thethread location.

R ⊆ S × Σ × S ∪ { S × S } is a totallabeledtransition relation

notice thatsfork−−−−→ (s′, s), with s′ the next state ofs, and

s = Init the initial state of the newly created thread.



Inference rules for the labeled transition relationRi for threadTi.

(FORK-ACTION)Instr(s.pc) = fork

sfork

−−−→ i (s′, s) [s′.pc = s.pc + 1; s = Initi]

(in-ACTION)Instr(s.pc) = go in(ℓ) ∧ (∃ℓ1 s.t.: ℓ1 := s.η(i) ∧ s.ϕ(ℓ1) = s.ϕ(ℓ))

sgo_in(l)

−−−−−→ i s′ [s′.pc = s.pc + 1; s.ϕ ∪ {ℓ 7→ ℓ1}]

(SYNC-ACTION)Instr(s.pc) = m

sm−→ i s′ [s′.pc = s.pc + 1]



The set ofΣ is split into mutually disjoint setsΣM , ΣS, ΣT , Στ ,representingmoving, synchronization, thread creation, andτ actions.

The labeled transition relation for the composition of two threadsT1 ‖ T2.

(SYNC-ACTION)

a ∈ ΣS1 ∧ s1 a

−→ 1 s′1∧ a ∈ ΣS

2 ∧ s2 a−→ 2 s

′2∧ s1.η(1) = s2.η(2)

(s1, s2)a−→ (s

′1, s

′2)

(L-PAR)

a ∈ ΣM1 ∧ s

a−→ 1 s

′1

(s1, s2)a

−→ 1 (s′1, s2)

(R-PAR)

a ∈ ΣM2 ∧ s2 a

−→ 2 s′2

(s1, s2)a

−→ 2 (s1, s′2

)


Verification of Security Policies (1)

Mandatory Access ControlIf ℓ is a location/host that contains confidential information,need tocheck that the information is not leaked (i.e., no write to remotelocations).

Information FlowIf Ti is a shopping agent searching the best airfare for a flight fromLugano to London and buying it by using the user’s credit cardnumber, need to validate to whom the threads reveals theconfidential information (by exploiting the trail of the actions of thethread).

“Bad” TracesIf Ti is a downloaded applet, need to check for Trojan horses, i.e.,sequences of malicious instructions (e.g., installing a backdoor or akeylogger).



A security policy consists of a set of rules or conditions stating whichactions are prohibited in the system:

〈policy〉 − > {〈sec_levels〉 | 〈operation_def〉 | 〈deny statement〉}

〈deny statement〉 − > deny to 〈deny_target〉 [〈code base〉][〈code origin〉]

{ 〈permission entry〉 {, 〈permission entry〉} }

〈deny_target〉 − > public| 〈entity list〉

The location may play an important role in determining access rights:

〈code base〉 − > codeBase 〈IPv4 addr〉

〈code origin〉 − > codeOrigin(〈location〉 | remote)

〈location〉 − > 〈location_id〉 {: 〈location_id〉}



A permission entry specifies which actions are denied:

〈permission entry〉 − > permission 〈action〉

〈action〉 − > 〈function〉 | 〈operation〉

In case of a function, it is possible to specify(i) formal parameters(variable names),(ii) actual parameters (the value of the argumentspassed),(iii) an empty string, denying access to the function regardlessof the arguments to it, or(iv) the keywordhigh (no high variables canbe passed as arguments to this function).

〈function〉 − > function 〈function_id〉〈parameters〉

〈parameters〉 − > 〈actual par〉 | 〈formal par〉 | high | ε



Java sandbox policy: it is responsible for protecting a number ofresources by preventing applets from accessing the local hard disk andthe network.

operation read_file_system { fread, read, scanf, gets, fgets}

deny to public codeOrigin remote

{ permission function connect_to_location,

permission operation read_file_system }

A naive multi-level security policy:

High={confidential_var, x}

deny to public codeOrigin remote

{ permission function fopen high}


Automated Security Verification

ProgramP ′ is annotated with the security invariants expressed in thesecurity policy;

A security monitor function is created for each permission statement inthe policy;

P ′ consists of the product ofP with all the monitor functionscorresponding to the security policyS.


An Efficient Security-driven abstraction

Idea: Remove from the system the behavior not related to thelocation-specific policy:

Location Projection, π ↓ ℓ: thread executions for a particularlocation.Moving Projection, π ↓M i: all movingactions executed by threadTi.Thread Projection, π ↓ i: all actions executed by threadTi.


The CEGAR Loop Revisited


Experiments

policy time (s) # iterations # predicates pv? SATABS: pv?

1 (sa) 151.644 7 17 yes yes

2 local (sa) 100.234 5 15 no no

2 remote (sa) 524.866 12 36 yes yes

3 codeBase (sa) 340.011 12 22 yes yes

Sample policy (2(sa)):deny to public codeOrigin remote

{ permission function fopen "/etc/passwd"}


Conclusion

Expressive formalism for specifying mobile systems:– it explicitly models thread location, location distribution and threadmoving operations;– it preserves both data and communication structures of mobilesystems.

Specification language for specifying security policies ofmobile code:– information flow;– access control policies;

Integrated model checking framework to support exhaustiveanalysis ofsecurity policies;

Location-specific abstractions enable the efficient verification of largemobile code applications.


software verification, весна 2008: automated verification of security policies in mobile code

Documents