Security Controls in the Android Operating System (OS)

As part of the Android Application Security series, we are going to understand the security controls provided by Android OS (operating system) to protect the applications that are running on the device. Without these security controls in place, the data on the devices or transmitted by apps could be easily accessed by other apps or devices in the network. 

Before getting started, if you haven't read the first part of this series, I highly recommend reading it.

Before the rise of mobile devices, OS (operating system) security primarily focused on desktop computers, servers, and enterprise systems. Below are a few important controls implemented by OS. 

• Role-based access control (RBAC) and multi-user environments
• Network security to protect against DoS (Denial of Service) attacks, firewalls, antivirus, etc.
• Memory protection mechanisms to prevent buffer overflow (BoF) attacks, including DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization)
• File system security, including file permissions, file encryption, and disk encryption

Like these, different operating systems (Windows, Linux, Unix, Solaris, etc.) came up with several protection mechanisms by the time the mobile device era started. 

Mobile operating systems like Android and iOS started building mobile platforms by keeping these security controls. But still, in the earlier days, there were not many controls available on Android/iOS. They added the required controls pretty fast. 

Defense in Depth

Android security followed a defense-in-depth model to protect confidentiality, integrity, and availability (CIA). In the defense-in-depth approach, they have implemented several controls. Below are important:

• Android Users and Groups
• SELinux (Security Enhanced Linux)
• Permissions
• DEP, ASLR, etc
• SECCOMP
• App Sandbox
• Device Encryption
• Trusted Execution Environment (TEE)

The below list shows the improvements:

• Android 4.2 (API level 16) in November 2012 (introduction of SELinux)
• Android 4.3 (API level 18) in July 2013 (SELinux became enabled by default)
• Android 4.4 (API level 19) in October 2013 (several new APIs and ART introduced)
• Android 5.0 (API level 21) in November 2014 (ART used by default and many other features added)
• Android 6.0 (API level 23) in October 2015 (many new features and improvements, including granting; detailed permissions setup at runtime rather than all or nothing during installation)
• Android 7.0 (API level 24-25) in August 2016 (new JIT compiler on ART)
• Android 8.0 (API level 26-27) in August 2017 (a lot of security improvements)
• Android 9 (API level 28) in August 2018 (restriction of background usage of mic or camera, introduction of lockdown mode, default HTTPS for all apps)
• Android 10 (API level 29) in September 2019 (access location "only while using the app," device tracking prevention, improve secure external storage)

Android App Security Features

Apart from these regular operating system controls, Android will provide the following security controls for an app running on Android OS. 

• App Sandboxing
• Permissions
• App Signing
• Keystore

App Sandboxing

Application sandboxing is one of the critical features provided by Android OS. It allows you to keep your data or process in a sandbox environment and won't allow other apps (malicious or normal). This will protect data inside the app. 

Linux-based security mechanisms, file system permissions, and runtime restrictions ensure that apps operate independently without unauthorized access to system resources or other apps. As we have seen in the previous article, the application data will be in the /data/data/ folder.

barbet:/data/data # ls
alpha.mydevices.in                                               com.google.android.apps.internal.betterbug
android                                                          com.google.android.apps.maps
android.auto_generated_rro_product__                             com.google.android.apps.messaging
android.auto_generated_rro_vendor__                              com.google.android.apps.nbu.files
android.autoinstalls.config.google.nexus                         com.google.android.apps.nexuslauncher
android.myshop.release                                           com.google.android.apps.photos

While installing the app on the device, the OS generates a unique code for the app and performs Base64 encoding on it. Then, create a folder name with that. Before Oreo, Android used a normal package name. But, after Oreo, Android started creating unique folder names to provide better unique names and security. 

barbet:/data/data # ls /data/app/
~~-09YTqMLYcn7FwT_vUBMOA==  ~~AK82hlWJIrFJf2cgbVRR3g==  ~~KvDoAodAiN0LD2UILHaetg==  ~~QOHLg7084hj8rNBvVYHYeg==  ~~gndAwbGNwp0mzMUTP556Sg==  ~~uoiS3mnMS4L3QfsR0uwqPA==
~~1GBi7xnRkkWDvnnXZaZHPQ==  ~~CeEiKh1AzGKF9Y9x76zs5A==  ~~L6i9NBP_E_AWx0xH9YqlTA==  ~~Qdd7zzYfVflMMaAGBQ8ZMw==  ~~hfTx_FzGJ_VJ0ixIGudCZg==  ~~vD_rgwS55aJpet3R2BZmPw==
~~21GSMTYpPGbmfo2J0pktSQ==  ~~DBpe3alZqtqzhzbsPsiIMg==  ~~LBtCo2pnLZRNu_bG1KmjIQ==  ~~RBZl37VivVPAu4ovxRpX3Q==  ~~j4XtEDAErb_X2lAXlXgHvA==  ~~vM80pt2jacKCCUjiKCh9UA==
~~2WLzdU9faNRtTWTH9veuiw==  ~~DbXAPRM1sjmHHYWO4BER0w==  ~~MSw6x4JmrypY_E2G71wchw==  ~~TU9zLt0XNPdlo26BAr_aIw==  ~~jMmQ6FtaqWQ_HmLd85T_pQ==  ~~vqp1MM_cfzUyOEucWflhDg==
~~2eFNNEK0J5-bfUpxfOnNGw==  ~~DxOUwLmCdEqkM_2UXXDo-g==  ~~Ma7GQ-mgVbviiz1NVUECiQ==  ~~U4EbGiTCND1jmF3wZdkRYw==  ~~j_HCTKzJrbJ7OVjNxm45Dw==  ~~vvRXqZtaVpDagq6KtxMXQg==
~~2zp6xn7KRnCY7KP-eL1uDw==  ~~En-qhd9ZYwBn2WR5JTYBcg==  ~~MhXEKEfd9PxBFoHtcXMAMA==  ~~WmA6pQdCwVlAa5kxwhRaYA==  ~~kAhQi7P28dfkIgqlK8Ytmw==  ~~wTH3BJqtk3T8SePQmQw3Zg==

Permissions

Android permissions are critical controls that dictate how an app interacts with system resources, such as accessing the internet, reading contacts, or accessing files on the device. Apps must declare required permissions in the AndroidManifest.xml file. Users are informed about the requested permissions during installation (or runtime for dangerous permissions) and can decide whether to grant them, ensuring transparency and control over app behavior.

• Install time permissions
• Normal Permissions
• Special Permissions
• Permission groups

App Signing

To install any app (APK file) on the device, it has to be digitally signed. Without proper signature verification, the OS won't allow the installation. This helps the user to see the authenticity of the developer or organization. 

Keystore

A Keystore in Android is a secure container used to store cryptographic keys and certificates. It plays a vital role in app signing, securing sensitive data, and enabling cryptographic operations like encryption, decryption, and authentication.

Conclusion

We can see how these controls help Android applications protect themselves from malicious apps in upcoming posts.