Type-Based Approaches

Information Flow Control

Hammer et al. [54] propose an approach, static information flow control (IFC), that is based on an object-sensitive and flow-sensitive SDG. The IFC approach finds information disclosure (assures confidentiality) and tampering (assures integrity) and provides flexibil- ity in assigning security properties to the types of expressions, where the security prop- erties are organized in a lattice following Bell-LaPadula model [23, 22]. The constraints are however combined in the IFC, and require non-trivial changes to support for example encryption [71].

Implementations of the approach such as JOANA [53] use the SDG generated by WALA [65] and support both explicit and implicit flows. Compared to the aforementioned taint analyses, IFC is sound and supports assigning security properties to expressions rather than method declarations. It finds for example, the vulnerability in SecretViewer which FlowDroid misses due to the unsound call graph, but reports a false positive for ACipher, which FlowDroid and Scoria avoids (Section6.3, page135). Since JOANA does not support Android applications, a detailed comparison with Scoria based on DroidBench remains as future work.

Security information is unavailable in the code. Some approaches [46, 37, 92] require ar- chitects to provide security types as annotations in the code. These annotations are different from the annotations Scoria uses, which focus only on describing aliasing, without providing security information.

Role-based access control

To enhance the code with an authorization mechanism such as role-based access control many approaches use Java annotations. In most cases, these annotations are only checked at runtime. In contrast, a typechecker ensures that annotations and code are consistent at compile-time. For example, Object Role Based Access Control (ORBAC) [46] uses a type- checker to enforce the security policy that a user cannot read confidential data of other users unless their roles allow him to do so. However, ORBAC does not handle object hierarchy and the role-based protection is not propagated to children objects, although the children may represent confidential data.

Type-systems for security

A type system [37, 92] allows architects to add security properties as annotations that augment the type of a variable that includes confidential value (@Tainted) or that can be exposed (@Untainted). Then, architects aided by the typechecker propagate the annotations in the code. To find information disclosure a typechecker analyzes one class at a time and ensures that no @Tainted is assigned to an @Untainted value. In Tainting Checker [37,

102], the constraint is a simple hard-coded check that the architects cannot change without redesigning the typechecker. The main advantage of a typechecker is that it only needs an AST and an intra-procedural CFG as a program representation, which makes the tainting type system modular and scalable. A tainting type system provides soundness, supports aliasing while the precision is provided by annotations.

1 class Main<owner>{ 2 domain UI,LOGIC,DATA;

3 View<UI,LOGIC,DATA> view = new View();

4 }

5 class View<owner,L,D> { 6 domain OWNED;

7 Host<L,D> h = new Host(); 8 Client<L,D> c = new Client(h); 9 void onCreate(String<D> pwd){

10 c.authenticate(pwd);

11 File<D> tFile = new File("client.tmp");

12 FileOutputStream<OWNED> fos = new FileOutputStream(tfile); 13 ObjectOutputStream<OWNED> out = new ObjectOutputStream(fos);

14 out.write(c);

15 }

16 }

17 class Client<owner,D> { 18 domain OWNED;

19 String<OWNED> aToken; 20 Host<L,D> h;

21 void authenticate(String<D> pwd) {

22 aToken = h.getAccessToken(pwd);

23 }

24 void post(String<lent> msg) {

25 h.post(msg, aToken);

26 }

27 }

Figure 7.3: Object reachability: The client object and the access token are persistently stored. A malicious client can impersonate the original client and post messages. Security constraint: A dataflow edge with an untrusted destination does not refer to an object from which confidential data is reachable.

while the parameter of the method write is annotated @Untainted. To find the vulnerability, the type system still needs reachability information because only a variable of the enclosing type of aToken is passed as an argument to the method write. The type system would need to consider all types that have at least one field annotated @Tainted as confidential, which may be overly conservative. If the developer were to use a serialization library and marks the field aToken as transient then the confidential data is not saved and the type system reports a false positive. Different serialization libraries require different implementations of the type systems. In Scoria, the architects can add the IsTransient security property and refine the constraint to avoid the false positive.

JFlow [92] is a Java-like programming language for writing secure programs, and Jif [93] is a type system that assures confidentiality and integrity for programs written in JFlow.

However, JFlow is not backward compatible with Java, and the type annotations are more complex than the ones Scoria uses, which only declare domains or put objects in domains. JFlow supports multiple types of annotations including among others annotations for assign- ing security properties and for defining constraints on explicit and implicit information flow. Since Jif checks the JFlow constraint annotations one class at a time, the constraints seem to enforce information flow control only locally. It would be interesting to compare JFlow constraints with the Scoria constraints that can use global information about objects that are created in different parts of the program and have the same conceptual purpose.