SEAndroid Security Mechanism overview and learning plan

Compared with iOS, Android is most criticized for its fluency and security. However, since 4.0, Android has spared no effort to improve its smoothness. Especially in the forthcoming L version, Dalvik is replaced with ART, and it is believed that it will become smoother and smoother. Android has not forgotten security. Android has introduced a SELinux-based security mechanism, called SEAndroid, to enhance system security since 4.3. Next we will give a brief introduction to SEAndroid and develop a learning plan.

Lao Luo's Sina Weibo: http://weibo.com/shengyangluo. welcome to the attention!

Before introducing the SEAndroid security mechanism, let's take a look at what security mechanism Android currently uses. In fact, we have already introduced the security mechanism of the Android System in the previous article about the debugging principle of NDK on a non-Root mobile phone. Therefore, here is a summary.

Before the SEAndroid security mechanism was introduced, the security mechanism of the Android system was divided into two levels: Application and kernel. Application-level security mechanisms are usually called Permission mechanisms. If an application needs to access sensitive or privileged system resources, it must apply in the AndroidManifest. xml configuration file and decide whether to grant the corresponding permissions during installation. After an application is installed, system services are generally used to indirectly use system sensitive or privileged resources. In this way, the system service first checks whether the application has applied for the corresponding permissions before representing the application to use these resources. If you have already applied for the application, you can directly release the application. Otherwise, the application will be rejected.

