2.【SELinux学习笔记】概念

1.强制类型的安全上下文

    在SELinux中，訪问控制属性叫做安全上上下文。不管主体还是客体都有与之关联的安全上下文。通常安全上下文是由三部分组成：用户：角色：类型。

如：

$id -Z 

joe:user_r:user_t

    在SELinux其中，訪问控制属性全部的客体或主体都有一个关联上的上下文属性。由于在SELinux基于类型强制策略，因此在安全上下文中的类型标识符决定了訪问权。

注！SELinux是基于标注Linux的，也就意味着主体要訪问课题时，要同一时候满足传统Linux的权限控制UGO模型和SELinux类型增强策略。

    在安全上下文中。一个进程（主体）的类型通常被称为一个域（domain），那么“域”、“域类型”、“主体类型”和进程类型都是一个意思。

相对于客体，用户和角色标识符非常少使用。为了方便管理。客体的角色通常被定义为object_r。

2.类型强制訪问控制

    在SELinux其中。全部訪问都必须明白授权。SELinx默认不同意不论什么訪问，全然不考虑当前UGO结构，即不考虑用户/组ID是什么。

这也就意味着，在这里没有超级用户了。

那么假设主体须要对客体进行訪问该怎样进行呢？

    在SELinux其中。一般是使用allow规则来指定主体类型（即域）对客体类型授予訪问权限，也就是allow规则规定了哪些类型的进程能够訪问哪些客体。

allow规则由四部分组成：

• 原类型（Source type（s）） 主体类型，即域
• 目标类型（Target type(s)） 客体类型
• 客体类别（Object class（es））客体的类别，如文件、文件夹等
• 许可（Permission（s）） 主体能够对客体运行哪些操作，我们称之为訪问向量

如图：

图1

TE allow规则的基础语法演示样例。如：

allow user_t bin_t : file {read execute getattr};//域为user_t的进程能够对客体类型为bin_t的文件具有读权限、可运行权限和能够获得该文件的属性的权限。而获得文件的属性getattr我们能够理解为查看文件的创建日期、更新时间等属性，以及DAC訪问模式（rwx）。

3.类型强制策略演示样例

    为了进一步研究类型强制策略。我们以管理password的程序（passwd）为例来深入了解。在Linux中，passwd程序是可信任的，改动存储经过加密的password的影子password文件（/etc/shadow），passwd 程序运行它自己内部的安全策略。同意普通用户改动属于他们自己的password。同一时候允许 root 改动全部password。因此，passwd 程序须要有移动和又一次创建shadow 文件的能力，在标准 Linux 中。它当然有这种权利。由于 passwd 程序可运行文件在运行时被加上了 setuid 位，它作为 root 用户（它能訪问全部文件）同意（我们知道，在系统中我们要改动一个用户的password，root用户和普通用户均能够用/usr/bin/passwd someuser这个命令来改动这个/etc/passwd这个文件。root用户本身拥有对/etc/passwd的写权限，无可厚非；那普通用户呢，这里就用到了setuid，setuid的作用是“让运行该命令的用户以该命令拥有者的权限去运行”，就是普通用户运行passwd时会拥有root的权限，这样就能够改动/etc/passwd这个文件了。）。

这就意味着不论什么程序（当以 root 身份执行时） 都有可能可以改动 shadow 文件。

类型强制使我们能做的事情是确保仅仅有 passwd 程序 （或类似的受信任的程序） 可以訪问 shadow 文件， 无论执行程序的用户是谁。

    下图为我们描写叙述了SELinux系统中passwd程序使用类型强制策略的流程：

图2

    上图中定义了passwd的域类型-passwd_t，和shadowpassword文件的类型-shadow_t。那么上图中的allow规则的含义为授权域类型为passwd_t的passwd进程的訪问文件类型为shadow_t的文件shadow，而且具有移动和创建新的shadowpassword文件。

    相应的shadow的安全上下文例如以下：

# ls -Z /etc/shadow

-r---- root root system_u:object_r:shadow_t shadow

    那么此时。在当前策略下检查执行password和程序的进程的安全上下文例如以下：

# ps -aZ

