SElinux 可视化操作指南

Your visual how-to guide for SELinux policy enforcement

SELinux 策略执行的可视化操作指南

概况

翻译Daniel J Walsh写的Your visual how-to guide for SELinux policy enforcement

描述了SElinux的三种策略,，这三种安全级别分别是：TE < MCS < MLS

Image by:opensource.com

图片来源:opensource.com

We are celebrating the SELinux 10th year anversary this year. Hard to believe it. SELinux was first introduced in Fedora Core 3 and later in Red Hat Enterprise Linux 4. For those who have never used SELinux, or would like an explanation…

今年我们正在庆祝 SELinux 十周年。难以置信。SELinux 最初是在 Fedora Core 3 中引入的，后来在 Red Hat Enterprise Linux 4 中引入。对于那些从来没有使用过 SELinux，或者想要一个解释…。

SElinux is a labeling system. Every process has a label. Every file/directory object in the operating system has a label. Even network ports, devices, and potentially hostnames have labels assigned to them. We write rules to control the access of a process label to an a object label like a file. We call this policy. The kernel enforces the rules. Sometimes this enforcement is called Mandatory Access Control (MAC).

SElinux 是一个标签系统。每个过程都有一个标签。操作系统中的每个文件/目录对象都有一个标签。甚至网络端口、设备和潜在的主机名都有分配给它们的标签。我们编写规则来控制进程标签对对象标签(如文件)的访问。我们称之为政策。内核执行规则。有时这种强制措施被称为强制访问控制(MAC)。

The owner of an object does not have discretion over the security attributes of a object. Standard Linux access control, owner/group + permission flags like rwx, is often called Discretionary Access Control (DAC). SELinux has no concept of UID or ownership of files. Everything is controlled by the labels. Meaning an SELinux system can be setup without an all powerful root process.

对象的所有者不能决定对象的安全属性。标准的 Linux 访问控制，即 owner/group + 权限标志，比如 rwx，通常被称为自主访问控制(DAC)。SELinux 没有 UID 或文件所有权的概念。一切都由标签控制。这意味着 SELinux 系统可以在没有强大的root进程的情况下设置。

Note: SELinux does not let you side step DAC Controls. SELinux is a parallel enforcement model. An application has to be allowed by BOTH SELinux and DAC to do certain activities. This can lead to confusion for administrators because the process gets Permission Denied. Administrators see Permission Denied means something is wrong with DAC, not SELinux labels.

注意: SELinux 不允许绕过 DAC 控制。SELinux 是一种并行执行模型。SELinux 和 DAC 都必须允许应用程序执行某些活动。这可能会导致管理员感到困惑，因为进程的权限被拒绝，管理员看到 Permission Denied 意味着 DAC 出了问题，而不是 SELinux 标签。

Type enforcement

类型强制执行

Lets look a little further into the labels. The SELinux primary model or enforcement is called type enforcement. Basically this means we define the label on a process based on its type, and the label on a file system object based on its type.

让我们进一步看看这些标签。SELinux 主模型或强制执行称为类型强制执行。基本上，这意味着我们基于进程的类型定义进程的标签，基于文件系统对象的类型定义文件系统对象的标签。

Analogy

类比

Imagine a system where we define types on objects like cats and dogs. A cat and dog are process types.

想象一个系统，我们定义对象的类型，比如猫(cat)和狗(dog)。猫和狗是进程类型。

We have a class of objects that they want to interact with which we call food. And I want to add types to the food, cat_food and dog_food.

我们有一类物体，它们（cat，dog）想要与之互动，我们称之为食物(chow)。我还想给食物(chow)添加类型，猫粮(cat_chow)和狗粮(dog_chow)。

As a policy writer, I would say that a dog has permission to eat dog_chow food and a cat has permission to eat cat_chow food. In SELinux we would write this rule in policy.

作为一个政策制定者，我认为狗(dog)有权吃狗粮(dog_chow)，猫(cat)有权吃猫粮(cat_chow)。在 SELinux 中，我们将在策略中编写此规则。