The kernel-level security mechanism is the traditional Linux UID/GID mechanism. In Linux, each user has a user ID and a user group ID (UID and GID respectively. In addition, processes and files in Linux also contain UID and GID. Linux manages permissions through UID/GID attributes of users, processes, and files.

We know that the first process started after the Linux kernel is started is called the init process. The Init process starts a login process and waits for the user to enter the user name and password to log on. Once the logon succeeds, a shell process is started. Then the shell process is responsible for executing USER commands. Note that during the above Startup Process,The init process is started as the root user, that is, the UID of the init process is 0, that is, root. By default, all processes started by the init process, that is, all the sub-processes fork, also run as root. Therefore. The UID of the login process in charge of logon is also 0. However, after a user enters the user name and password and successfully logs on to the system, the started shell process is no longer root, but a user who successfully logs on to the system. How is this done? It turns out that a process with root permission can change its identity through the system interface setuid. That is to say, the identity of the User shell process started by the login process at the beginning is actually root, but before it can execute USER commands, it has changed its UID to the UID corresponding to the login user through setuid. In this way, you can restrict the permissions of each user who successfully logs on to the system.

The various commands executed by the user in the shell process are either executed in the current process or in the started sub-process. Note: according to the above analysis, the sub-processes started by the User shell Process also run as logon users, in addition, the default UID and GID of the files created during the running process are the same as the UID and GID of the login user, and these files can only be accessed by the user. What should I do if a user wants to give some self-created files to another user for access? Linux divides file permissions into three types: read, write, and execute, which are represented by letters r, w, and x, respectively. Each file has three groups of read, write, and execute permissions, which are for the file owner, the file owner group, and all users except the owner and users in the owner group. In this way, if a user wants to give another user access to a self-created file, you only need to set other user permissions for the file accordingly.

We know that Android is a Linux kernel-based system, but it is not like a traditional Linux system and can be used only after users log on. However, the Android system has the same user concept as the traditional Linux system. However, these users do not need to log on or use the Android system. Specifically, the Android system maps every APK installed on the system to a different Linux user. That is to say, each APK has a corresponding UID and GID. These UIDs and gids are allocated by the system installation service PackageManagerService during APK installation.

We know that the process in which the APK runs is started by another system service ActivityManagerService. Before starting the APK process, ActivityManagerService first queries PackageManagerService for the UID and GID allocated during APK installation. With the UID and GID of the APK, ActivityManagerService sends a request for creating the APK process to another zygote process running as root. After the Zygote process receives the request, it will fork a sub-process to be used as the APK process created in the request. For detailed analysis of the APK process creation process, refer to the source code analysis document of the Process Startup Process of Android applications.

Note: As mentioned above, zygote processes run as root. Therefore, the sub-process fork, that is, the APK process, runs as root at the beginning. However, before the APK code can be executed, the APK process sets its UID as the UID allocated during APK installation through the system interface setuid. This process is similar to the process of starting the User shell Process through the login process in the traditional Linux system. In this way, we can ensure that every APK process runs with different identities, so as to ensure that there is no interference between them. This is the so-called sandbox, which is completely based on the Linux UID and GID.

The UID/GID Mechanism analyzed above can be described in Figure 1:

Figure 1 Security Mechanism of Android system based on UID/GID

What problems does this Linux UID/GID-based security mechanism have? Note: As mentioned above, when a user wants to authorize another user to access the file he created, he only needs to modify the access limit of the file. That is to say, in Linux, file permissions are controlled by the owner. Therefore, this permission Control method is called autonomous, and the formal English name is Discretionary Access Control, or DAC.

Ideally, the DAC mechanism is fine. However, serious security problems may occur in reality. For example, a user may accidentally change the permission bit of the file he created to allow access by other users. If this user is a privileged user and the file operated incorrectly is a sensitive file, serious security problems will occur. There are three ways to generate such misoperations:

1. the user executed the wrong command.

2. There are bugs in the program responsible for executing USER commands

3. The program responsible for executing USER commands is under attack

It can be seen that the DAC mechanism can only be avoided under ideal conditions, but in reality it is difficult to prevent! For example, the GingerBreak vulnerability is exploited to run the Android disk management daemon vold as root to obtain the root permission, so as to root the device.

Note that the DAC problem we mentioned above applies to the kernel-level Linux UID/GID mechanism, but also to the application-level Permission mechanism. The MasterKey vulnerability shows this problem to the fullest. We know that the MasterKey vulnerability can tamper with the APK without changing the signature. What are the consequences? If the tampered APK application has a special Permission, it means that the embedded malicious code can use these special Permission at will.

More seriously, the tampered APK is a system APK. The Permission of the Android system is divided into two types: one is that all APK can be applied for, and the other is that the system APK can apply. Only the system APK can apply for more sensitive Permission, such as the Permission -- android. permission. INSTALL_PACKAGES used to install the APK. This means that after a system APK with android. permission. INSTALL_PACKAGES is tampered, malicious code can install any malicious APK on the device.

In fact, the application-level Permission mechanism is also based on Linux UID/GID. When we are in the AndroidManfest. when applying for a Permission in the xml configuration file, the installation service PackageManagerService of the Android system not only records its application for a specific Permission (so that the APK can perform verification when calling the API interface that requires Permission ), the APK will also be added to a corresponding Linux user group. This is because in the Android system, not all privileged operations are indirectly performed through system services, such as network access. Once an APK applies for network access Permission, it will be added to the Linux network user group. In this case, the APK can access the network by creating a socket.

In this way, both the application-level Permission mechanism and the kernel-level Linux UID/GID mechanism will also be plagued by DAC problems. At this time, we need a more powerful security mechanism to ensure system security.

In the access control model, the MAC Mechanism is opposite to the DAC mechanism. The full name of MAC is Mandatory Access Control, which is translated as Mandatory Access Control. In MAC, the permissions of users, processes, or files are determined by management policies, rather than by their own permissions. For example, we can set A management policy that does not allow user A to grant user B access to the file F created by it. In this way, no matter how user A modifies the permission bit of file F, user B cannot access file F. This secure access model can effectively protect system security. SEAndroid, which we will introduce in this series of files, is a MAC mechanism.

In SEAndroid, each process and file is associated with a security context. This security context consists of four parts: User, role, type, and security level. Each part is separated by a colon. For example, u: r: t: s0 describes a SEAndroid security context. After each process and file are associated with a security context, the system administrator can establish a security access policy based on the security context to specify what processes can access what files.

The SEAndroid Security Mechanism 2 described above is shown in:

Figure 2 SEAndroid Security Mechanism

In Figure 2, the security context marked in red is SEAndroid. Here, u: r: unstructed_app: s0 describes the security context of the process in which the user-installed APK runs, while u: object_r: app_data_file: s0 describes the security context of the data file generated during running of the User-installed APK.

As shown in figure 2, SEAndroid security mechanisms coexist with the traditional Linux UID/GID security mechanisms, that is, they are used to restrict the permissions of processes at the same time. When a process accesses a file, it must first pass the DAC security check based on UID/GID, and then be eligible for entering the SEAndroid-based MAC security check. As long as one of the checks fails, the process's request to access the file will be rejected. The preceding security check process is as follows:

Figure 3 secure access process based on Linux UID/GID and SEAndroid

An example is provided to illustrate the above secure access process. When we want to download a file from a mobile phone to a computer, we use the adb pull command. When we execute the adb pull command, the daemon adbd on the mobile phone actually reads the specified file, and send the read content to the adb process running on the computer. Next, follow these steps to download the file/system/bin/gpsd from Samsung Note II with SEAndroid enabled to your computer.

1. Run the ls-l command to check whether the/system/bin/gpsd file exists on the mobile phone and its permission bit based on the traditional Linux UID/GID:

$ ./adb shell ls -l /system/bin/gpsd-rwxr-xr-x root     shell     2822268 2014-02-11 03:27 gpsd

From the command output, we can see that if you only consider the traditional Linux UID/GID security mechanism, the/system/bin/gpsd file on the mobile phone can be read by all users.

2. Run the adb pull command to download the/system/bin/gpsd file on the mobile phone:

$ ./adb pull /system/bin/gpsd ./gpsdfailed to copy '/system/bin/gpsd' to './gpsd': Permission denied

From the command output, we can see that the/system/bin/gpsd file on the mobile phone is not downloaded to the computer as expected, because "Permission denied" is not authorized enough.

3. Run the ls-Z and ps-Z commands to check the security context of the file/system/bin/gpsd and process adbd respectively:

./adb shell ls -Z /system/bin/gpsd-rwxr-xr-x root     shell             u:object_r:gpsd_exec:s0 gpsd$ ./adb shell ps -Z | grep 'adbd'u:r:adbd:s0                    shell     1978  1     /sbin/adbd

The command output shows that the security context of the file/system/bin/gpsd is u: object_r: gpsd_exec: s0, while that of the Process adbd is u: r; adbd: s0, so we can conclude that, on the Samsung Note II operating system, there must be an access policy that does not allow the security context to be u: r; adbd: the process access security context of s0 is u: object_r: gpsd_exec: s0.

From the above example, we can see that the files that can be accessed before SEAndroid is enabled will become inaccessible after SEAndroid is enabled! If we really need to access these files, for example, we need to package these files in our own ROM, is there any other way to access them? After reading the SEAndroid Security Mechanism series, you will find that the answer is yes, and it is implemented on the premise that the SEAndroid security policy is followed!

Another key aspect of SEAndroid security mechanism is worth mentioning. That is, the purpose of the SEAndroid security mechanism is not to completely prevent others from attacking our devices, but to minimize the damage suffered when our devices are under attacks. For example, SEAndroid security does not completely prevent our devices from being root, but it ensures that some sensitive files remain inaccessible after our devices are root, this protects our devices to the greatest extent possible. This is because as long as the program is compiled by humans, there are more or less bugs, or vulnerabilities, especially complex programs, which will be exploited by hackers, and successfully intrude into our system. This is hard to prevent. Of course, we do not mean that SEAndroid is useless to prevent the intrusion of devices. To some extent, SEAndroid can still increase the technical difficulty of intrusion.

Because SEAndroid has a lot of content, it is enough to write a thick and thick book to describe it. But in the following articles, Lao Luo does not plan to introduce it one by one, instead, I mainly focused on the key parts for detailed analysis. Therefore, I hope that students can read the following book and a thesis before continuing to learn the next article:

1. SELinux by Example-Using Security Enhanced Linux

2. Security Enhanced (SE) Android: Bringing Flexible MAC to Android

In fact, the next article about SEAndroid is based on the above paper to expand Security Enhanced (SE) Android: Bringing Flexible MAC to Android, the purpose is to explain the content of this thesis from the perspective of Android source code analysis.

Okay, no more nonsense. Next, we will go into the SEAndroid security mechanism as follows:

1. Analysis of basic concepts of SEAndroid Security Mechanism

2. File Security Context Analysis of SEAndroid Security Mechanism

3. Process Security Context Analysis of SEAndroid Security Mechanism

4. SEAndroid Security Policy Management Analysis

5. Analysis of Binde IPC Protection supported by SEAndroid Security Mechanism

6. Analysis of Property Protection supported by SEAndroid Security Mechanism

We hope that through the analysis of these six scenarios, we will have a deep understanding of the security mechanisms of the Android system to help us better protect the privacy and data on our mobile phones. Please stay tuned! For more information, refer to Lao Luo's Sina Weibo: http://weibo.com/shengyangluo.