Understanding Android security mechanisms

This article starts with the Android system architecture, analyzes Android's security mechanism and SE Android, and finally gives some Android security status and common security solutions.

1. Android system architecture

Android adopts a layered system architecture, which consists of the Linux kernel layer, hardware abstraction layer, system runtime library layer, application framework layer and application layer from bottom to top.

Android is based on the Linux operating system kernel and implements core system functions such as hardware device drivers, process and memory management, network protocol stack, power management, etc. In addition, Android has added some unique functions for mobile devices, such as low memory management LMK (Low Memory Killer), anonymous shared memory (Ashmem: Anonymous Shared Memory), and inter-process communication Binder mechanism. These enhancements further improve the security of Android in terms of memory management, inter-process communication, etc.

There was no hardware abstraction layer in previous versions of Android. Since hardware manufacturers do not want to disclose the source code of their device drivers, Google encapsulated the Linux kernel driver, shielded the underlying implementation details, and provided a unified interface to the upper layer, which is the hardware abstraction layer.

HAL (Hardware Abstraction Layer) specifies a unified interface for the application layer to read, write and configure the hardware layer. In essence, it divides the hardware driver into user space and kernel space, where the kernel driver runs in kernel space and HAL runs in user space. The Stub in the above figure exists in the form of a so library and can be understood as a proxy. The upper layer obtains the relevant Stub of HAL by calling the identifier and then obtains the corresponding operation.

The system runtime library consists of the system class library and the Android runtime. The system class library is basically written in C/C++, and its basic functions are as follows:

Of course, there is also Android NDK (Native Development Kit), which allows applications to be developed without relying on the Dalvik virtual machine. The Android runtime core library provides core APIs such as android.os, android.net, and android.media, while the Dalvik virtual machine relies on the Linux kernel to implement process isolation and thread scheduling management, security and exception management, garbage collection and other functions, and has been improved to adapt to the low-memory, low-processor speed mobile device environment.

The next layer is the application framework layer. A series of class libraries required by Android applications allow developers to quickly develop programs and implement personalized extensions through inheritance. For example, Activity Manager is responsible for creating the main thread ActivityThread, maintaining the Activity life cycle, and providing an interactive interface for the window.

The application layer is the applications that interact directly with users, such as SMS messages, image browsers, maps, and applications developed by developers.

2. Android security mechanism

Android integrates security design into every level of the system architecture, covering the system kernel, virtual machine, application framework layer, and application layer, striving to properly protect the security of user data, applications, and devices while being open. The Android security model mainly provides the following security mechanisms:

• Process sandbox isolation mechanism
• Application Signature Mechanism
• Permission declaration mechanism
• Access control mechanism
• Process communication mechanism
• Memory management mechanism

The process sandbox isolation mechanism allows Android applications to be assigned a unique user ID (UID) when they are installed and keep it permanently. The application and the Dalvik virtual machine it runs on run in an independent Linux process space, completely isolated from other applications.

In special cases, there can also be a mutual trust relationship between processes. For example, applications from the same developer or the same development organization can run in the same process space through the shared UID (Shared UserId) mechanism provided by Android.

The application signature mechanism stipulates that APK files must be digitally signed by developers in order to identify the application author and the trust relationship between applications. When installing the application APK, the system installer first checks whether the APK is signed. It can only be installed if it is signed. When the application is upgraded, it is necessary to check whether the digital signature of the new version of the application is the same as the signature of the installed application, otherwise it will be treated as a new application. Android developers may name the installation packages with the same name, and different signatures can be used to distinguish them, ensure that packages with different signatures are not replaced, and prevent malware from replacing installed applications.

Permission declaration mechanism: To obtain the right to operate on an object, you need to bind the permission to the operation of the object. Different levels require different authentication methods for applications to exercise permissions. Normal level can be used, Dangerous level requires user confirmation during installation, and Signature and Signatureorsystem levels must be used by system users.

Access control mechanism to ensure that system files and user data are not illegally accessed.

The process communication mechanism is implemented based on the shared memory Binder and provides lightweight remote process calls (RPC). The interface description language (AIDL) is used to define the interface and the type of exchanged data to ensure that the data in the inter-process communication will not overflow or cross the boundary.

Linux process perspective

Application perspective

The memory management mechanism is based on Linux's low memory management mechanism. It has designed and implemented a unique LMK, which can classify and group processes according to their importance. When memory is insufficient, it can automatically clean up the memory space occupied by the processes at the same level. At the same time, the introduced Ashmem memory mechanism enables Android to clean up the shared memory area that is no longer in use.

It is precisely because Android adopts a multi-layer architecture that it protects information security while ensuring the flexibility of an open platform.

3. SE Android

Android is a system based on the Linux kernel. Like traditional Linux systems, Android also has the concept of users. However, these users do not need to log in to use the Android system. The Android system maps each APK installed in the system to a different Linux user. In other words, each APK has a corresponding UID and GID, which are allocated by the system installation service PackageManagerService when the APK is installed. The Android sandbox isolation mechanism is based on Linux's UID and GID.

