Formal Modeling and Reasoning about the Android Security Framework

Formal Modeling and Reasoning about the

Android Security Framework

Alessandro Armando: Fondazione Bruno Kessler Gabriele Costa: Universit`a di Genova

Alessio Merlo: Universit`a E-Campus

Outline

1 Context and motivations

2 _{Modeling the Android framework}

3 Type and effect system

Outline

1 Context and motivations

2 _{Modeling the Android framework}

3 Type and effect system

Mobile devices and applications

Smart devices

Computational capabilities: modern devices resemble PCs profiles Resources: mobile phones managemorevaluable resources than PCs Code mobility: most of the functionalities are provided through mobile applications (Apps)

Mobile applications

Apps can be obtained from remote (trusted or untrusted) providers Typically, they consists of code,resourcesand acontract

App code is installed and can dynamically access system resources App resources are added to the system ones (with proper

permissions)

Android

Android OS

Popular: more than 900K new devices per day (June ’12) Used by different devices: phones, tablets, PCs, smart TVs, ... Open source: can be inspected and customised

Linux-kernel + Java application level Android Apps

App markets: Apps are published through dedicated web services App pkg: Packages contain App bytecode, resources and manifest Manifest: A list of permissions and privileges defined/required by the App

Android Application Framework

Programming framework

Java Language + Android APIs + Dalvik VM

Apps consist of componentsof typeactivity,service,content providerorintent receiver.

Components access the system resources via APIs (vertical interaction) and other Apps contents viaintents(horizontal interaction)

Permissions and privileges

Manifests contain a list ofprivileges (required by the App) and permissions (declared by the App) + components description Users check privileges before installation and accept them Dynamic access controlguarantees that Apps only use APIs according to privileges

Security Limitations in Android

Known issues

Manifest description is extremely coarse-grained

E.g., “App uses network” tells nothing about network usage Access control isnot effective

Unable to prevent collusion (i.e., App offering illegal accesses) Security policies areunclear

Users do not have a global view and cannot decide their rules Flawshave been reported

Outline

1 Context and motivations

2 _{Modeling the Android framework}

3 Type and effect system

Modeling approach

Programming framework

We define a programming languageallowing us to write and analyse applications in a minimal framework

It includes an imperative fragment with statements forintents, API invocationsandprivileges modification

Applications are collections of components with anamespace and a manifest

Programming language

Syntax A::=hM,∆,C¯i Application M ::= Π;P; Λ Manifest Π ::=ε | ρα.Π | ρσ.Π Privileges P::=ε | (α,u¯).P Permissions Λ ::=ε | (α7→η).Λ Bindings ∆ ::=∅ | ∆{C/η} Name space

C ::=skip | icastE | ecastηE | grant_σηE | Statements

revokeσηE | checkσηE | newxinC | receiveαx7→C |

applyEtoE0 | system_σE | if(E =E0){C}else{C0} | C;C0 E ::=null | u |x | Iα(E,E0) | E.d | E.e | procf(x){C} Expressions

Statements semantics

Configuration and transitions

U,Φ,C a U0,Φ0,C Rules (fragment) (S−GRNT) self=η0 u∈U(η0) Φ0= Φ∪ {(η, σ,u)} U,Φ,grant_σηu U,Φ0,· (S−ICST) self=η η0∈Λ(α) η, α,u|= Φ U,Φ,icastIα(u,v) αη0 η(u,v) Λ U,Φ,· (S−SYS) self=η η, σ,u|= Φ U,Φ,system_σuση(u)U,Φ,·

System behaviour

Execution context

Given a set of applications we build anexecution context

P=U,Φ,[C1]η1· · ·[Cn]ηn

Φis the system policy and is automatically built from the application manifests Context semantics U,Φ,Cj b ΛU0,Φ0,C0 U,Φ,[C1]η₁· · ·[Cj]η_j· · ·[Cn]ηn b ⇒ΛU0,Φ0,[C1]η₁· · ·[C0]η_j· · ·[Cn]ηn U,Φ,Ci αηηj_i(u,v) Λ U0,Φ0,C0 U,Φ,· · ·[Ci]ηi· · ·[receiveαx7→C]ηj· · · ⇒ΛU0,Φ0,· · ·[C0]ηi· · ·[C{Iα(u,v)/x}]ηj· · ·

Outline

1 Context and motivations

2 _{Modeling the Android framework}

3 Type and effect system

Applications effects

History expressions

Process algebra-like syntax and semantics

Provide a fine-grained description of programs behaviour Used for history-based security analysis (e.g., usage control) Syntax H,H0 ::= ε | h | αη(u, τ) | α¯ηh.H | ση(u) | ησ,u | ησ,u | ?ησ,u | νu.H | H·H0 | H+H0 | HkH0 | µh.H | H\L LTS semantics (examples) αη(u, τ) αη(u,τ) −−−−−→ε ση(u) ση(u) −−−→ε η_σ,u η σ,u −−→ε JHK={a1. . .an| ∃H 0_.H a1 −→ · · · an −→H0}

Typing rules

Type and type environment

τ, τ0 ::=1 | U | Iα(U, τ) | τ

H

−→1 Γ,Γ0 ::=∅ | Γ{τ /x}

Judgements structure

Γ`E :τ Γ.η_OC:H

Type and effect system (fragment) (TS−ICST) Γ`E:Iα(U, τ) Γ.η<sub>O</sub>icastE: P u∈U αη(u, τ) (TS−SYS) Γ`E:U Γ.η_Osystem_σE: P u∈U ση(u) (TS−RECV) Γ{Iα(U, τ)/x}.η_OC:H Γ.η_Oreceiveαx7→C: ¯αηh.H

Type and effect system properties

Lemma

For eachC such that ∅.η_OC :H and for each Φ,Λ andU such that

U(η) =O, for all arbitrary long sequences of actions performed by

U,Φ,C there exists a trace in_JH_K denoting it. Theorem

For eachS =A1, . . . ,An such thatAi =hMi,∆i,C1i. . .C

i

kiifor any

arbitrary long computation performed byUS,ΦS,[C11]η1 1· · ·[C

n

kn]ηnkn there

Outline

1 Context and motivations

2 _{Modeling the Android framework}

3 Type and effect system

Future work

Ongoing research

Integrate our approach in the real Android development framework Include language for expressive security policies (e.g., temporal logics)

Enhance Android security with user-defined security policies Use history expressions for both static analysis and applications monitoring

Conclusion

In this paper

We defined a new approach for modeling Android applications Models are automatically inferred from applications implementations History expressions provide fine-grained characterisation of

applications behaviour in terms of security-relevant operations We capture illegal interactions which causes documented security flaws and attacks