allow cat cat_chow:food eat;

allow dog dog_chow:food eat;

With these rules the kernel would allow the cat process to eat food labeled cat_chow and the dog to eat food labeled dog_chow.

根据这些规则，内核允许猫(cat)进程吃标记为 cat_chow 的食物，允许狗(dog)吃标记为 dog_chow 的食物。

But in an SELinux system everything is denied by default. This means that if the dog process tried to eat the cat_chow, the kernel would prevent it.

但在 SELinux 系统中，默认情况下会拒绝所有内容。这意味着如果 dog 进程试图吃 cat_chow，内核将阻止它。

Likewise cats would not be allowed to touch dog food.

同样，猫也不允许碰狗粮。

Real world

真实世界

We label Apache processes as httpd_t and we label Apache content as httpd_sys_content_t and httpd_sys_content_rw_t. Imagine we have credit card data stored in a mySQL database which is labeled msyqld_data_t. If an Apache process is hacked, the hacker could get control of the httpd_t process and would be allowed to read httpd_sys_content_t files and write to httpd_sys_content_rw_t. But the hacker would not be allowed to read the credit card data (mysqld_data_t) even if the process was running as root. In this case SELinux has mitigated the break in.

我们将 Apache 进程标记为 httpd_t，将 Apache 内容标记为 httpd_sys_content_ t 和 httpd_sys_content_ rw_ t。假设我们将信用卡数据存储在一个名为 msyqld_data_t 的 mySQL 数据库中。如果一个 Apache 进程被黑客攻击，黑客就可以控制 httpd_t 进程，并被允许读取 httpd_ sys_content_t 文件和写入 httpd_sys_content_ rw_ t。但是即使进程以 root 身份运行，黑客也不能读取信用卡数据(mysqld_data_t)。在这种情况下，SELinux 减轻了入侵的影响。

MCS enforcement

MCS强制执行

Analogy

类比

Above, we typed the dog process and cat process, but what happens if you have multiple dogs processes: Fido and Spot. You want to stop Fido from eating Spot’s dog_chow.

上面，我们输入了狗(dog)进程和猫(cat)进程，但是如果有多个狗进程: Fido_dog 和 Spot_dog，会发生什么情况呢。你想阻止 Fido_dog 吃 Spot 的狗食(dog_chow)。

One solution would be to create lots of new types, like Fido_dog and Fido_dog_chow. But, this will quickly become unruly because all dogs have pretty much the same permissions.

一个解决方案是创建许多新类型，如 Fido_dog 和 Fido_dog_chow。但是，这很快就会变得难以控制了，因为所有的狗都有几乎相同的权限。

To handle this we developed a new form of enforcement, which we call Multi Category Security (MCS). In MCS, we add another section of the label which we can apply to the dog process and to the dog_chow food. Now we label the dog process as dog:random1 (Fido) and dog:random2 (Spot).

为了解决这个问题，我们开发了一种新的强制执行形式，我们称之为多类安全(MCS)。在 MCS 中，我们添加了标签的另一部分，我们可以将其应用到 dog 进程和 dog_chow 食物中。现在我们把 dog 进程分别标记为 dog:random1 (Fido) 和 dog:random2 (Spot)。

We label the dog chow as dog_chow:random1 (Fido) and dog_chow:random2 (Spot).

我们将狗粮(dog_chow)标记为 dog_chow:random1 (Fido) 和 dog_chow:random2 (Spot)。

MCS rules say that if the type enforcement rules are OK and the random MCS labels match exactly, then the access is allowed, if not it is denied.

MCS 规则说，如果 类型强制执行 规则是可以的，并且随机 MCS 标签完全匹配，那么允许访问，如果不允许，则拒绝访问。

Fido (dog:random1) trying to eat cat_chow:food is denied by type enforcement.

dog:random1 (Fido) 试图吃 cat_chow:food 被 类型强制执行 拒绝。

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