What kind of problems does this Linux UID/GID-based security mechanism have?

Linux divides file permissions into three types: read, write, and execute, represented by the letters r, w, and x respectively. Each file has three sets of read, write, and execute permissions, one for the file owner, the group to which the file owner belongs, and all other users except the owner and the users in the group to which the owner belongs. In this way, if a user wants to give a file he created to another user for access, he only needs to set the other user permission bits of the file accordingly. Therefore, in the Linux system, the file permission control is in the hands of the owner. Therefore, this permission control method is called autonomous, and its official English name is Discretionary Access Control, abbreviated as DAC.

Ideally, the DAC mechanism is fine. However, a user may accidentally modify the permission bits of a file he created to allow other users to access it. If this user is a privileged user and the file he mistakenly operates is a sensitive file, then serious security issues will arise. There are three ways for this misoperation to occur:

• The user executed the wrong command
• The program responsible for executing user commands has a bug
• The program responsible for executing user commands is under attack

Later, the Linux kernel adopted the necessary access control mechanism: SE Linux (Security-Enhanced Linux), which uses a mandatory access control MAC (Mandatory Access Control) policy implementation method to protect kernel security by limiting any process and user access to resources in the system. SE Android (Security-Enhanced Android) is a combination of Android and SE Linux. It was launched by the US NSA in 2012 to support the use of SE Linux on the Android platform.

There are currently three main policy mechanisms in the SE Android system:

• Install-time MAC
• Permission revocation
• Tag propagation

During installation, MAC checks the permissions of the application by looking up the MAC policy configuration. Permission revocation can revoke permissions for installed applications. This mechanism revokes certain permissions of the application by looking up the permission revocation list when the application is running. Permission label propagation is an application of taint tracking. The permissions of the Android system are mapped to the MAC policy configuration file as abstract labels.

The objects to be protected by the SE Android security mechanism are the resources in the system, which are distributed in various subsystems. In fact, there are many resources in the system that need to be protected, in addition to files, there are also processes, sockets, and IPC. SE Android is a complex security model, so this article will not further analyze it. For more information, please refer to: Analysis of the SEAndroid security mechanism framework (http://blog.csdn.net/luoshengyang/article/details/37613135)

4. Android application security solution

Android applications will encounter various security issues. It is particularly important to understand various security risks from a macro perspective and take appropriate defensive measures. So, what security issues do Android applications face?

• Virus
• Key information leakage
• APP repackaging
• Process hijacked
• Data hijacked during transmission
• Webview Vulnerability

Viruses, needless to say, are all malware. Some developers may not pay much attention to the leakage of key information. Although Java code can be obfuscated, the creation method of several major components of Android is dependency injection, so it cannot be obfuscated. Moreover, some commonly used decompilation tools such as apktool can easily restore the plaintext information in Java, and the library information in native can also be obtained through objdump or IDA. Therefore, once there is plaintext sensitive information in Java or native code, it is basically unsafe. Repackaging is to re-add malicious code logic after decompilation and repack an APK file. The process is hijacked. Generally, the process is hooked by process injection or debugging, changing the logic and order of program operation, so as to obtain the memory information of the program operation. Hook needs to obtain root permissions or the same permissions as the hooked process. If the phone is not rooted, the possibility of being hijacked is still small. Data is hijacked during transmission, generally because the data is transmitted in plaintext or HTTPS is not used. Webview vulnerabilities are generally caused by JS injection.

In reality, there may be more problems than those mentioned above. In general, we should deal with common security issues in Android development from the following aspects:

• Application permission control. By controlling the permissions of applications, malicious applications are prevented from causing damage to the system. Measures taken include the reasonable use of system built-in permissions and application customized permissions.
• Application Signature: Sign the application with a digital signature.
• Application hardening. Application hardening includes four modules: virus scanning, anti-injection, anti-debugging, and anti-tampering. Currently, there are many application hardening solutions in the industry, such as 360 application hardening, Tencent Cloud application hardening, Baidu application hardening, etc.
• Static code analysis: Use the static code analysis tool lint to monitor security risks and optimize the code.
• Firewall. Install a firewall on your Android device if necessary to prevent remote network attacks.
• Data storage encryption: Use encryption to protect sensitive application data, such as using SQLCipher to encrypt SQLite databases.
• Security points for application component development. Security measures that should be taken at the code level for components such as Activity, Service, Content Provider, Broadcast Receiver, etc. Each of them can be opened through implicit Intent, so if these components are not open to the public, they must be marked as exported as false in AndroidManifest to prohibit other programs from accessing our components. For components that need to interact with the outside world, access rights control should be added, and the transmitted data needs to be securely verified.

refer to:

• 《Analysis and Application Practice of Android Security Mechanism》
• A brief introduction to SEAndroid security mechanism and study plan

http://blog.csdn.net/luoshengyang/article/details/35392905

• Android application security status and solutions (learning materials)

http://blog.csdn.net/yzzst/article/details/46471277