selinux学习笔记二（selinux基础关键字介绍）

Android操作系统中集成selinux模块，是一种对系统安全的增强。以前基于DAC的安全防护模式有个致命漏洞，即：进程自身可以被动态的修改，如第三方app通过hack的方式把自身变成system进程，则该app就具有了system权限。为了防止此类漏洞被触发，在DAC的基础上增加MAC的权限控制，而selinux是MAC安全模块中比较完善的一种，所以把selinux功能引入Android。

在selinux的世界里，把所有的东西分为subject（一般可以理解为动态运行的进程）和object（一般可以理解为静态存在的文件），其安全防护即是指管理所有subject对所有object的访问，而所谓的管理所指的是把各个object能接受的访问方式（如：增，删，改，查）细化成规则，并指定不同的subject对不同的object有那些访问规则。所以简单的来讲可以把selinux的安全防护分为三个部分：

1）对所有subject分类，分类的结果是每个subject都有与之对应的security context；
2）对所有object分类，分类的结果是每个object都有与之对应的security context；
3）描述各种不同subject对各种不同object的访问规则，并把描述形成文件，即policy文件。

当subject要对object访问时，首先要去查询该访问方式是否在现有的policy文件中被授权。其实DAC的安全防护也可以抽象成类似selinux中定义的subject，object和policy这种模式。而MAC不同于DAC的地方是，在MAC模式中subject的security context，object的security context和policy都是一经确立不可以修改，而DAC模式中这三者在初始化以后变动仍然可以被改变。

使用selinux实现安全防护时，对subject和object的security context定义相对来讲比较简单，最繁重的工作是policy文件的撰写。逐步的分别介绍如下：

首先介绍selinux中的security context，通过命令行ps -eZ看到各个进程的security context，通过命令行ls -Z可以得到当前目录下所有文件的security context。例如得到的init进程security context描述为：

u:r:init:s0

得到的'/data'目录的security context为：

u:object_r:system_data_file:s0

可见在selinux中，security context是用一个字符串表示的，字符串包含四个部分，对这四部分的描述
可以参考：https://selinuxproject.org/page/NB_SC 中所述：

SELinux requires a security context to be associated with every process (or subject) and object that are used by the security server to decide whether access is allowed or not as defined by the policy.
The security context is also known as a 'security label' or just label that can cause confusion as there are many types of label depending on the context (another context!!).
Within SELinux, a security context is represented as variable-length strings that define the SELinux user[1], their role, a type identifier and an optional MCS / MLS security range or level as follows:
user:role:type[:range]

其中前两个字段user和role基本上是固定的，对于subject来讲这两者大多数情况下被分别写死为“u”和“r”，对object来讲这两者大多数情况下被分别写死为“u”和“object_r”；最后一个字段又是可选的，大多数情况下都被写死为“s0”。所以对于subject和object来讲，他们security context全部用type字段来表示，所以selinux又可以被叫做TYPE ENFORCED ACCESS CONTROL。

subject 的security context的“type”字段，一般被理解为“domain”；object的security context的“type”字段一般被理解为“type”。

介绍完security context以后，然后就可以开始介绍policy了，随便从找到一个.te文件（包含了多条policy内容）中找到一条规则描述如下：

allow netd properties_device:dir relabelto;
allow netd properties_device:dir relabelto;

allow语句的格式如下：

allow domains types:classes operations

a）：domains - subject的一种类型；
b）：types - object的一种类型；
c）：classes - 这个字段没有具体的含义，是后者operations的一种归类；
d）：operations - 要执行的操作（例如，读，写等）。

所以上述规则的含义是：允许domain为“netd”的进程对type为“properties_devices”的object做class “dir”中定义的“relabelto”操作。翻译成selinux的结论就是：允许security context为“netd”的进程对security context为“properties_devices”做class “dir”中定义的“relabelto”操作。

那么当“netd”进程在运行过程中触发了这条规则以后，kernel层是通过怎样的流程才决定允许触发这条规则的函数调用的呢？

在开始这个问题之前，有以下个前提假设，后续会详细介绍这几个前提的实现过程：
1）在内核层，当前进程的security context已经被标识为“netd”（其实各种各样的security context最终在内核层只是一个security id）；
2）在内核层，security context为“properties_devices”的object也已经被标识；
3）在内核层，class “dir”中确实定义了“relabelto”操作。

转载于:https://blog.51cto.com/2559640/2365797