dog:random1 (Fido) 被允许吃 dog_chow:random1 (Fido)。

Fido (dog:random1) denied to eat spot’s (dog_chow:random2) food.

dog:random1 (Fido) 拒绝吃 dog_chow:random2 (Spot)。

Real world

真实世界

In computer systems we often have lots of processes all with the same access, but we want them separated from each other. We sometimes call this a multi-tenant environment. The best example of this is virtual machines. If I have a server running lots of virtual machines, and one of them gets hacked, I want to prevent it from attacking the other virtual machines and virtual machine images. But in a type enforcement system the KVM virtual machine is labeled svirt_t and the image is labeled svirt_image_t. We have rules that say svirt_t can read/write/delete content labeled svirt_image_t. With libvirt we implemented not only type enforcement separation, but also MCS separation. When libvirt is about to launch a virtual machine it picks out a random MCS label like s0:c1,c2, it then assigns the svirt_image_t:s0:c1,c2 label to all of the content that the virtual machine is going to need to manage. Finally, it launches the virtual machine as svirt_t:s0:c1,c2. Then, the SELinux kernel controls that svirt_t:s0:c1,c2 can not write to svirt_image_t:s0:c3,c4, even if the virtual machine is controled by a hacker and takes it over. Even if it is running as root.

在计算机系统中，我们通常有许多进程，它们具有相同的访问权限，但我们希望它们彼此分离。我们有时称之为多租户环境。最好的例子就是虚拟机。如果我有一个服务器运行了很多虚拟机，其中一个被黑客攻击，我希望防止它攻击其他虚拟机和虚拟机映像。但是在 类型强制执行 系统中，KVM 虚拟机被标记为 svirt_t，而映像被标记为 svirt_image_t。我们有规则说 svirt_t 可以读/写/删除标记为 svirt_image_t 的内容。使用 libvirt，我们不仅实现了 类型强制执行 分离，还实现了 MCS 分离。当 libvirt 准备启动一个虚拟机时，它会选择一个随机的 MCS 标签，比如 s0:c1,c2，然后为虚拟机需要管理的所有内容分配 svirt_image_t:s0:c1,c2标签。最后，它以 svirt_t:s0:c1,c2 的形式启动虚拟机。然后，SELinux 内核控制 s0:c1,c2 不能写入 svirt_image_t:s0:c3,c4，即使虚拟机被黑客控制并接管。即使它以 root 用户身份运行。

We use similar separation in OpenShift. Each gear (user/app process)runs with the same SELinux type (openshift_t). Policy defines the rules controlling the access of the gear type and a unique MCS label to make sure one gear can not interact with other gears.

我们在 OpenShift 中使用类似的分隔。每个齿轮(用户/应用程序进程)都使用相同的 SELinux 类型(openshift_t)运行。策略定义了控制齿轮类型访问的规则和唯一的 MCS 标签，以确保一个齿轮不能与其他齿轮交互。

Watch this short video on what would happen if an Openshift gear became root.

观看这个短视频了解，如果一个 Openshift 齿轮成为 root 会发生什么。

MLS enforcement

MLS强制执行

Another form of SELinux enforcement, used much less frequently, is called Multi Level Security (MLS); it was developed back in the 60s and is used mainly in trusted operating systems like Trusted Solaris.

SELinux 的另一种实施形式被称为多级安全(Multi Level Security，MLS) ，它使用频率要低得多; 它开发于60年代，主要用于受信任的操作系统，如 Trusted Solaris。

The main idea is to control processes based on the level of the data they will be using. A secret process can not read top secret data.

其主要思想是根据流程将要使用的数据级别来控制流程。秘密进程无法读取绝密数据。

MLS is very similar to MCS, except it adds a concept of dominance to enforcement. Where MCS labels have to match exactly, one MLS label can dominate another MLS label and get access.

MLS 与 MCS 非常相似，除了它增加了一个强制执行的支配概念。在 MCS 标签必须精确匹配的地方，一个 MLS 标签可以支配另一个 MLS 标签并获得访问权限。

