Seandroid Safety mechanism Brief introduction and learning Plan

Android is most criticized for its fluency and security compared to iOS. However, from 4.0 onwards, Android spares no effort to improve its fluency. Especially in the upcoming L release, with art replacing Dalvik, I believe it will be more and more fluent. As for security, Android has not forgotten. Starting with 4.3, Android introduced a set of SELinux-based security mechanisms called seandroid to enhance system security. Next we will briefly introduce the seandroid and make a study plan.

Lao Luo's Sina Weibo: Http://weibo.com/shengyangluo, welcome attention!

Before introducing the Seandroid security mechanism, let's look at what security mechanisms are currently being used by Android. In fact, we've covered the security mechanisms of Android in the article on the security mechanism of Android from the NDK's debugging principles on non-root phones. Therefore, here is the main summary.

Before introducing the Seandroid security mechanism, the security mechanism of Android system is divided into two levels of application and kernel. The application-level security mechanism is what we usually call the permission mechanism. An application that requires access to some system-sensitive or privileged resources must be requested in the Androidmanifest.xml configuration file and determined by the user at the time of installation to grant the appropriate permissions. After an application is installed, it is generally used to indirectly use system-sensitive or privileged resources through system services. This allows the system service to check whether the app has requested the appropriate permissions before using these resources on behalf of the app. If you have already applied, then direct release, otherwise, will refuse to execute.

The kernel-level security mechanism is the traditional Linux uid/gid mechanism. In Linux, each user has a user ID, and there is also a user group ID, which is referred to as UID and GID, respectively. In addition, the Linux system's processes and files also have the concept of UID and GID. Linux is through the user, process, file Uid/gid properties to manage the rights.

We know that when the Linux kernel starts to complete, the first process that starts is called the init process. The init process then initiates a login process, waiting for the user to enter a user name and password to log in. Once the login is successful, a shell process is started. The shell process is then responsible for executing the user's commands. Note that during the startup process ,the INIT process was initiated as root, which is the init process uid 0, root. By default, all processes initiated by the Init process, that is, all child processes that are forked out, are also run as root. So. The UID of the login process responsible for logging in is also 0. However, when the user enters the user name and password, and the login succeeds, the shell process started is no longer root, but the user who successfully logged into the system. How is this done? It turns out that a process with root privileges can change its identity through the system interface setuid. That is, the user shell process initiated by the login process is also rooted at the beginning, but before it can execute the user's command, it has changed its UID to the UID of the logged-on user by setuid. This allows you to restrict the permissions of each user who successfully log in to the system.

The various commands that the user then executes in the shell process are either executed in this process or executed in a child process that is started. Note that, according to our analysis above, the child processes initiated by the user shell process are also run as logged-in users, and the default UID and GID of the files created during the run of these processes are also consistent with the UID and GID of the logged-on user, and the files can only be accessed by the user themselves. What if a user wants to give some of the files they create to another user? Linux divides the file's permissions into three reads, writes, and executes, denoted by the letters R, W, and X, respectively. Each file has three sets of read, write, and Execute permissions, respectively, for the owner of the file, the group to which the file owner belongs, and all other users except the owner and the user who owns the group. This way, if a user wants to give another user access to a file they have created, then it is only necessary to set the other user permissions of the file accordingly.

We know that Android is a Linux kernel-based system, but it is not like a traditional Linux system that requires users to log in before they can use it. However, the Android system has the same user concept as a traditional Linux system. Only these users do not need to log in or use the Android system. Specifically, the Android system maps every APK installed in the system to a different Linux user. In other words, each apk has a corresponding UID and GID. These UID and GID are assigned by the system installation Service Packagemanagerservice when the APK is installed.

We know that the process that the APK runs on is initiated by another system service Activitymanagerservice. Activitymanagerservice before starting the APK process, the packagemanagerservice is queried for the UID and GID assigned to the APK installation. With the UID and GID of the APK, Activitymanagerservice sends a request to create the APK process to another zygote process running as root. After the zygote process receives the request, it will fork out a child process to create the APK process as requested. A detailed analysis of the APK process's creation process can be found in the source code Analysis article of the Android application process startup process.

