转载自鸟哥的私房菜网站
SELinux 是透过 MAC 的方式来控管程序，他控制的主体是程序，而目标则是该程序能否读取的『档案资源』！所以先来说明一下这些咚咚的相关性啦！
主体(Subject)：
SELinux主要想要管理的就是程序，因此你可以将『主体』跟本章谈到的 process 划上等号；
目标(Object)：
主体程序能否存取的『目标资源』一般就是文件系统。因此这个目标项目可以等文件系统划上等号；
政策(Policy)：
由于程序与档案数量庞大，因此 SELinux 会依据某些服务来制订基本的存取安全性政策。这些政策内还会有详细的规则 (rule)来指定不同的服务开放某些资源的存取与否。在目前的 CentOS 6.x 里面仅有提供两个主要的政策如下，一般来说，使用预设的target 政策即可。
targeted：针对网络服务限制较多，针对本机限制较少，是预设的政策；
mls：完整的 SELinux 限制，限制方面较为严格。
图 7.4-1、SELinux 运作的各组件之相关性(本图参考小州老师的上课讲义)
安全性本文(Security Context)
CentOS 6.x 的 target 政策已经帮我们制订好非常多的规则了，因此你只要知道如何开启/关闭某项规则的放行与否即可。那个安全性本文比较麻烦！因为你可能需要自行配置文件案的安全性本文呢！为何需要自行设定啊？ 举例来说，你不也常常进行档案的 rwx的重新设定吗？这个安全性本文你就将他想成 SELinux 内必备的 rwx 就是了！这样比较好理解啦。
安全性本文存在于主体程序中与目标档案资源中。程序在内存内，所以安全性本文可以存入是没问题。那档案的安全性本文是记录在哪里呢？事实上，安全性本文是放置到档案的 inode 内的，因此主体程序想要读取目标档案资源时，同样需要读取inode ， 这 inode 内就可以比对安全性本文以及 rwx 等权限值是否正确，而给予适当的读取权限依据。
那么安全性本文到底是什么样的存在呢？我们先来看看 /root 底下的档案的安全性本文好了。 观察安全性本文可使用『 ls -Z』去观察如下：(注意：你必须已经启动了 SELinux 才行！若尚未启动，这部份请稍微看过一遍即可。底下会介绍如何启动 SELinux喔！)
[root@www ~]# ls -Z
-rw-------. root root system_u:object_r:admin_home_t:s0 anaconda-ks.cfg
drwxr-xr-x. root root unconfined_u:object_r:admin_home_t:s0 bin
-rw-r--r--. root root system_u:object_r:admin_home_t:s0 install.log
-rw-r--r--. root root system_u:object_r:admin_home_t:s0 install.log.syslog
# 上述特殊字体的部分，就是安全性本文的内容！
如上所示，安全性本文主要用冒号分为三个字段 (最后一个字段先略过不看)，这三个字段的意义为：
Identify:role:type
身份识别:角色:类型
身份识别(Identify)： 相当于账号方面的身份识别！主要的身份识别则有底下三种常见的类型：
root：表示 root 的账号身份，如同上面的表格显示的是 root 家目录下的数据啊！
system_u：表示系统程序方面的识别，通常就是程序啰；
user_u：代表的是一般使用者账号相关的身份。
角色 (Role)：透过角色字段，我们可以知道这个数据是属于程序、档案资源还是代表使用者。一般的角色有：
object_r：代表的是档案或目录等档案资源，这应该是最常见的啰；
system_r：代表的就是程序啦！不过，一般使用者也会被指定成为 system_r 喔！
类型 (Type)：在预设的 targeted 政策中， Identify 与 Role 字段基本上是不重要的！重要的在于这个类型 (type) 字段！基本上，一个主体程序能不能读取到这个档案资源，与类型字段有关！而类型字段在档案与程序的定义不太相同，分别是：
type：在档案资源 (Object) 上面称为类型 (Type)；
domain：在主体程序 (Subject) 则称为领域 (domain) 了！
目标(Object)：
主体程序能否存取的『目标资源』一般就是文件系统。因此这个目标项目可以等文件系统划上等号；
政策(Policy)：
由于程序与档案数量庞大，因此 SELinux 会依据某些服务来制订基本的存取安全性政策。这些政策内还会有详细的规则 (rule)来指定不同的服务开放某些资源的存取与否。在目前的 CentOS 6.x 里面仅有提供两个主要的政策如下，一般来说，使用预设的target 政策即可。
targeted：针对网络服务限制较多，针对本机限制较少，是预设的政策；
mls：完整的 SELinux 限制，限制方面较为严格。
安全性本文 (securitycontext)：
我们刚刚谈到了主体、目标与政策面，但是主体能不能存取目标除了要符合政策指定之外，主体与目标的安全性本文必须一致才能够顺利存取。 这个安全性本文 (securitycontext) 有点类似文件系统的 rwx 啦！安全性本文的内容与设定是非常重要的！如果设定错误，你的某些服务(主体程序)就无法存取文件系统(目标资源)，当然就会一直出现『权限不符』的错误讯息了！
图 7.4-1、SELinux 运作的各组件之相关性(本图参考小州老师的上课讲义)
上图的重点在『主体』如何取得『目标』的资源访问权限！由上图我们可以发现，(1)主体程序必须要通过 SELinux 政策内的规则放行后，就可以与目标资源进行安全性本文的比对，(2)若比对失败则无法存取目标，若比对成功则可以开始存取目标。问题是，最终能否存取目标还是与文件系统的 rwx权限设定有关喔！如此一来，加入了 SELinux 之后，出现权限不符的情况时，你就得要一步一步的分析可能的问题了！
安全性本文(Security Context)
CentOS 6.x 的 target 政策已经帮我们制订好非常多的规则了，因此你只要知道如何开启/关闭某项规则的放行与否即可。那个安全性本文比较麻烦！因为你可能需要自行配置文件案的安全性本文呢！为何需要自行设定啊？ 举例来说，你不也常常进行档案的 rwx的重新设定吗？这个安全性本文你就将他想成 SELinux 内必备的 rwx 就是了！这样比较好理解啦。
安全性本文存在于主体程序中与目标档案资源中。程序在内存内，所以安全性本文可以存入是没问题。那档案的安全性本文是记录在哪里呢？事实上，安全性本文是放置到档案的 inode 内的，因此主体程序想要读取目标档案资源时，同样需要读取inode ， 这 inode 内就可以比对安全性本文以及 rwx 等权限值是否正确，而给予适当的读取权限依据。
那么安全性本文到底是什么样的存在呢？我们先来看看 /root 底下的档案的安全性本文好了。 观察安全性本文可使用『 ls -Z』去观察如下：(注意：你必须已经启动了 SELinux 才行！若尚未启动，这部份请稍微看过一遍即可。底下会介绍如何启动 SELinux喔！)
[root@www ~]# ls -Z
-rw-------. root root system_u:object_r:admin_home_t:s0 anaconda-ks.cfg
drwxr-xr-x. root root unconfined_u:object_r:admin_home_t:s0 bin
-rw-r--r--. root root system_u:object_r:admin_home_t:s0 install.log
-rw-r--r--. root root system_u:object_r:admin_home_t:s0 install.log.syslog
# 上述特殊字体的部分，就是安全性本文的内容！
如上所示，安全性本文主要用冒号分为三个字段 (最后一个字段先略过不看)，这三个字段的意义为：
Identify:role:type
身份识别:角色:类型
身份识别(Identify)： 相当于账号方面的身份识别！主要的身份识别则有底下三种常见的类型：
root：表示 root 的账号身份，如同上面的表格显示的是 root 家目录下的数据啊！
system_u：表示系统程序方面的识别，通常就是程序啰；
user_u：代表的是一般使用者账号相关的身份。
角色 (Role)：透过角色字段，我们可以知道这个数据是属于程序、档案资源还是代表使用者。一般的角色有：
object_r：代表的是档案或目录等档案资源，这应该是最常见的啰；
system_r：代表的就是程序啦！不过，一般使用者也会被指定成为 system_r 喔！
类型 (Type)：在预设的 targeted 政策中， Identify 与 Role 字段基本上是不重要的！重要的在于这个类型 (type) 字段！基本上，一个主体程序能不能读取到这个档案资源，与类型字段有关！而类型字段在档案与程序的定义不太相同，分别是：
type：在档案资源 (Object) 上面称为类型 (Type)；
domain：在主体程序 (Subject) 则称为领域 (domain) 了！
