Seandroid Safety mechanism Brief introduction and learning Plan

Compared to iOS. Android is most criticized for its fluency and security.

However, from the beginning of 4.0, Android spared no effort to improve its fluency.

Especially in the upcoming L version number, with art replaced by Dalvik, I believe it will be more and more fluent. As for security, Android has not forgotten.

Since 4.3, Android has 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 we introduce 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.

So. Here is a summary of the main.

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 hypothesis requires access to some system-sensitive or privileged resources, which must be applied in the Androidmanifest.xml configuration file, and the user decides whether or not to grant the appropriate permissions when installing.

After the app has been installed. System-sensitive or privileged resources are typically used indirectly through system services. This is before the system service uses these resources on behalf of the application. You will first check to see if the app has already applied the appropriate permissions.

If you have already applied, then direct release. Otherwise, it refuses to run.

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 is started, the first process started is called the init process. The init process then launches a login process, waiting for the user to enter username and password logins. Once the login is successful. A shell process is started. The shell process is then responsible for running the user's commands. Attention. During the start-up 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 the sub-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 username and password, and the login succeeds, the shell process started is no longer root, but the user who successfully logs 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. Other words. The user shell process initiated by the login process is also rooted at the beginning, but before it can run the user's command, it has changed its UID to the UID of the logged-on user by setuid. This will allow you to limit the permissions of each user who successfully logged into the system.

The various commands that the user then runs in the shell process are either running in this process or running in a child process that is started. Note that, according to our analysis above, the child processes initiated by the user shell process are run as the logged-on user, and the default UID and GID of the files created during the process are also consistent with the UID and GID of the logged-on user, and these files can only be visited by the user themselves.

Suppose a user wants to give another user access to a file they have created, what should they do? Linux divides the file's permissions into three types: read, write, and run. denoted by the letters R, W, and X, respectively.

Each file has three sets of read, write, and run permissions, each of which is for all of the files, the groups to which all the files belong, and all other users except the entire group of users.

This assumes that a user wants to give another user access to a file that he or she creates. Then it is only necessary to set the other user rights of this file in the corresponding position.

We know that Android is a Linux kernel-based system. But it's not like a traditional Linux system. Users need to log in after the ability to use. However, the Android system is the same as the traditional Linux system as a real user concept. Only these users are not required to log in and can use the Android system.

Specifically speaking. It is the Android system that 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 UID and GID assigned to the APK installation will be queried to Packagemanagerservice first.

With the UID of the apk and after GID. Activitymanagerservice sends a request to create the APK process to another zygote process running as root.

After the zygote process receives the request. Will fork out a sub-process to create the APK process as requested. The specific analysis of the APK process's creation process can be described in the source code analysis of the Android application process startup process.

Note that we mentioned above. The zygote process is run as root. Therefore, the sub-process that it fork out, that is, the APK process, is also running as root at the start. Just before the APK process can run the APK code, it will set its UID to the UID assigned to the APK installation via the system interface setuid. 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 above analysis of the UID/GID mechanism 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? Take note of what we mentioned earlier. When a user wants to grant another user access to the file they created, it just needs to change the permission bit of the file. That is, in a Linux system, the permissions of the file are controlled in the hands of the entire person.

Therefore, this type of 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. However, in reality. can cause serious security problems.

For example, a user might accidentally change the permission bit of a file he created to consent to another user's access.

Suppose this user is a privileged user. And the file it is manipulating is a sensitive file, which can cause serious security problems.

There are three ways to produce this type of misoperation:

1. The user ran the wrong command

2. The program responsible for running the user command has a bug

3. The program responsible for running 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 gingerbread 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 said above is for the kernel-level Linux uid/gid mechanism. However, the same permission mechanism applies to the application level. 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 freely use these special permission.

What's more serious is that the tampered apk is a system apk. There are two types of Android permission, one is all apk can apply, the other is the system apk talent enough to apply. Only the system apk talent enough to apply for the permission more sensitive. For example, to install the APK permission--android.permission.install_packages. This means that a system with Android.permission.INSTALL_PACKAGES apk is tampered with. Malicious code will be able to install random malicious apk on the device.

In fact, the application level of the permission mechanism is 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 will record that it has a corresponding permission (so that the APK call requires permission API interface), the APK is added to one of the corresponding Linux user groups. This is because in an Android system, not all privileged operations are run indirectly through system services, such as Internet access.

Once an APK asks for a network access permission, it will be added to the Linux network user group. The APK will then be able to access the network by creating a socket.

