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 !!! 🙂