Analogy

类比

Instead of talking about different dogs, we now look at different breeds. We might have a Greyhound and a Chihuahua.

我们现在不再讨论不同的狗，而是讨论不同的品种。我们可能有一只灰狗和一只吉娃娃。

We might want to allow the Greyhound to eat any dog food, but a Chihuahua could choke if it tried to eat Greyhound dog food.

我们可能想让灰狗(Greyhound)吃任何狗粮，但吉娃娃试图吃灰狗狗粮，它可能可以噎死。

We want to label the Greyhound as dog:Greyhound and his dog food as dog_chow:Greyhound, and label the Chihuahua as dog:Chihuahua and his food as dog_chow:Chihuahua.

我们想给灰狗(Greyhound)贴上标签:dog:Greyhound ，它的狗粮贴上标签：dog_chow:Greyhound，给吉娃娃(Chihuahua)贴上标签: dog:Chihuahua ，它的狗粮贴上标签：dog_chow:Chihuahua。

With the MLS policy, we would have the MLS Greyhound label dominate the Chihuahua label. This means dog:Greyhound is allowed to eat dog_chow:Greyhound and dog_chow:Chihuahua.

有了 MLS 的政策，我们将有 MLS 灰狗(Greyhound )标签支配吉娃娃(Chihuahua )标签。这意味着dog:Greyhound 允许吃 dog_chow:Greyhound 和 dog_chow:Chihuahua 。

But dog:Chihuahua is not allowed to eat dog_chow:Greyhound.

但是 dog:Chihuahua 是不允许吃 dog_chow:Greyhound。

Of course, dog:Greyhound and dog:Chihuahua are still prevented from eating cat_chow:Siamese by type enforcement, even if the MLS type Greyhound dominates Siamese.

当然，因为 [Type enforcement(TE)](#Type enforcement ) ，dog:Greyhound 和 dog:Chihuahua 仍然被禁止吃 cat_chow:Siamese，即使 MLS 类型的Greyhound 支配 Siamese。。

Real world

真实世界

I could have two Apache servers: one running as httpd_t:TopSecret and another running as httpd_t:Secret. If the Apache process httpd_t:Secret were hacked, the hacker could read httpd_sys_content_t:Secret but would be prevented from reading httpd_sys_content_t:TopSecret.

我可以有两个 Apache 服务器: 一个运行 httpd_t:TopSecret，另一个运行 httpd_t:Secret。如果 Apache 进程 httpd_t:Secret 被黑客攻击，黑客可以读取 httpd_sys_content_t:Secret，但是不能读取 http _sys_content_t:TopSecret。

However, if the Apache server running httpd_t:TopSecret was hacked, it could read httpd_sys_content_t:Secret data as well as httpd_sys_content_t:TopSecret.

但是，如果运行 httpd_t:TopSecret 的 Apache 服务器被黑客攻击，它可以读取 httpd_sys_content_t:Secret 数据以及 httpd_sys_content_t:TopSecret。

We use the MLS in military environments where a user might only be allowed to see secret data, but another user on the same system could read top secret data.

我们在军事环境中使用 MLS，在这种环境中，用户可能只被允许查看机密数据，但同一系统中的其他用户可以读取绝密数据。

Conclusion

结论

SELinux is a powerful labeling system, controlling access granted to individual processes by the kernel. The primary feature of this is type enforcement where rules define the access allowed to a process is allowed based on the labeled type of the process and the labeled type of the object. Two additional controls have been added to separate processes with the same type from each other called MCS, total separtion from each other, and MLS, allowing for process domination.

SELinux 是一个强大的标签系统，控制内核授予各个进程的访问权限。这种方法的主要特点是类型强制执行，其中规则根据进程的标记类型和对象的标记类型定义允许对进程的访问。添加了两个额外的控件来将具有相同类型的进程相互分离，称为 MCS、相互完全分离和 MLS，从而允许进程控制。