Note that, as we mentioned above, the zygote process is running as root. Therefore, the sub-process that it fork out, that is, the APK process, is also running as root at the very beginning. However, the APK process will use the system interface setuid to set its UID to the UID assigned to the APK installation before it can execute the APK code. This process is very similar to the process of booting a user shell process from a traditional Linux system through the login process. In this way, each apk process can be guaranteed to run in a different identity, ensuring that there is no interference with each other. This is the so-called sandbox, which is entirely based on the UID and GID of Linux.

The uid/gid mechanism of the above analysis can be described by the diagram:

Figure 1 Android system based on uid/gid security mechanism

What is the problem with this security mechanism based on Linux uid/gid? Note As we mentioned earlier, when a user wants to grant another user access to a file that he or she creates, it just needs to modify the access permission bit of the file. In other words, in a Linux system, the permissions of the file are controlled in the owner's hands. Therefore, this type of authority control is called autonomous, the official English name is discretionary Access control, referred to as the DAC.

In the ideal case, the DAC mechanism is not a problem. In reality, however, serious security problems can arise. For example, a user might accidentally modify the permission bit of a file he creates to allow other users to access it incorrectly. If the user is a privileged user and the file it is manipulating is a sensitive file, then a serious security issue arises. There are three ways to produce this type of mis-operation:

1. The user executed the wrong command

2. The program responsible for executing user commands has a bug

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

This shows that the DAC mechanism can only be ideal without problems, but in reality it is impossible! For example, the Gingerbreak vulnerability would be to root the device by running the Android Disk Management daemon Vold as root by attacking.

Note that the DAC problem we mentioned above is for the kernel-level Linux uid/gid mechanism, but the same applies to the application-level permission mechanism. The problem is manifested through masterkey loopholes. We know that the Masterkey vulnerability could tamper with the apk without changing the signature. What will be the consequences? If the tampered APK application has a special permission, it means that the embedded malicious code can arbitrarily use these special permission.

What's more serious is that the tampered apk is a system apk. There are two types of permission for Android, one for all apk applications, and the other for system apk to apply. Only the system apk can apply permission more sensitive, such as the permission--android.permission.install_packages to install APK. This means that when a system with Android.permission.INSTALL_PACKAGES apk is tampered with, malicious code can install any malicious apk on the device.

In fact, the application-level permission mechanism is also based on the Linux uid/gid. When we apply for a permission in the APK's androidmanfest.xml configuration file, the Android installation service Packagemanagerservice except that it has a corresponding permission (so that the APK call requires permission API interface), the APK is also added to the appropriate Linux user group. This is because in an Android system, not all privileged operations are performed indirectly through system services, such as network access. Once an APK requests a network access permission, it will be added to the Linux network user group, when the APK can create a socket to access the network.

Thus, in Android, both the application-level permission mechanism and the kernel-level Linux uid/gid mechanism are also plagued by DAC problems. At this point we need a more robust security mechanism to ensure the security of the system.

In the access control model, the MAC mechanism is relative to the DAC mechanism. The full name of the MAC is mandatory access control, which translates to mandatory access controls. In the MAC mechanism, the user, process, or file permissions are determined by the management policy, not by their own discretion. For example, we can set up a management policy that does not allow user A to grant User B access to the file it creates. This way, User B cannot access file F regardless of how user a modifies the permission bit of the file F. This secure access model is a powerful way to protect the security of your system. The seandroid we're going to cover 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 of the user, role, type, security level, each separated by a colon. For example, U:r:t:s0 describes a seandroid security context. Once each process and file are associated with a security context, the system administrator can establish a secure access policy based on these security contexts to specify what kind of files the process can access.

The seandroid security mechanism described above is shown in 2:

Figure 2 Seandroid security mechanism

In Figure 2, the red callout is the seandroid security context. Where U:r:unstructed_app:s0 describes the security context of the process in which the user installed the APK is running, and U:object_r:app_data_file:s0 describes the security contexts of the data files that are generated during the run of the user-installed apk.

