ASM CH2 - General Security Model of Android

1. Multi-party authorization
   According to the reference papar (chapter 3) given at the beginning of this blog, the term multi-part authorization is actually another type of “Access Control”.

   In the reference paper, they define three types of participants in the whole Android system:

   • Users
   • Developers
   • Platform

   DAC (discretionary access control) is been used in users and developers groups which is stated in detail in the paper. As for the access control method among users, developers and platform, they adopt MAC (mandatory access control). For the detail of the connection between DAC and MAC, refer to BIGMAC: Fine-Grained Policy Analysis of Android Firmware

   In the paper they say, for users and developers:

   • Data in shared storage is controlled by users.
   • Data in private app directories and app virtual address space is controlled by apps (developers).
   • Data in special system locations is controlled by the platform (e.g. list of granted permissions).

2. Open ecosystem access
   No central control organization, which means “Instead of creating specific platform APIs for every conceivable workflow, app developers are free to define their own APIs they offer to other apps.”

   Which also means system developers of Android are only responsible for the platform-level security issues, but for the upper architecture, it should be protected both by developers and then finally users.

3. Security is a compatibility requirement
   To get straight to the point, if your modding “android” is not complied with CDD and cannot pass CTS, then basiclly it’s not Android. The exception are, for example, you implement a new security model that can be admitted by the security team of Android. Let’s say, allowing you system to be rooting, but can make sure your system can return to a known-good state.

4. Factory reset restores the device to a safe state
   Factory reset returns an Android device to a state that only depends on system code that is covered by Verified Boot. An important aspect is supply chain security of these factory images in the sense of integrity and authenticity of system code.

5. Applications are security principals
   Android apps are not considered to be fully authorized agents for user actions.

In summary, even though the Android doesn’t fully grant the users with all the power, but in this way, it can also prevent the users from the tricks of malicious apps.

The Android platform security model does not currently have a simple, consistent representation in formal notation because these rules evolved from practical experience instead of a top-down theoretical design. The five rules are, at the time of this writing, the simplest expression of how these different security controls combine at the meta level.

1. Machenism summarization

2. Machenism in practical