Android Security Model

SELinux for Android

Security Enhanced Linux is applied for Android OS 4.3 and later versions , in order to overcome the shortcomings with Discretionary Access Control (DAC). SELinux as usual was first introduced for desktops. Later, it was adopted for Android with required modifications by a set of researcher and named it as “SEAndroid”. SELinux has used a new MAC policy to entrust the security of the Linux OS. The same MAC policy concept was adopted for Android with SEAndroid. I will explain here how the MAC policy has enhanced the security of the Android OS.

What is new with MAC than DAC?

MAC stands for Mandatory Access Control. As the name implies, MAC system enforce security policies over all processes, objects and operations. Thus, all security decisions will be made by a central authority, rather than depending on the resource owner to determine the access permissions. The following Figure shows how the central authority make decision. When an application process (Subject) wants to access a particular resource (Object), it will be handle by the “Object Manager”. The “Security Server” will make the decision whether allow or deny by looking at the “Security Policies”. Once a decision is made it is passed to the “Access Vector Cache”, so that it increase the performance of the component in the next attempt. So, the “Object Manager” will first check the AVC Cache for the decision, if otherwise the task will be forward to “Security Server”.

How to make a security decision with MAC policy?

MAC policies are defined based on the “Security Context” of a particular Subject and Object. Now lets see how this “Security Context” is defined for each Subject and Object.

Each application process will get a new attribute called this “Security Context” in addition to the UID at the time of process being forked by the “Zygote”. All the resources will also get a type label for “Security Context”. For instance, all the 3rd party applications will be labeled as “untrusted_app” and its private data will be labeled as “app_data_file”. The system processes and resources also have got a label accordingly.

Now when an application process wants to access a resource, the action go through the central authority, which look at the policies apply for subjects and objects as defined by the security context. SEAndroid has configured policies for all the processes, resources and operations. Thus, if and only if the MAC policy allow the operation it can be continued.

What makes the difference?

If an application somehow got the superuser or root access its UID will be changed to UID=0, yet the “Security Context” of the process is going to be remained as the “untruested_app”. Thus, even thought it run as root user, this process will not be allowed by the MAC policy to access resources with other context. Thereby, the potential damaged arise with a root user is reduced with this model.

Advantages with enforcing MAC

Capable of confining privileged process access to files and network resources and even processes running with superuser (root, UID=0) identity.
The malicious applications attempt to exploit kernel or system vulnerabilities has become challenging with this new security updates.

Yet we are not assumed be super enjoyed by the current state, because bad guys will always find a way to bypass these security mechanisms.

Until then,

Cheers !!! 🙂

Android Sandboxing and Permission Model

The Android OS versions 4.2 and earlier were based on the Discretionary Access Control (DAC) with Sandboxing model. I will explain here how the security was designed with this initial approach and shortcomings associate with DAC.

The Android kernel is a modified version of Linux Kernel in order to adopt the specific requirements of a mobile device. The multi-user system used in desktop Linux is adopted to Android as each application as a unique user. Thus the user based isolation is followed as application based isolation with Android . Consequently, each application has got a unique UserID (UID). With the isolation, each application is run within its own Dalivk VM and within its own process.

By default, an application process runs within this sandbox can only access its own private data. Thus inter-application communication is not allowed by default.

However, applications may required to access other system resources. For instance GPS, Network, Bluetooth, Contacts, etc. In order to access these resources application will have to go through the permission model. The owner of the system resources is the device user. According to the Discretionary Access Control (DAC), the owner of the resource controls access permissions related to it. Thus, a permission request list will be prompted at the installation time of the application for the user or the device owner to accept it or denied. Once the application granted the permissions they can have access to particular set of system resources.

Shortcomings of DAC

If somehow malicious application got the root access, which is also called su, superuer or UID=root, then the sandboxing model can be easily bypassed and it is no longer applicable. Because with this security model super user or root user has given absolute power over the device.Thus can access any system resource and even resources belong to the other 3-rd party applications. Moreover, it can perform all privilege actions including;

-read, write private files of any app.

-Can read, write or change permission bits of any file/directry

-Kill any process, change system configurations, starting/stopping system services

-Remove core system apps etc.

In the next post I will explain how the Security Enhanced Linux was adopted to Android to further improve the security of the OS.

Cheers !! 🙂