Graphic tutorial: SELinux policy implementation

This year we have celebrated SELinux's ten-year-old birthday. looking back at the ten-year-old development history, there is a sense of dreams. SELinux first appeared in FedoraCore3, and then logged on to the Red Hat Enterprise Linux4. SELinux, a friend who has never used SELinux or who wants to further confirm its basic definition, has celebrated the tenth birthday of SELinux this year. it is a dream to recall the development history of the decade. SELinux first appeared in Fedora Core 3 and then logged on to RedHat Enterprise Linux 4. If you have never used SELinux or want to further confirm the basic definition of SELinux, read on.

SElinux is a tag system. Each process has its own tag, and each file/directory object in the operating system has its own tag. Tags are even assigned to network ports, devices, and potential host names. We write rules to control access to a process tag or even an object tag. this is called a management policy. The SELinux kernel enforces these rules. sometimes we call this scheme mandatory access control (MAC ).

The owner of an object does not have the permission to go beyond the object's security attributes. Standard Linux access control and all/group + permission tags (such as rwx) are generally called independent access control (DAC ). SELinux does not contain UID or file ownership. All things are controlled by the tag mechanism. This means that the SELinux system can be set without involving the high-permission root process.

Note:SELinux does not replace DAC control. SELinux is a parallel execution mode. an application can run normally only after it meets the requirements of both SELinux and DAC. This may cause some confusion when the administrator is denied permissions. If the administrator permission is denied, the DAC is faulty, but this is definitely not related to the SELinux tag.

• Type mandatory

Let's take a closer look at the tag mechanism. The main mode or forcible means of SELinux is called "type forced ". This means that we need to define tags for the process based on its actual type, and the tag for the file system object is also based on its type.

Metaphor

Let's assume that there is a system where the object types to be defined are divided into cat or dog ). A cat and a dog constitute a process type.

Now we want to interact with the so-called "food. Foods also need to be divided into different types, namely, cat food and dog food.

As a policy maker, I plan to adopt this approach: dog has the right to eat dog_chow, while cat has the right to eat cat_chow. In SELinux, we will write this rule into the policy.

• Allow the cat process to eat cat_chow: food;
• Allow the dog process to eat dog_chow: food;

With these rules, the system kernel will allow the cat process to eat the food with the cat_chow label, while the dog process will eat the food with the dog_chow label.

However, by default, the SELinux system will block all requests. This means that if a dog process tries to eat cat_chow, the kernel will block it.

Similarly, the cat process does not allow exposure to dog food.

Actual situation

We label the Apache process as httpd_t and the Apache content as httpd_sys_content_t and httpd_sys-content_rw_t. Assume that we store credit card data in a MySQL database and label it as mysqld_data_t. If an Apache process is intruded, hackers can gain control of the httpd_t process, read the content of the httpd_sys_content_t file, and write data to the httpd_sys_content_rw_t file. However, hackers still cannot read credit card data (mysqld_data_t), even if the compromised process runs as root. In this case, SELinux can significantly mitigate the security threats caused by intrusion activities.

• MCS force

Metaphor

As mentioned above, we have entered two Process types: Dog and cat. However, if the dog process is divided into two types: Fido and Spot, and we do not want Fido to move the dog_chow of the Spot, what changes will happen?

One solution is to create a large number of new types, such as Fido_dog and Fido_dog_chow. However, this approach will soon lose feasibility because all dog-type processes have almost the same permissions.

To solve this problem, we have developed a new forced form called multi-category security (MCS ). In MCS, we add another component to the tag and apply it to the dog process and dog_chow food. Now we mark the dog process as dog: random1 (representing Fido) and dog: random2 (representing Spot) respectively ).

We marked the dog food as dog_chow: random1 (Fido) and dog_chow: random2 (Spot ).

The content of the MCS rule is: if the type mandatory rule is OK and the random MCS tag exactly matches, the access will be passed. if either of them does not meet the requirements, access is denied.

If you try to eat cat_chow: food, Fido (dog: random1) is forcibly rejected by the type.

Fido (dog: random1) is allowed to eat dog_chow: random1.

