SEAndroid 相关知识
本文图片和内容摘自罗升阳的博客《SEAndroid安全机制框架分析》
如需了解详细内容，请访问原博客。
1. 整体框架
- 在内核空间，主要涉及到一个称为SELinux LSM的模块
- 在用户空间，涉及到Security Context、Security Server和SEAndroid Policy
2. 内核空间
与SELinux Security Server相关的一个内核子模块是LSM，全称是Linux Security Model，这个模块包含有一个访问向量缓冲（Access Vector Cache）和一个安全服务（Security Server）。Security Server负责安全访问控制逻辑，即由它来决定一个主体访问一个客体是否是合法的。这里说的主体一般就是指进程，而客体就是主体要访问的资源，例如文件。
SELinux与LSM和内核中的子系统交互过程如下：
首先，SELinux会在LSM中注册相应的回调函数；其次，LSM会在相应的内核对象子系统中会加入一些Hook代码。例如，我们调用系统接口read函数来读取一个文件的时候，就会进入到内核的文件子系统中。在文件子系统中负责读取文件函数vfs_read就会 调用LSM加入的Hook代码。这些Hook代码就会调用之前SELinux注册进来的回调函数，以便后者可以进行安全检查。
SELinux在进行安全检查的时候，首先是看一下自己的Access Vector Cache是否已经有结果。如果有的话，就直接将结果返回给相应的内核子系统就可以了。如果没有的话，就需要到Security Server中去进行检查。检查出来的结果在返回给相应的内核子系统的同时，也会保存在自己的Access Vector Cache中，以便下次可以快速地得到检查结果。
- 一般性错误检查，例如访问的对象是否存在、访问参数是否正确等。
- DAC检查，即基于Linux UID/GID的安全检查。
- SELinux检查，即基于安全上下文和安全策略的安全检查。
3. 用户空间
在用户空间中，SEAndroid包含有三个主要的模块，分别是安全上下文（Security Context）、安全策略（SEAndroid Policy）和安全服务（Security Server）。
3.1 安全上下文
安全上下文实际上就是一个附加在对象上的标签（Tag）。这个标签实际上就是一个字符串，它由四部分内容组成，分别是SELinux用户、SELinux角色、类型、安全级别，每一个部分都通过一个冒号来分隔，格式为“user:role:type:sensitivity”。
在开启了SEAndroid安全机制的设备上执行带-Z选项的ls命令，就可以看到一个文件的安全上下文：
# ls -Z init.rc
u:object_r:rootfs:s0 init.rc init.rc
在安全上下文标签的四个部分中，只有类型（Type）才是最重要的，SELinux用户、SELinux角色和安全级别都几乎可以忽略不计的。正因为如此，SEAndroid安全机制又称为是基于TE（Type Enforcement）策略的安全机制。
3.1.1 用户和角色
对于进程来说，SELinux用户和SELinux角色只是用来限制进程可以标注的类型。而对于文件来说，SELinux用户和SELinux角色就可以完全忽略不计。为了完整地描述一个文件的安全上下文，通常将它的SELinux角色固定为object_r，而将它的SELinux用户设置为创建它的进程的SELinux用户。
在SEAndroid中，只定义了一个SELinux用户u，因此我们通过ps -Z和ls -Z命令看到的所有的进程和文件的安全上下文中的SELinux用户都为u。同时，SEAndroid也只定义了一个SELinux角色r，因此，我们通过ps -Z命令看到的所有进程的安全上下文中的SELinux角色都为r。
用户定义在system/sepolicy/private/users中，内容如下：
user u roles { r } level s0 range s0 - mls_systemhigh;
上述语句声明了一个SELinux用户u，它可用的SELinux角色为r，它的默认安全级别为s0，可用的安全级别范围为s0~mls_systemhigh，其中，mls_systemhigh为系统定义的最高安全级别。
角色定义在system/sepolicy/private/roles_decl中，内容如下：
role r;
上述语句声明了一个SELinux角色r。
3.1.2 安全级别
安全级别实际上是一个MAC安全机制，它是建立在TE的基础之上的。在SELinux中，安全级别是可选的，也就是说，可以选择启用或者不启用。
在基于安全级别的MAC安全机制中，主体（subject）和客体（object）都关联有一个安全级别。其中，安全级别较高的主体可以读取安全级别较低的客体，称为“read down”；而安全级别较低的主体可以写入安全级别较高的客体，称为“write up”。
通过这种规则，可以允许数据从安全级别较低的主体流向安全级别较高的主体，而限制数据从安全级别较高的主体流向安全级别较低的主体，从而有效地保护了数据。注意，如果主体和客体的安全级别是相同的，那么主体是可以对客体进行读和写的。数据流向如下图所示，我们定义了两个安全级别：PUBLIC和SECRET，其中，SECRET的安全级别高于PUBLIC。
在实际使用中，安全级别是由敏感性（Sensitivity）和类别（Category）两部分内容组成的，格式为“sensitivity[:category_set]”，其中，category_set是可选的。例如，假设我们定义有s0、s1两个Sensitivity，以c0、c1、c2三个Category，那么“s0:c0,c1”表示的就是Sensitivity为s0、Category为c0和c1的一个安全级别。
3.1.3 类型
在SEAndroid中，我们通常将用来标注文件的安全上下文中的类型称为file_type，而用来标注进程的安全上下文的类型称为domain，并且每一个用来描述文件安全上下文的类型都将file_type设置为其属性，每一个用来描述进程安全上下文的类型都将domain设置为其属性。
将一个类型设置为另一个类型的属性可以通过type语句实现。例如以下语句将类型 domain设置类型init的属性：
type init domain;
3.2 安全策略
SEAndroid安全机制中的安全策略是在安全上下文的基础上进行描述的，也就是说，它通过主体和客体的安全上下文，定义主体是否有权限访问客体。
在system/sepolicy目录中，所有以.te为后缀的文件经过编译之后，就会生成一个sepolicy文件。
打开某个.te文件，里面会有allow语句。一个Type所具有的权限是通过allow语句来描述的，以下这个allow语句：
allow unconfineddomain domain:binder { call transfer set_context_mgr };
表明domain为unconfineddomain的进程可以与其它进程进行binder ipc通信（call），并且能够向这些进程传递Binder对象（transfer），以及将自己设置为Binder上下文管理器（set_context_mgr）。
SEAndroid使用的是最小权限原则，也就是说，只有通过allow语句声明的权限才是允许的，而其它没有通过allow语句声明的权限都是禁止，这样就可以最大限度地保护系统中的资源。
3.3 安全服务
用户空间的Security Server主要是用来保护用户空间资源的，以及用来操作内核空间对象的安全上下文的，它由应用程序安装服务PackageManagerService、应用程序安装守护进程installd、应用程序进程孵化器Zygote进程以及init进程组成。
PackageManagerService和installd负责创建App数据目录的安全上下文，Zygote进程负责创建App进程的安全上下文，而init进程负责控制系统属性的安全访问。