Thus, in Android, whether the application-level permission mechanism or the kernel-level Linux uid/gid mechanism, the same will be affected by the DAC problem.

At this time, we need a more powerful 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 the mandatory interview controls.

In the MAC mechanism, the user, process, or file permissions are determined by the management policy, not by their own discretion. Like what. We were able to set up a management policy that would not allow user A to grant User B access to the file it created. This way, no matter how user a changes the permission bit of the file F. User B is not able to access the file F. This security 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. When each process and file are associated with a security context. System administrators can develop a security access policy based on these security contexts to define what processes can access what files.

The above-described description of the seandroid security mechanism 2 saw:

Figure 2 Seandroid security mechanism

In Figure 2, the red callout is the seandroid security context. Of U:r:unstructed_app:s0 describes the security context of the process in which the user-installed apk is running, while the U:OBJECT_R:APP_DATA_FILE:S0 description describes the security contexts of the data files that are generated during the run by the user-installed apk.

As you can see from Figure 2, the seandroid security mechanism is co-existing with the traditional Linux uid/gid security mechanism. Other words. They are used at the same time to constrain the permissions of the process.

When a process visits a file, the first step is to pass the Uid/gid-based DAC security check and then qualify for the Seandroid-based Mac security check. If only one of the checks does not pass, the process's request to access the file will be rejected. The above-mentioned security check procedure 3 sees:

watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqvthvvc2hlbmd5yw5n/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/ Dissolve/70/gravity/southeast "/>

Figure 3 Security interview process based on Linux uid/gid and seandroid

We use a sample to illustrate the security interview process described above.

When we want to download a file from our phone to our computer, we use the ADB pull command. When we run the ADB pull command. The specified file is actually read by the daemon adbd on the phone. and send 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 as follows.

1. Run the ls-l command to check that the/SYSTEM/BIN/GPSD file exists on the phone. And it's 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

As you can see from the output of the command, consider only the traditional Linux uid/gid security mechanism. The/system/bin/gpsd file on the phone is readable by all.

2. Run 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

We can see from the output of the command that 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

From the output of the command can be seen. The security context for file/system/bin/gpsd is u:object_r:gpsd_exec:s0. The security context for the process adbd is u:r;adbd:s0. So we can conclude. On a system operated by Samsung Note II. There must be an access policy that does not agree with the security context for the U:R;ADBD:S0 process to access the security context file for U:object_r:gpsd_exec:s0.

As you can see from the example above, before you enable seandroid. Documents that could have been interviewed. After you have enabled seandroid, you will not be able to access the interview!

Let's say we do need to access these files, for example, we need to package these files in our own ROM. So is there any other way to access it? After reading the seandroid security mechanism of this series of articles. You'll find the answer is yes. And it is implemented under the premise of seandroid security Policy!

Another key point about the seandroid security mechanism is worth mentioning. That is the purpose of the seandroid security mechanism is not to completely stop others from attacking our devices. But to ensure that our equipment is under attack. To the least amount of damage suffered. Like what. The seandroid security mechanism does not completely prevent our devices from being rooted. But it will ensure that our device is rooted. Some sensitive files are still inaccessible, so that we can protect our equipment to the fullest extent possible. This is because only the program is written by humans. There are more or less bugs. Or a loophole, especially a complex program. It 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.

As there is a lot of content in seandroid, enough to write a very thick and very thick book to describe the narrative, but in the next article, Lao Luo does not intend to introduce each. Instead of focusing on the key parts for specific analysis, I hope that students will continue to study the next article. Be able to read one of the following books and an essay:

1. SELinux by example-using Security enhanced Linux

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

In fact, the next introduction to Seandroid's article is based on the above paper to the security Enhanced (SE) android:bringing flexible MAC to Android expansion, The aim is to explain the content of this paper from the point of view of the source code analysis of Android system.

All right. In accordance with the usual practice, we follow the following scenario to learn more about the Seandroid security mechanism:

1. seandroid Security Mechanism Framework analysis

2. File security context analysis for seandroid security mechanisms

3. Process security context analysis for the seandroid security mechanism

4. Binde IPC Protection Support analysis of seandroid security mechanism

5. Property protection support analysis of seandroid security mechanism

We hope that through the analysis of these five scenarios, we have a deep understanding of the security mechanism of Android system. To help us better protect the privacy and data on your phone, stay tuned!

A lot of other information can focus on Lao Luo's Sina Weibo: Http://weibo.com/shengyangluo.

Seandroid Safety mechanism Brief introduction and learning Plan