As you can see from Figure 2, the seandroid security mechanism is associated with the traditional Linux uid/gid security mechanism, which means that they are also used to constrain the permissions of the process. When a process accesses a file, it must first pass a Uid/gid-based DAC security check and then qualify for a seandroid-based Mac security check. As long as one of these checks does not pass, the process's request to access the file is rejected. The above security check procedure is shown in 3:

Figure 3 Secure access process based on Linux uid/gid and seandroid

We use an example to illustrate the security access process described above. When we want to download a file from our phone to our computer, we use the ADB pull command. When we execute the ADB pull command, it is actually the daemon adbd on the phone that reads the specified file and sends the read out to the ADB process running on the computer. Next, we'll try to download the files from the Seandroid-enabled Samsung Note II/SYSTEM/BIN/GPSD to the computer by following these steps.

1. Execute the ls-l command to check that the/SYSTEM/BIN/GPSD file exists on the phone and that it is based on the traditional Linux uid/gid privilege bit:

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

From the output of the command, you can see that if you only consider the traditional Linux uid/gid security mechanism, the/SYSTEM/BIN/GPSD file on the phone is readable by all users.

2. Execute the ADB pull command to download the/system/bin/gpsd file on your phone:

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

As you can see from the output of the command, we did not download the/system/bin/gpsd file on the phone as expected because of "Permission denied", which is not enough permissions.

3. Check the security context of the file/system/bin/gpsd and process adbd, respectively, through the ls-z and Ps-z commands:

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

As you can see from the output of the command, the security context for the file/system/bin/gpsd is U:object_r:gpsd_exec:s0, and the security context for the process adbd is u:r;adbd:s0, so we can conclude that on the system that Samsung Note II is running , there must be an access policy that does not allow a security context for a U:R;ADBD:S0 process to access a security context file that is u:object_r:gpsd_exec:s0.

From the above example, it can be seen that before enabling Seandroid, the original file can be accessed, until the seandroid is enabled, it becomes inaccessible! If we do need to access these files, for example we need to package these files in our own production ROM, then is there any other way to access it? Once you've read the Seandroid Security-series article, you'll find the answer is yes, and it's done with the seandroid security policy!

There is also a key point that is worth mentioning about the seandroid security mechanism. That is, the purpose of the seandroid security mechanism is not to completely eliminate attacks on our devices, but to minimize the damage to our devices when they are attacked. For example, seandroid security does not completely prevent our device from being rooted, but it ensures that after our device is rooted, some sensitive files remain inaccessible, so that we can protect our devices to the fullest extent possible. This is because, as long as the program is written by humans, there are more or less bugs, or loopholes, especially complex programs, which will be exploited by hackers and successfully hacked into our system. This is impossible to guard against. Of course, we are not saying that seandroid is useless to prevent the device from being invaded, and it can increase the technical difficulty of intrusion to some extent.

Because of the seandroid content, enough to write a very thick and thick book to describe, but in the next article, Lao Luo is not intended to be introduced one by one, but mainly to grasp the key part of the detailed analysis, so I hope that students continue to learn the next article, You can read one of the following books and a paper:

1. SELinux by example-using Security enhanced Linux

2. Security Enhanced (SE) android:bringing flexible MAC to Android

In fact, the next article that introduces Seandroid is based on the paper above that security enhanced (SE) android:bringing flexible MAC to Android unfold, The aim is to explain the content of this paper from the angle of source analysis of Android system.

All right, no more nonsense. Next we will follow the following scenario to learn more about Seandroid security:

1. Basic concept analysis of seandroid security mechanism

2. File security context analysis for seandroid security mechanisms

3. Process security context analysis for the seandroid security mechanism

4. Security Policy Management Analysis of seandroid security mechanism

5. Binde IPC Protection Support analysis of seandroid security mechanism

6. Property protection support analysis of seandroid security mechanism

We hope that through the analysis of these six scenarios, we have a deep understanding of the security mechanism of Android system to help us better protect the privacy and data on the phone, so stay tuned! More information can be paid attention to Lao Luo's Sina Weibo: Http://weibo.com/shengyangluo.