Fido (dog: random1) cannot eat Spot (dog_chow: random2) food.

Actual situation

In computer systems, we usually face a large number of processes that access the same object, but we want them to be differentiated from each other. We sometimes call this a multi-tenant environment. The best solution for processing such environments is the virtual machine system. If I have a server running a large number of virtual machines, and one of them has been hacked, I certainly want to prevent hackers from using this as a springboard to further disrupt other virtual machines and virtual machine images. However, in the type forced system, the KVM virtual opportunity is marked as s0000_t, and the image is marked as s0000_image_t. Our rule is to allow s0000_t to read/write/delete content with the s0000_image_t tag. In the virtual machine label mechanism, we must not only adopt the type forced scheme, but also distinguish it through MCS. When a virtual unit is about to start a virtual machine system, a random MCS tag will be selected for the virtual unit, such as s0: c1, c2, and then s1__image_t: s0: c1, the c2 tag is assigned to all the content to be managed by the virtual machine. Finally, the virtual opportunity starts with the s1__t: s0: c1, c2 mark. At this time, the SELinux kernel can control s1__t: s0: c1, and c2 cannot write content to s1__image_t: s0: c3, c4, this control capability is also effective when the virtual machine is controlled by hackers and the other party has root permissions.

We also use a similar isolation mechanism in OpenShift. Each component (including user/application process) runs in the same SELinux type (openshift_t ). Policy-defined rules and rules determine how to control access activities related to component types and unique MCS tags, so as to ensure that different components cannot interact.

If you are interested, you can click here to view a small video to learn what happens if an Openshift component has root permissions.

• MLS force

This is another forced form of SELinux, but the frequency of use is much lower. This is multi-level security (MLS). It was born in the 1960s s, it is mainly used in Trusted operating systems such as Trusted Solaris.

The main idea is to implement process control based on the level of data being used. That is to say, the secrect process cannot read the top secret data.

MLS is very similar to MCS, but it adds the concept of "dominance" to the forcible mechanism. The MCS tag can pass only when it is completely matched, but one MLS tag can control another MLS tag to obtain access permission.

Metaphor

Now we will not talk about different dogs, but focus on different dog breeds. For example, we are now facing a gray dog and a Giwa.

We allow the gray dog to eat any type of dog food, but the Giwa cannot eat the gray dog's dog food.

The label we set for the gray dog is dog: Greyhound, and its dog food is dog_chow: Greyhound; while the label for the Giwa is dog: chibaihua, and its food label is dog_chow: chibaihua.

 

Under the MLS policy, we allow the MLS gray dog label to have right to control the doll label. This means that dog: Greyhound can eat dog_chow: Greyhound and dog_chow: chibaihua.

 

However, dog: chibaihua cannot eat dog_chow: Greyhound.

Of course, dog: Greyhound and dog: chibaihua are still affected by type force and cannot eat cat_chow: Siamese, even if the gray-dog type in MLS has permission to the Siro cat type.

Actual situation

Assume that I have two Apache servers: one running with the httpd_t: Topsecret tag and the other running with the httpd_t: Secret tag. If the Apache process httpd_t: Secret is intruded, the hacker will be able to read the content of httpd_sys_content_t: Secret, but cannot read the content of httpd_sys_content_t: TopSecret.

However, if the Apache server running httpd_t: TopSecret is intruded, contents of httpd_sys_content_t: Secrect and httpd_sys_content_t: TopSecret will be exposed to hackers.

We use the MLS mechanism in a military environment, that is, a user is only allowed to view the secret data, while another user in the same system can view the top secret data.

Summary

SELinux is a powerful tag system that uses the kernel to control access to each individual process. The main function is type enforcement. The role of a rule is to determine whether a process has the right to read the corresponding object based on the tag type of the process and the object. In addition, there are two other control mechanisms, where MCS is responsible for distinguishing similar processes from each other, while MLS allows one process to have the permission to direct to another process.

Link: http://opensource.com/business/13/11/selinux-policy-guide#.UoWMDG-jYlE.sinaweibo