This article will show you all the security mechanisms of the Android system

With the development of mobile Internet, Android devices have become an important part of users' daily lives. However, as an open source system, Android also faces many security challenges, such as malware, permission abuse, data leakage, etc. Therefore, Google has introduced a variety of security mechanisms in the Android system to ensure the integrity of the system and the security of user data. This article will explore Android's system security mechanisms in depth, including SELinux, permission management, data encryption, and Verified Boot, and analyze common security risks and countermeasures.

Android System Security Overview

Android's security architecture mainly consists of the following key parts:

• Application layer security: Use permission management mechanism to prevent malicious access between applications.
• System-level security: Use SELinux, process isolation and other means to enhance security.
• Data security: Use file encryption and Keystore to protect user data.
• Boot security: Ensure the system has not been tampered with through Verified Boot.

Analysis of key safety mechanisms

1. SELinux mandatory access control

SELinux (Security-Enhanced Linux) is a mandatory access control (MAC) mechanism introduced in Android 4.3. It is used to limit the permissions of processes and prevent malicious programs from obtaining core system resources.

SELinux operating modes

• Permissive mode: Only logs security policy violations without actually blocking them.
• Enforcing (enforcement mode): strictly enforce security policies and prevent violations.

SELinux in Action Example

When a malicious application tries to access the data of the system_server process, if the SELinux rules do not allow it, the access request will be denied and recorded in the log:

 avc: denied { read } for pid=1234 comm="malicious_app" name="system_data" dev="mmcblk0p1" ino=12345 scnotallow=u:r:untrusted_app:s0 tcnotallow=u:object_r:system_data_file:s0 tclass=file

2. Permission Management

Android uses a permission mechanism to control applications' access to system resources, which can be divided into the following categories:

• Normal Permissions: such as INTERNET, no user authorization is required.
• Dangerous Permissions: such as READ_CONTACTS, which require user consent.
• Signature Permissions: Only available to apps signed by the same developer.

Runtime permissions

Starting from Android 6.0 (API 23), dangerous permissions need to be requested at runtime:

 if (ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA) != PackageManager.PERMISSION_GRANTED) { ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.CAMERA}, REQUEST_CODE); }

3. Data encryption

Android uses multiple encryption mechanisms to ensure data security.

File-Based Encryption (FBE)

Android 7.0 introduced FBE, which encrypts data based on user identity. Data of different users is encrypted with different keys to prevent cross-user access.

Keystore

Keystore provides secure storage for API keys and encryption keys to prevent keys from being stolen by malware. For example, use Keystore to generate an AES encryption key:

 KeyGenerator keyGenerator = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore"); keyGenerator.init(new KeyGenParameterSpec.Builder("MyKeyAlias", KeyProperties.PURPOSE_ENCRYPT | KeyProperties.PURPOSE_DECRYPT) .setBlockModes(KeyProperties.BLOCK_MODE_GCM) .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE) .build()); SecretKey key = keyGenerator.generateKey();

4. Verified Boot

Verified Boot verifies system integrity through chained trust, preventing attackers from tampering with system files.

How it works

• The bootloader verifies the integrity of the boot partition.
• Boot partition verifies system partition.
• If tampering is detected, the system will enter "restricted mode" or refuse to boot.

AVB (Android Verified Boot)

Android 8.0 introduces the AVB mechanism to further enhance trusted boot. It ensures that the device has not been tampered with at all stages from boot to system operation, and that the running code is trustworthy. The core goal of AVB is to prevent malware from tampering with system partitions, protect user data, and improve the overall security of the device.

picture

Common security risks

Although Android has adopted many security mechanisms, there are still security risks:

1. Root Bypass

Root tools may use system vulnerabilities to bypass SELinux and permission management. For example, some exploits can modify the system_server process permissions by escalating privileges to obtain root permissions.

2. Privilege Escalation Vulnerability

An attacker can escalate privileges through kernel vulnerabilities or userspace vulnerabilities, such as CVE-2019-2215 (Use-After-Free vulnerability).

Summarize

Android's system security mechanism covers multiple levels, from SELinux mandatory access control, permission management to data encryption and Verified Boot, building a relatively complete security system. However, the security mechanism is not omnipotent, and attackers can still break through security protection through means such as vulnerability exploitation and social engineering. Therefore, developers and security researchers need to continue to pay attention to Android's security updates to enhance the system's protection capabilities.

In actual applications, developers can take the following measures to improve security:

1. Follow the principle of least privilege and only request necessary permissions.
2. Enable SELinux Enforcing mode to prevent malware from accessing system components.
3. Use the Keystore API to protect sensitive data and prevent key disclosure.
4. Update systems and patches in a timely manner to fix known security vulnerabilities.

Through these measures, we can effectively improve the security of the Android system, reduce the attack surface, and ensure the security of user data.

This article is reprinted from the WeChat public account "Happy Programmer". You can follow it through the QR code below. To reprint this article, please contact the Happy Programmer public account.