SELinux与SEAndroid（一）

起因

最近项目中偶然遇到以下权限问题：

<4>[ 16.770785] type=1400 audit(1471402121.849:35): avc: denied
{ add_name }
for pid=1728 comm="system_server" name="pmops" scontext=u:r:system_server:s0 tcontext=u:object_r:securespaces_file:s0 tclass=dir permissive=0

log中出现avc: denied 相关的信息就是Se机制做的相关权限限制。于是想深入研究以下SE权限机制。希望本文可以帮助大家轻松修改相关安全权限的文件，进一步在安全方面定制自己的Android系统。

背景

SEAndroid是Google在Android 4.4上正式推出的一套以SELinux为基础于核心的系统安全机制。而SELinux则是由美国NSA（国安局）和一些公司（RedHat、Tresys）设计的一个针对Linux的安全加强系统。
NSA最初设计的安全模型叫FLASK，全称为Flux Advanced Security Kernel（由Uta大学和美国国防部开发，后来由NSA将其开源），当时这套模型针对DTOS系统。后来，NSA觉得Linux更具发展和普及前景，所以就在Linux系统上重新实现了FLASK，称之为SELinux。
Linux Kernel中，SELinux通过Linux Security Modules实现。在2.6之前，SElinux通过Patch方式发布。从2.6开始，SELinux正式入驻内核，成为标配。

SELinux背景知识

先问大家一个问题，如果你搞到了Android的root权限，你就真的可以为所欲为了？不妨往下看：
SELinux出现之前，Linux上的安全模型叫DAC，全称是Discretionary Access Control，翻译为自主访问控制。DAC的核心思想很简单，就是：
进程理论上所拥有的权限与执行它的用户的权限相同。比如，以root用户启动Browser，那么Browser就有root用户的权限，在Linux系统上能干任何事情。
显然，DAC太过宽松了，所以各路高手想方设法都要在Android系统上搞到root权限。那么SELinux如何解决这个问题呢？原来，它在DAC之外，设计了一个新的安全模型，叫MAC（Mandatory Access Control），翻译为强制访问控制。MAC的处世哲学非常简单：即任何进程想在SELinux系统中干任何事情，都必须先在安全策略配置文件中赋予权限。凡是没有出现在安全策略配置文件中的权限，进程就没有该权限。就是说即使你ROOT了，想干一些事情也是不行的，ROOT已经不是万能神了。
那SE权限需要怎么添加呢？我们来看一个例子：

/*
  from external/sepolicy/netd.te
 下面这条SELinux语句表示 允许（allow ）netd域（domain）中的进程  ”写（write）“
 类型为proc的文件
 注意，SELinux中安全策略文件有自己的一套语法格式，下文我们将详细介绍它
*/
allow netd proc:file write

如果没有在netd.te中使用上例中的权限配置allow语句，则netd就无法往/proc目录下得任何文件中写数据，即使netd具有root权限。
显然，MAC比DAC在权限管理这一块要复杂，要严格，要细致得多。
那么，关于DAC和MAC，此处笔者总结了几个知识点：
Linux系统先做DAC检查。如果没有通过DAC权限检查，则操作直接失败。通过DAC检查之后，再做MAC权限检查。
SELinux中也有用户的概念，但它和Linux中原有的user概念不是同一个东西。什么意思呢？比如，Linux中的超级用户root在SELinux中可能就是一个没权限，没地位，打打酱油的”路人甲“。当然，这一切都由SELinux安全策略的制定者来决定。

SELinux Policy语法介绍

Linux中有两种东西，一种死的（Inactive），一种活的（Active）。死的东西就是文件（Linux哲学，万物皆文件。注意，万不可狭义解释为File），而活的东西就是进程。此处的“死”和“活”是一种比喻，映射到软件层面的意思是：进程能发起动作，例如它能打开文件并操作它。而文件只能被进程操作。
SELinux中，每种东西都会被赋予一个安全属性，官方说法叫Security Context。Security Context（以后用SContext表示）是一个字符串，主要由三部分组成。例如SEAndroid中，进程的SContext可通过ps -Z命令查看

最左边的那一列是进程的SContext，以第一个进程/system/bin/logwrapper的SContext为例，其值为u:r:init:s0，其中：
u为user的意思。SEAndroid中定义了一个SELinux用户，值为u。
r为role的意思。role是角色之意，它是SELinux中一种比较高层次，更方便的权限管理思路，即Role Based Access Control（基于角色的访问控制，简称为RBAC）。简单点说，一个u可以属于多个role，不同的role具有不同的权限。RBAC我们到最后再讨论。
init，代表该进程所属的Domain为init。MAC的基础管理思路其实不是针对上面的RBAC，而是所谓的Type Enforcement Accesc Control（简称TEAC，一般用TE表示）。对进程来说，Type就是Domain。比如init这个Domain有什么权限，都需要通过[例子1]中allow语句来说明。
S0和SELinux为了满足军用和教育行业而设计的Multi-Level Security（MLS）机制有关。简单点说，MLS将系统的进程和文件进行了分级，不同级别的资源需要对应级别的进程才能访问。后文还将详细介绍MLS。

再来看文件的SContext，读者可通过ls -Z来查看

倒数第二列所示为根目录下几个文件和目录的SContext信息，以第一行root目录为例，其信息为u:object_r:rootfs:s0：
u：同样是user之意，它代表创建这个文件的SELinux user。
object_r：文件是死的东西，它没法扮演角色，所以在SELinux中，死的东西都用object_r来表示它的role。
rootfs：死的东西的Type，和进程的Domain其实是一个意思。它表示root目录对应的Type是rootfs。
s0：MLS的级别。

到这里应该就知道刚开始我遇到的问题该怎么解决了，添加如下权限即可：
allow system_server securespaces_file:dir add_name