名词解释：
SEAndroid：Security-Enhanced Android
SEAndroid是SELinux（Security-Enhanced Linux） 在 Android 系统中的实现，SELinux是一个强制访问控制（MAC）系统，SEAndroid将其引入以加强Android的安全性，主要通过限制应用和系统组件的权限范围，减少安全漏洞被利用的可能性。
SELinux:Security-Enhanced Linux
如果没有SELinux权限，直接的表现是什么：
Example1：APK->JNI->底层驱动（app操作设备驱点，read,write）,可能会遇到权限问题，打开不了，不能读，不能写等问题，但是在以早期的版本，可能对节点chmod a+x /dev/xxx 进行权限的设置，就能访问了。
Example2：开启启动中，根据rc文件提供的启动信息，会启动一些后台进程，可以在进程对应的rc文件中配置让进程开机启动，但是有可能跑不起来，如果没有配置selinux相关策略的话，这是因为app运行的时候，检测安全环境。
第一节：SEAndroid基础概念
1.1SELinux背后的深层设计目标
DAC自主访问控制模型
这种是比较粗犷的模型，称之为DAC(自主访问，通过chmod修改访问权限)。一个进程如果是超级用户root,它可以访问系统上的所有关联root的资源。因此我们需要控制访问权限的颗粒，这就可以通过MAC机制（即SEAndroid）,因为SELinux设计的核心是引入强制访问（MAC）,而非依赖传统的自主访问权限（DAC）,这一点对于现代系统至关重要，因为DAC的设计缺陷在于它允许具有足够权限的用户自由分配访问权，这在攻击者获得管理员权限后可能会造成严重的系统危害。SELinux则通过预定义的策略，确保即使管理员也不能轻易修改核心文件或服务的访问权限。
SELinux的关键设计目标是实现最小权限原则，这种原则要求每个进程和服务只能访问其完成任务所需要的最小权限。换句话说，即使系统中有漏洞，攻击者也不能轻松通过一个进程掌控这个系统。
例子：一个采购员或行政管理员，之前对某个物资，有各种处置权，处理权在他们手上，随他处置。如果采用MAC机制后，引入策略规则，他能处理的方式就必须有章可循了，对物资的处理需要明文规定的写出来，比如销毁，或只能内部拍卖等。
比如：
可以把SELinux想象成一个严密的公司安全系统：不同的部门（进程）有不同的权限（策略），即便一个部门的员工（进程）突破了内部的限制，他也无法进入其他部门的办公室（文件，资源），因为它的门禁卡（权限策略）不允许他进入这些不相关的区域。
MAC访问控制框架模型
这里的MAC模型，是基于前面的DAC模型的，同样也拥有用户类型，uid和gid的概念。
主体：一般指的是活动的进程
客体：有普通文件，虚拟文件，属性文件，服务service和app
te文件：一般用于描述主体对客体的一套动作行为，就是一种逻辑性的行为描述。
比如：信息部的张经理，允许对员工具有分配系统的xxx权限，这类描述就是te文件中的明文规定，描述了一种主体对客体的规章制度。
第二节：Selinux Context上下文
2.1 聊聊scontext
前面的模型中，讲到客体，主体，权限的概念，即：
某个进程（主体）对（客体）资源会有（哪些）权限动作
这里需要搞明白：
谁是主体，谁能成为主体，我怎么知道某个东西是主体，同理，客体以及权限动作也是如此。
在android系统中，这个问题是通过label标签来解决，我们称这个标签Selinux Context上下文。
简称为scontext
换句话说，安卓系统中的每一个客体和主体对象，都会有一个scontext上下文件，它是一个label字符串，安卓系统中需要有对此有一个规定：
主体的scontext是u:r:xxx:s0,(看到类似这个scontext就知道它是属于主体的标签)，一般这个xxx就是模块名称，如init,adbd,vold等。
客体的scontext是u:object_r:xxx:s0,(看到类似这个scontext就知道它是属于客体的标签)，这个xxx一般指的就是MAC模型中的客体类型资源文件,如/dev/light0
配合te文件的规定策略：比如：进程init对存放在/dev/light0的这个文件有open和read的权限
有可能进程init对存放/dev/light0的这个资源，就没有写入的权限（如果te文件没有规定的话）
换个角度思考，如果想在一个te文件中描述主体对客体的行为动作，主体如何描述，客体又如何描述，所以肯定是需要一些字符串去标识和定义它们，这就是需要打标签的原因。
2.2 关于context_file
前面已经讲了scontext,了解了什么样的标签是主体以及客体，那现在又出现了一个问题，我们在哪里定义这个标签？就是我们这节要讲的context_file,上下文文件。
注意：系统上的所有的文件，全部都需要打上上下文标签，每个文件都需要有标签定义。
那么问题来了，现在所有的标签都已经准备好了，有file_context,genfs_contexts,service_contexts,seapp_contexts,property_contexts,也清楚我们需要对每个客体所需要的标签是在对应的context_file文件中进行标签的定义，但这只是定义性的，我们还需要知道一点，对这个客体来说，肯定是需要有一个角色（是谁）来给这个客体赋予context_file文件中定义的标签label。
在安卓系统中，一般是通过一些SecurityServer进程，如init进程（但不仅仅只有它），它可以将上下文标签中的定义，给对应的文件打上标签（上图中也包含了打标签的过程）。
（知识扩展：这里针对的是客体，但只对主体的上下文标签又是在哪里呢？主体在运行之前也是一个问价，所以也需要拥有上下文里的某一个标签）
2.3Selinux权限的检测
当主体要真正去访问客体资源的时候，会去触发安全的认证的检测过程，比如说它有对应的权限，放行，如果没对应的权限，就访问失败，问题是由谁来监控权限的合法性工作？这个监控是谁来做的，其实也是安全服务SecurityServer来处理，需要由linux内核LSM的支持，翻译过来是Linux Security Module的简称，它是内核的一个子系统，有一个概念前提大家要了解：所有定义的标签和规则，最终都会被写到linux内核中。
通过libselinux这个库（相当于系统调用），可以完成应用层到内核空间的转换，最终进入LSM模块，然后真正授权的判断是通过内核中的核心模块SELINUX进行判断，他会去比较某个主体有什么权限。某个客体又需要什么权限，二者进行匹配比较判断。因此一个相对较完整的SEandroid模型可能就出来了。
继续分析Selinux如何进行权限检查：
涉及策略规则的编译过程。
selinux相关文件定义位置总结：