joe:user_r:passwd_t 16532 pts/0 00:00:00 passwd

4.域转换

    我们所做的从表面上看起来，不过主体提供对客体訪问的许可编写一个TE策略。由于我们不得不考虑以下这个问题，比如在Linux系统中。用户joe登录系统，而且创建了一个shell进程（如bash）。而shell进程的类型是user_t。它表示一个普通的、不受信任的用户进程域类型。

那么此时Joe用户怎样让shell进程改动password呢？首先我们来看下图：

图3

    当Joe的shell程序执行其它程序时。新进程则会继承user_t的域类型，而user_t又是一个不受信任的域，那么首先我们不应域类型为user_t的进程直接操作shadowpassword文件，由于这样会同意其它程序也能够读写这个很重要的文件。

那么此时我们该怎样实现呢？也就是说怎样实现将一个域为user_t的shell进程转变为域为passwd_t进程。

①setuid

    传统Linux中。我们能够通过给passwd赋一个setuid的值，使其具有root权限。

在传统Linux系统中。使用以下命令来查看passwd文件信息：

# ls -l /usr/bin/passwd

-r-sxx 1 root root 19336 Sep 7 04:11 /usr/bin/passwd

从上面的信息中我们能够看到，第一个在全部者权限的x位置变成了s，这里的s指的就i时setuid位了。意思是不论什么执行这个文件的进程，它的uid都将编程文件的全部者。

当前我们看到文件的全部者为root用户。那么当Joe用户登陆执行该文件时，实际上此时shell进程的uid就编程了root用户的uid了。例如以下图：

图4

    从上图我们能够看到setuid在传统Linux中是一个很强大的特性。但也同一时候暴漏出传统Linux的主要弱点。即passwd须要以root身份执行訪问shadow文件。然而当以root身份执行时，passwd能够訪问全部的系统资源，而我们最初的目的不过须要passwd操作shadow文件而已，这不仅违背了我们的初衷。也违背了最小权限原则。

②te

    从图2中我们知道allow规则可确保passwd_t域的passwd进程能够訪问shadowpassword文件。那么是怎样实现user_t到passwd_t的域转变呢，看下图：

图5

从上图中我们能够看到有四个类型分别为：user_t（shell）、shadow_t（shadow）、passwd_t（passwd），passwd_exec_t（passwd）。passwd的安全上下文例如以下：

# ls -Z /usr/bin/passwd

-r-sxx root root system_u:object_r:passwd_exec_t /usr/bin/passwd

从上面的信息我们能够来创建TE策略规则是passwd_t域执行。首先第一条规则：

allow user_t passwd_exec_t : file {getattr execute};//同意域为usert_（这里指shell进程），在passwd可运行文件（passwd_exec_t）启动execve()系统调用。实际上也就是说同意shell进程调用execve()来运行passwd。

第二条规则：

allow passwd_t passwd_exec_t : file entrypoint;//提供passwd_t域的入口訪问权，entrypoint许可在SELinxu中是一个许可权限，它的作用就是定义哪个可执行文件（如passwd）能够以某个特定的域（passwd_t）来执行，这就是所谓的域转变。

那么样例中的passwd可执行文件被标识为passwd_exec_t，而且passwd_t类型有entrypoint权限訪问passwd_exec_t，那么passwd就具备了在passwd_t域类型中执行的条件。

第三条规则：

allow user_t passwd_t : process transition;//这条规则中没有提供对客体的訪问，由于此时客体是process，意味着此时的客体代表进程。

假设系统资源都被封装为客体的话，那么进程也能够理解为系统资源，这里进程作为客体并不矛盾。在这个规则中，许但是transition，这个许可的含义就是同意改动进程的安全上下文中的类型。那么这条规则的含义指的就是：同意user_t域转变为passwd_t域。

那么至此我们了解了域转变的流程。也就是说一次成功的域转变，这三条规则必须保证同一时候存在，且当这三个许可在一个TE策略中同一时候通过才干完毕域的转变。

总结例如以下：

1. 进程的新域（passwd_t）对可运行文件（passwd）具有entrypoint许可
2. 进程当前域（usr_t）具有对入口文件(passwd_exec_t)具有execute许可
3. 进程当前域(usr_t)对新的域(passwd_t)具有transition许可

