This article has three purposes:
1. Understand how SEAndorid works.
2. Be able to understand the rules of SEAndroid.
3. Be able to add or delete your own rules (this rule may not be used by most people, so the first two are the main purposes)
SEAndroid is the transplantation of SELinux to Android. SELinux is a system protection mechanism on Linux, whose full name is Security Enhanced Linux, and it is an implementation of MAC (Mandatory Access Control System). Its purpose is to clearly indicate which resources (files, network ports, etc.). ) a process can access. The Android system is implemented based on Linux. For the traditional Linux system, NSA developed a set of security mechanism SELinux to enhance security. However, because Android system has a unique user space runtime, SELinux is not completely suitable for Android system. Therefore, NSA and Google developed SEAndroid based on SELinux for Android system.
Android 4.4 introduced this mechanism for the first time. The biggest difference between SeaAndroid and SELinux is that SeaAndroid adapts Binder in Android system. After entering the adb shell, you can use the getenforce command to see if it is applied. After root, SEAndroid can be closed through setenforce 0. But it seems that this function has been turned off at present.
To understand the concept of SEAndorid, you have to mention DAC and MAC.
DAC is a traditional access control mode of Linux, which can control the access of files, folders and * * * shared resources. In the DAC model, the owner (or administrator) of the file object is responsible for managing access control. DAC uses ACL (Access Control List) to provide different permissions for non-administrator users, while root users have complete freedom to control the file system.
In layman's terms, if Xiao Ming creates a file, he has absolute control over the file, and he can independently control the permissions of others on the file. A file has three permissions: read (r), write (w) and execute (x). We can see the permissions of each file through the command ls -l l, and then we can specify the permissions of this other person to this file through the command chmod. (chmod 777？ Everyone should understand the command 1.txt, so I won't elaborate. )
But the disadvantage of this mechanism is that the root user can control the permissions of any file and do whatever he wants. The control granularity is coarse. If I just want another person to see my file, and this person is not in the same user group as me, then I can only achieve this goal through chmod XX4 XX, but then anyone else can see my file. Therefore, it has a relatively coarse particle size.
So Linux introduced MAC mechanism, that is, mandatory access control. The core idea of MAC is that any process that wants to do anything in SELinux system must be given permission in the security policy configuration file first. If there is no permission in the security policy configuration file, the process does not have this permission. This mechanism is equivalent to a white list, on which the permissions of all processes are configured. A process can only do things within the permissions on the white list, and once it wants to do operations that do not belong to its own permissions, it will be rejected.
Unlike DAC, MAC no longer simply divides processes into root processes, but configures a type for each process (subject) and file (object). When a process manipulates (reading and writing, etc. ) a file, the system will check whether the process type has the operation permission of this file type.
Through the command ps -Z, you can see the security label of the process, and ls -Z can see the label (security context) of the file.
For example, in the process security context, the init process is of type init, and the following processes are of type kernel. (In fact, the type of a process is also called a domain. )
The type of 123.txt in the file security context is tootfs.
(The format of process and file security context labels is user: role: type: security _ level, regardless of other columns. This involves several other access control models in SELinux. In SEAndroid, we only need to care about its type, such as init process. U:r: init: s0, we just need to know that his type is init. )
Knowing the security contexts of processes and files, how to control permissions through their security contexts?
There is a file called sepolicy on the mobile phone, which is the security policy configuration file of SEAndroid, which contains the permission configuration of all processes, and the processes can only run within their permissions. Even if this file has root permissions, it cannot be deleted. Dump the contents of this file, and you will find that there are many rules in it (I passed Meizu's 4000 rule and Samsung's 20000 rule). Look at two examples.
? Allow untrusted application system to apply data file: file {read}
? Allowed zygote sdcard _ type: file {read write creatrename}
Its specific format is: allowdomain type: class {permission}? (Domain refers to the type of process)
By interpreting the above three rules in this format,
1. Allows processes of untrusted application types to read files of system application data file types.
2. Allow the process of zygote type to read and write the file renamed sdcard_type by creat.
So the control mode of MAC is this: when a process operates a file, the system will check the context of the process and the file to see if the type of the process has permission to operate the type of the file. For example, if zygote wants to read a file on sdcard, the file type is sdcard, and the type (domain) of zygote is zygote, the system will check and find this rule: allow Zygote SD card _ type: file {read write creatRename}. Then the operation will be allowed. If zygote wants to delete a file on an sdcard, the system will be rejected if it finds that there is no deletion in the corresponding rules. The above two rules and this example are all made up by myself, just to illustrate the situation. In real cases, zygote has the right to delete files on sdcard. )
DAC and MAC work at the same time, and an operation will be detected according to DAC and MAC before execution. If the conditions of any mechanism are not met, it will be rejected.
The above section explains the working principle of SeaAndroid, so we know why the root authority of zygote can't do whatever it wants, but how to change the rules of SeaAndroid and expand zygote's authority. It is impossible to change the sepolicy directly, because the sepolicy is in boot.img, and the file sepolicy will be rewritten and read every time it is turned on, so the change cannot be successful.
So unzip boot.img directly, replace the sepolicy inside and repackage it. There is a set of decompression and packaging tools on Linux, and the windows decompression tool is Android-image-tools-windows.zip? First find the official ROM brush package of the mobile phone manufacturer and find boot.img to decompress. There is a file called sepolicy in it. Modify sepolicy and then replace it, repackage it and brush it into your mobile phone. Well, it's actually quite complicated, but I don't think most people need it. Write it like this first, it is necessary to write it in detail. I was going to upload my own tools, but I don't know how to upload files. . . I can't find a link to my tool, you can find it here))
/xmikos/setools-android
? 1.sepolicy-inject: insert rule
2. Search: decompilation strategy
3.seinfo: check the version of sepolicy.
Command to modify the policy: Push it to the mobile phone and enter it directly. /(corresponding file) to see its usage (here is one of the commands I inserted).
. /se policy-inject-s zygote-t labeled fs-c file system-P remount，getattr，relabelto，transition，quotamod，unmount-P/se policy-o/SD card/se policy 1
/showthread.php？ t=2073775
Blog is the starting point of learning, not the end. . . This article is only an introduction to SEAndroid, with a strong purpose, only the main part, and many contents are not involved. If you have a deep understanding of SEAndroid, you can read Lao Luo's article.
* * Finally, a compliment! ! ! Add a concern, will you * *
Reference link:
The introduction of SEAndroid security mechanism and the study plan strongly recommend Lao Luo.
SEAndroid strategy analysis suggestion
Security mechanism of Android
Understand SELinux deeply