哈喽大家好，我是咸鱼
文章《SELinux 导致 Keepalived 检测脚本无法执行》以【keepalived 无法执行检测脚本】为案例向大家简单介绍了关于 SELinux 的一些概念
比如说什么是自主访问控制 DAC 和 强制访问控制 MAC；SELinux 安全上下文的概念等等
那么今天咸鱼将单独写一篇文章向大家专门介绍一下 SELinux
SELinux（Security Enhanced Linux，安全增强型 Linux），这玩意由美国国家安全局（NSA）利用 Linux 安全模块（LSM）开发而成
安全增强型 Linux，看名字就感觉是跟安全相关的。 SELinux 是 Linux 内核中的一个模块，用来解决进程与文件资源之间权限相关的一些问题
提到进程与文件资源之间的权限问题，我们脑子里首先想到的应该就是 rwx 权限了吧
在传统的 UNIX 类系统中，文件资源都与特定的用户和群组相关联，并且访问权限通过 rwx 来控制
普通用户想要去读写系统中的文件资源受限于其所属的用户和群组的 rwx 权限
对于 root 用户来说rwx权限设置是无效的，因为 root 用户拥有完全访问控制权
比如说某个进程想要对文件进行读写时，系统就会根据该进程的属主和属组去比对文件权限，只有通过权限检查才能进一步操作
这种权限控制方式被称为自主访问控制（Discretionary Access Control, DAC）
DAC 是 Linux 操作系统中的一种基本权限控制机制，用于限制用户对系统资源的访问权限
但是后面大家发现 DAC 有许多不足之处：比如说 root 的权限太高了，如果某个恶意进程拿到了 root 权限，那么将是一件很可怕的事情
又或者不小心把某一个文件的权限设置成了 777，那么这个文件就会被任何人任何进程操作
为了弥补 DAC 的一些不足之处，MAC 模型随之诞生
MAC 是 Linux 操作系统中一种更加严格和细粒度的访问控制机制，用于加强对系统资源的保护和控制
它有趣的地方在于可以针对特定的进程与特定的文件资源来管理权限，不仅考虑了前面 DAC 机制中的 rwx 权限、还考虑了更多因素（例如安全策略和标签）
即使你是 root 用户，在使用不同的进程时你所能获取的权限也不一定是 root
SELinux 引用了 MAC ，每个进程和系统资源都有一个特殊的安全性标签，称为 SELinux 上下文（context）
依据这个安全上下文，SELinux 制定了一系列规则，用来限制进程之间如何互相交互以及如何与各类系统资源交互
SELinux 的规则能够精细到是否允许特定用户或进程访问特定资源
举个例子：
使用 SELinux时，httpd 进程能够访问
/var/www/html/，但是不允许访问/tmp和/var/tmp/中的文件即使你的 web 服务器被攻击，黑客控制了 httpd 进程，就算拥有 root 权限也无法访问
/tmp和/var/tmp/中的文件
需要注意的是：
我们知道，SELinux 通过 MAC 的方式来管理进程或用户的权限
即 SELinux 控制的主体是【进程】或【用户】，而【目标】则是该进程或用户能否访问的文件资源
关于 SELinux 策略，以 CentOS 7.x 为例：
/etc/selinux/config
# SELINUXTYPE= can take one of three values:
# targeted - Targeted processes are protected,
# minimum - Modification of targeted policy. Only selected processes are protected.
# mls - Multi Level Security protection.
我们知道，每个主体进程和目标资源都有一个安全标签，称为 SELinux 安全上下文（Security Context）
SELinux 会根据主体的安全上下文以及目标的安全上下文来决定是否允许主体访问目标，以及允许何种类型的访问
即主体与目标的安全上下文必须一致才能够顺利读写，有点像 DAC 中的 rwx 权限
安全上下文存放在文件的 inode 内，可以通过下面的命令去查看（需要先开启 SELinux）
# 查看目录下文件的安全上下文
[root@minion2 ~]# ll -Z
... unconfined_u:object_r:admin_home_t:s0 文件1
... system_u:object_r:admin_home_t:s0 文件2
... unconfined_u:object_r:admin_home_t:s0 文件3
以 unconfined_u:object_r:admin_home_t 为例，可以看到安全上下文主要用冒号分割了三个字段，分别代表三个主要类型
User(用户）
在 SELinux 中，身份是指操作系统中的用户（User）。每个 user 都有一个唯一的身份标识
不同的 user 可以被分配不同的角色（role）和类型（type），以控制他们对系统资源的访问
比如 unconfined_u（不受限的用户）表示该文件来自于不受限（不受 SELinux 限制）的用户
一般来讲默认的 bash 环境是不受 SELinux 管制的，所以 bash 进程产生的文件 user 大多数为
unconfined_u不受限用户
比如 system_u ，如果是网络服务所产生或系统服务运行过程中产生的文件，那 user 大部分就是 system_u
role（角色）
角色是 SELinux 中的一个概念，用于定义用户在系统中的角色或角色组
role 可以帮助限制 user 的行为，使其在不同的角色下有不同的权限
通过 role ，就可以知道这个数据是属于进程还是文件资源，_r 表示 role
object_r（文件或目录）
system_r（进程）
type（类型）
type 是 SELinux 中非常重要的一个概念，它用于对文件、进程等资源进行分类，每个文件、进程都被赋予一个唯一的 type 标识
type 定义了资源可以被哪些进程和用户访问，以及资源可以访问哪些其他资源
这种基于类型的访问控制使得即使用户有相同的权限，但只有在特定的 type 下才能进行访问，从而增强了系统的安全性
type 在文件与进程方面的定义有一些区别：
1)type：在文件资源（Object）上面称为类型（type）
2)domain：在主体进程（Subject）上面称为域（domain）
type 与 domain 需要相互适配，该进程才能够顺利读取文件资源
以 crond 为例，先看下 crond 进程的安全上下文内容
# 可以看到 crond 进程的 type（即 domain） 为 crond_t
[root@localhost ~]# ps -eZ | grep crond
system_u:system_r:crond_t:s0-s0:c0.c1023 681 ? 00:00:00 crond
system_u:system_r:crond_t:s0-s0:c0.c1023 688 ? 00:00:00 atd
再来看下 crond 的执行文件、配置文件等安全上下文内容
# 可以看到文件资源的 type 为 crond_exec_t、system_cron_spool_t
[root@localhost ~]# ll -Zd /usr/sbin/crond /etc/crontab /etc/cron.d
drwxr-xr-x. root root system_u:object_r:system_cron_spool_t:s0 /etc/cron.d
-rw-r--r--. root root system_u:object_r:system_cron_spool_t:s0 /etc/crontab
-rwxr-xr-x. root root system_u:object_r:crond_exec_t:s0 /usr/sbin/crond
当我们执行 /usr/sbin/crond 之后，这个进程的 domain 类型是 crond_t，能够读取的配置文件则为 system_cron_spool_t 这种类型
如果配置文件的 type 不是 system_cron_spool_t ，就算进程拥有 rwx 权限也无法读取
最后总结一下，SELinux 基于 MAC 模型进一步更加严格和细分地对进程与资源之间的权限进行控制，用于加强对系统资源的保护
在 SELinux 中，有三个重要的概念：
SELinux 控制的主体是【进程】或【用户】，而【目标】则是该进程或用户能否访问的文件资源
SELinux 为每个主体进程和目标资源都打上一个安全标签，称为 SELinux 安全上下文（Security Context），它会根据主体的安全上下文以及目标的安全上下文来决定是否允许主体访问目标，以及允许何种类型的访问
即主体与目标的安全上下文必须一致才能够顺利读写，有点像 DAC 中的 rwx 权限