Abstract-We introduce a novel type system for enforcing secure information flow in an imperative language. Our work is motivated by the problem of statically checking potential information leakage in Android applications. To this end, we design a lightweight type system featuring Android permission model, where the permissions are statically assigned to applications and are used to enforce access control in the applications. We take inspiration from a type system by Banerjee and Naumann to allow security types to be dependent on the permissions of the applications. A novel feature of our type system is a typing rule for conditional branching induced by permission testing, which introduces a merging operator on security types, allowing more precise security policies to be enforced. The soundness of our type system is proved with respect to non-interference. In addition, a type inference algorithm is presented for the underlying security type system, by reducing the inference problem to a constraint solving problem in the lattice of security types. Mobile security has become increasingly important for our daily life due to the pervasive use of mobile applications. Among the mobile devices that are currently in the market, Android devices account for the majority of them so analysis of their security has been of significant interests. There has been a large number of analyses on Android security ([1]-[5]) focusing on detecting potential security violations. Here we are interested instead in the problem of constructing secure applications, in particular, in providing guarantee of information flow security in the constructed applications. We follow the language-based security approach whereby information flow is enforced through type systems [6]- [9] . In particular, we propose a design of a type system that guarantees non-interference property [8], i.e., typable programs are non-interferent. As shown in [10], non-interference provides a general and natural way to model information flow security. The type-based approach to non-interference requires assigning security labels to program variables and security policies to functions or procedures. Such policies are typically encoded as types, and typeability of the program implies that the runtime behavior of the program complies with the stated policies. Security labels form a lattice structure with an † Corresponding author. S t r i n g number ; i f ( c h e c k P e r m i s s i o n (READ_CONTACT ) ) number = . . . ; // query the phone number e l s e number = " " ; r e t u r n number ; } Listing 1. Sample code for getting contact info with a permission check. underlying partial order ≤, e.g., a lattice with two elements "high" (H) and "low" (L) where L ≤ H. Typing rules can then be designed to prevent both explicit and implicit flow (through conditionals, e.g., if-then-else statements) from H to L. To prevent an explicit flow, the typing rule for an assignment statement such as x := e would require that l(e) ≤ l(x) where l(.) denotes the security level of an expression. To prevent an implicit flow, e.g., if (y = 0) then x:= 0 else x := 1, most type systems for non-interference require that the assignments in both branches are given the same security level that is higher or at least equal to the security level of the condition (y=0). For example, if y is of type H and x is of type L, the statement would not be typable. In designing an information flow type system for Android, we encounter a common pattern of conditionals that would not be typable using conventional type systems. Consider the pseudo-code in Listing 1. Such a code fragment could be part of a phone dialer or a social network service app such as Facebook, WhatsApp, where getContactNo provides a public interface to query the phone number associated with a name. The (implicit) security policy in this context is that contact information (the phone number) can only be released if the calling app has READ_CONTACT permission. The latter is enforced using the checkPermission API in Android. Suppose phone numbers are labelled with H, and the empty string is labelled with L. If the interface is invoked by an app that has the required permission, the phone number (H) is returned; otherwise an empty string (L) is returned. In both cases, no 218 2018 IEEE 31st Computer Security Foundations Symposium
Recent work by REF considers security labels that depend on permissions granted to a program.
A Permission-Dependent Type System for Secure Information Flow Analysis
2018 IEEE 31st Computer Security Foundations Symposium (CSF)
2018 IEEE 31st Computer Security Foundations Symposium (CSF)
Computer Science