Here is because I need to do a bug with contact SELinux, so I looked for a lot of information to learn.
The whole half a month of my problem, finally resolved, so hereby to record, also learn. Here I will summarize some of the recent query summary of the data
then the collation of a lot of information, many are reproduced from the Internet, some of their additions, for future standby, but also for everyone to learn Kazakhstan.
Here this background, I put some links, after all, this can slowly understand and see, after finishing
First, selinux background knowledge
http://blog.csdn.net/syhost/article/details/41496701 DAC and Mac
Prior to the advent of SELinux, the Linux security model called DAC, the full name is discretionary access control, translation for autonomous access controls. The central idea of the DAC is simple:
The process theoretically has the same permissions as the user who executes it. For example, if you start browser with root, then browser has the root user's right to be able to do anything on the Linux system.
Obviously, the DAC is too loose, so the pros are trying to get root on the Android system. So selinux how to solve this problem. It turned out that, outside the DAC, a new security model was designed, called MAC (mandatory Access control),
Translate to mandatory access control. The philosophy of Mac is very simple: any process that wants to do anything in the SELinux system must first be given permission in the security policy configuration file. A process does not have permissions that are not present in the security policy configuration file. To see an example of a seandroid set of permissions:
/* from
external/sepolicy/netd.te the
following SELinux statement represents the Allow (allow) netd domains (domain) process write
Files of type proc
Note that the security policy file in SELinux has its own set of syntax formats, which we'll explain in more detail here/
allow netd proc:file write
If you do not configure the Allow statement in Netd.te using the permissions in the previous example, then netd cannot write data to any file in the/proc directory, even if netd has root permissions.
Obviously, the Mac is more complex and rigorous than the DAC in the Rights management, and it's much more detailed.
So, about DAC and Mac, here's a few things I've summed up:
The Linux system does the DAC check first. If the DAC permission check is not passed, the operation fails directly. After the DAC check, then do Mac permissions check.
SELinux also has the concept of a user, but it is not the same thing as the Linux user concept. What does that mean. For example, the super user root in Linux may be a selinux, no position, playing soy sauce "passers-by a". Of course, it's all up to the SELinux security policy makers to decide.
In this context, the reader should be able to sense that the security policy file is the most important in SELinux. That's true. In fact, for readers of this article, the ultimate goal of learning SELinux should be:
Read the existing security policy files.
Write security policy files that meet specific requirements.
As mentioned earlier, SELinux has its own set of rules to write security policy files, a set of rules called SELinux policy language. It is the key to mastering SELinux.
II. Framework
After finishing