5.默认域转变：type_transition指令

    通过前面的了解我们已经非常清楚了域转变的流程，那么另一个疑惑就是，用户Joe怎样明白它所须要的域转变。通常情况下我们并不须要用户明白的发出这些请求，这就须要一个方法让系统默认启动域转变。

    为了支持默认的域转变，这里我们引入一个新的规则。即类型转变规则（type_transition）。这个规则为SELinux策略提供了一个方法指定默认的域转变。详细例如以下：

type_transition user_t passwd_exec_t : process passwd_t;//将主体user_t域转变为主体passwd_t域

    这个语法规则域allow规则不尽同样，但仍然能够看到熟悉的主体域和客体域（user_t和passwd_exec_t），并且还有客体类别（process）。并且还有新的域（passwd_t）。

6.角色

    SELinux也提供了一种基于角色的訪问控制（RBAC：Role-Based Access Control）。RBAC作为传统訪问控制（DAC自主訪问。MAC强制訪问）的有前景的取代受到广泛的关注。RBAC支持三个著名的安全原则：最小权限原则，责任分离原则和数据抽象原则，SELinux的RBAC特性是依靠TE建立的，由于在SELinux中訪问控制主要是通过类型实现的，角色是基于进程安全上下文中的角色标识符限制进程能够转变的类型。那么怎样定义角色的限制呢？看下图：

图6

    从上图我们能够看到。这里添加了角色部分（user_r）。定义一个角色的语句例如以下：

role user_r type passwd_t;//role语句声明角色标识符以及声明的角色有关的类型。这里声明角色user_r以及相关联的类型passwd_t，这个关联意味着passwd_t类型在安全上下文中与角色user_r共存。假设没有此role语句。就无法创建新的安全上下文joe:user_r:passwd_t。且execve()函数调用也会失败，及时TE策略同意Joe的类型（user_t）有全部的訪问权。

7.MLS（Multi-Level Security）

    MLS对于SELinux来说是可选的，但虽然如此。MLS对部分应用程序还是增强了一定的安全性。那么为了支持MLS。安全上下文被扩展例如以下。添加了安全级别，如：

user:role:type:sensitivity[:category,...][-sensitivity[:category,...]]

    包括MLS的安全上下文至少有一个安全级别。假设存在两个安全级别，那么这两个安全级别就被叫做低和高。假设高安全级别丢失，那么就会仅仅有低安全级别生效。

8.SELinux特性

①.Permissive（许可）模式

    SELinux能够执行在permissive模式，在这个模式中。仅仅存在訪问检查但不会拒绝不同意的訪问。检查SELinux当前的工作模式最简单的方法就是执行getenforce命令。设置系统SELinux工作模式，可使用setenforce 0设置为permissive模式。使用setenforce 1改动为强制模式，可是假设从permissive模式改动为强制模式须要以root登录后再操作。

②passwd演示样例

    为了帮助我们更好的理解域转换，我们来通过以下的流程来验证域转换：

• 启动第一个终端。执行passwd命令：

$ passwd

Changing password for user joe.

Changing password for joe

(current) UNIX password:

• 启动第二个终端，su到root用户，然后使用以下的怕死命令：

$ su
Password:
Your default context is root:sysadm_r:sysadm_t.
Do you want to choose a different one? [n]
# ps axZ|grep passwd
user_u:user_r:passwd_t 4299 pts/1 S+ 0:00 passwd

此时我们看到passwd进程的域为passwd_t。

③策略分析工具apol

    这是一个检查策略内容很有用的一个工具，由Tresys科技公司开发，随SELinux工具包一起公布，成为SeTools。

SeTools软件包包括在大多数SELinux发行包中，执行apol命令确定这个工具是否已经安装到系统中，若没有安装

    apol（analyze policy）是一个成熟的SELinux策略分析工具。本系列文章中也会常常使用SELinux策略。假设我们想要使用它来检查策略文件。执行apol然后打开strict策略文件，在Query>Policy Summary下就能够看到策略相关的摘要信息。