传统Linux系统的安全保护主要基于DAC（Discretionary Access Control ，自主访问控制）。DAC的核心思想是：由资源（如文件、目录）的所有者确定该资源的访问权限（如读、写、执行）。DAC的控制策略灵活，但不严谨，存在一定的安全隐患。例如，基于DAC的Linux，由于 root 权限过大，一旦黑客入侵Linux操作系统并获得root权限，整个操作系统将暴露于恶意攻击的威胁之下。因此，为了提高操作系统的安全性，研究人员提出了SELinux（Security Enhanced Linux，安全增强型Linux），并集成到Linux内核中。
SELinux起源于1980年开始的微内核和操作系统安全研究，是由美国国家安全局（National Security Agency，NSA）和一些公司(RedHat等)基于Flask（Flux Advanced Security Kernel）架构开发的一种强制访问控制系统。NSA，在2001年引入SELinux作为内核补丁；在2003年完成了SELinux到LSM（Linux Security Modules，Linux内核安全模块）的迁移，并入到Linux2.6的内核主线[1]。
SELinux安全机制采用MAC（Mandatory Access Control，强制访问控制）的方式实现，目的是通过限制系统中的任何进程(包括root进程)以及用户对资源的访问，任何进程在SELinux系统中执行任何操作之前，都必须在安全策略的配置文件中赋予权限。若没有在安全策略中配置的权限，进程就不能执行该权限所对应的操作，从而减小或阻止由于DAC机制的缺陷所带来的安全威胁，进而提供更细粒度的权限控制管理。
SELinux在Android中应用主要有以下优势：
-
SELinux可以全面保护Android中的各种系统daemon，让它们避免来自恶意程序的危害；
-
SELinux可以完全控制Android应用程序与内核层之间的交互，也能控制应用程序对系统资源的访问；
-
SELinux提供了灵活的安全策略配置机制，能无缝集成到Android系统。
因此，从Android4.3版本开始，谷歌将SELinux移植到了Android系统中，并且命名为SEAndroid[2]。
2.1 SEAndroid框架
图1 SEAndroid框架
SEAndroid框架如图1所示，在SEAndroid的框架中，通过SELinux的文件系统，将其划分为了用户空间和内核空间。用户空间中包含了安全上下文、安全服务、selinux库libselinux。内核空间包含LSM，两者通过SELinux文件系统进行隔离，并通过libselinux库进行交互[3]。
-
安全上下文：用来对主体和客体进行标记，在SEAndroid中，每一个进程和文件都会与一个安全上下文[4]进行关联。该安全上下文由用户、角色、类型、安全级别这四个部分组成安全上下文，例如，u:r:t:s0描述的就是一个SEAndroid安全上下文。当每一个进程和文件都关联上一个安全上下文之后，就能基于这些安全上下文制定安全访问策略。
-
安全服务：需要到安全上下文中去检索对象的安全上下文，也需要到内核空间去操作安全上下文，安全服务主要针对于安全上下文和策略管理。
-
SEAndroid策略库：安全访问策略。系统在启动的时候，用户空间的安全服务需要将这些安全访问策略加载内核空间SELinux的 LSM模块中。
-
libselinux库：用户空间的libselinux库封装了对SELinux文件系统接口的读写操作，用户空间的安全服务访问内核空间的LSM模块时，都是间接地通过libselinux进行的。用户空间的安全服务检索用户空间的安全策略时，同样也是通过 libselinux库来进行的。
-
LSM模块：LSM是内核通用的一个安全模块，SELinux可以使用，其他模块也可以使用，因此LSM仅提供机制实现而不提供策略实现。
2.2 用户空间
在用户空间中，SEAndroid包含有三个主要的模块，分别是安全上下文（Security Context）、安全策略（SEAndroid Policy）和安全服务（Security Server）。
1）安全上下文：
SEAndroid是一种基于安全策略的MAC安全机制。这种安全策略也是建立在对象的安全上下文的基础上的。这里所说的对象分为两种类型，一种称主体（Subject），一种称为客体（Object）。主体通常是指进程，而客观是指进程所要访问的资源（如文件、系统属性等）。
安全上下文实际上是一个附加在对象上的标签(Tag)，用来对主体和客体进行标记，在SEAndroid中无论是进程还是文件都拥有一个安全上下文，此安全上下文是由用户、角色、类型、安全级别四个部分组成，各个部分之间用冒号进行分隔。
格式为“user:role:type:sensitivity”，具体如：u:object_r:rootfs:s0就是一个文件的安全上下文，其中：
-
u：表示用户user，创建这个文件的用户。
-
object_r：表示这是个文件，在SEAndroid中的所有文件都用object_r来表示。
-
rootfs：表示一个文件的类型，如果是进程的话此项表示为域(domain)。
-
s0：安全级别，表示用户只能读取自己的敏感度级别及更低级别的文件，数据只能从较低级别流入到更高级别，且不会从高级别流向低级别，无法写入，只能读取，保证机密性。
SEAndroid上的安全策略采用了SELinux中的域名/类型强制机制，在SEAndroid中，我们通常将用来标注文件的安全上下文类型称为file_type，用来标注进程的安全上下文类型称为domain。
这里我们只讨论四种类型对象的安全上下文，分别是App进程、App数据文件、系统文件和系统属性。这四种类型对象的安全上下文通过四个文件来描述：mac_permissions.xml、seapp_contexts、file_contexts和property_contexts。
mac_permissions.xml和seapp_contexts：应用的安全上下文和其对应可以访问的文件类型，是由mac_permissions.xml和seapp_contexts两个文件来决定的。
在应用安装的过程中，包管理服务将应用标记为在mac_permissions.xml文件中定义的称为seinfo常量。
文件mac_permissions.xml给不同签名的App分配不同的seinfo字符串，例如，在AOSP源码环境下编译并且使用平台签名的App获得的seinfo为“platform”，使用第三方签名安装的App获得的seinfo签名为“default”。
seapp_contexts 是 SELinux 移植到 Android 平台后新添加的文件，为了对所要安装的应用程序和应用程序生成的文件内容进行安全标记。对于平台签名的应用程序来说，其 seinfo 为“platform”，user 为“_app”。
file_contexts：通过正则表达式来描述系统文件的安全上下文，当系统完全启动并且SEAndroid安全机制的策略加载完成时，file_contexts中定义的所有文件和目录都会被直接标记上安全上下文，所有上下文中的对应的type都会定义在file.te中。
property_contexts：针对Android系统中的系统属性资源的文件，此类文件可以被用来控制系统的行为或者获取系统的相关信息，SEAndroid 同样会为这些属性资源标记安全上下文。
2）安全服务
用户空间的安全服务主要是用来保护用户空间资源，以及用来操作内核空间对象的安全上下文，它是由包管理服务、应用程序安装守护进程installd、应用程序进程孵化器Zygote进程以及init进程组成。其中，包管理服务和installd负责创建App数据目录的安全上下文，Zygote进程负责创建App进程的安全上下文，而init进程负责控制系统属性的安全访问。
包管理服务在启动的时候，会定位到mac_permissions.xml文件，然后对它进行解析，得到App签名或者包名与seinfo的对应关系。当包安装服务安装App的时候，它会根据其签名或者包名查找到对应的seinfo，并且将这个seinfo传递给另外一个守护进程installd。
守护进程installd负责创建App数据目录。在创建App数据目录的时候，需要给它设置安全上下文，使得SEAndroid安全机制可以对它进行安全访问控制。installd根据包管理服务传递过来的seinfo，并且通过调用libselinux库定位到seapp_contexts文件中查找到对应的Type，根据此Type，installd能够给正在安装的APP数据目录设置安全上下文。
在Android系统中，Zygote进程负责创建应用程序进程。应用程序进程是SEAndroid安全机制中的主体，它们也需要设置安全上下文，由Zygote进程来设置。组件管理服务ActivityManagerService在请求Zygote进程创建应用程序进程之前，会到包管理服务中去查询对应的seinfo，并且将这个seinfo传递到Zygote进程。因此，Zygote进程在fork一个应用程序进程之后，就会使用ActivityManagerService传递过来的seinfo，并且调用libselinux库找到seapp_contexts文件中查找到对应的域。有了这个域之后，Zygote进程就能够创建的应用程序进程设置安全上下文。
3）安全策略
SEAndroid安全机制中的安全策略是在安全上下文的基础上进行描述的，也就是说，它通过主体和客体的安全上下文，定义主体是否有权限访问客体，这种安全策略就称类型强制访问Type Enforcement，简称TE。
TE策略的表达式为：
rule_name source_type target_type：class perm_set；
-
rule_name：TE的规则名称，如allow表示授权等。
-
source_type：源类型。
-
target_type：目标类型。
-
class：类别，目标客体是哪种类别，主要有file，dir，socket等。
-
perm_set：许可集，许可集是指某种客体类别所拥有的操作，比如文件类所拥有的读、写、执行、链接、创建等操作组成的集合称为许可集。
例1：allow system_app system_data_file:dircreate_dir_perms;
上述语句表示允许具有system_app 属性的进程在具有system_data_file属性类型的文件夹中创建文件。
例2：allow init fotad:unix_stream_socket { bind create }；
上述语句表示允许init类型对fotad类型的unix_stream_socket 进行bind和create的操作。
在TE中，与source_type，target_type相关的命令有三种：
-
type：用来定义一个类型或者将某个类型与某个attribute结合起来。
-
attribute：用来定义一个属性。
-
typeattribute：将某个type和某个或多个attribute关联起来。
可以在定义type的时候，直接将其和某个attribute关联，也可以单独通过typeattribue将某个type和某个或多个attribute关联起来。
attribute 表示是多个具有共性的 type 的集合，之所以使用 attribute，是因为系统通常会定义非常多的 type，每个 type 都需要通过 allow 语句设置相应权限，有了attribute 之后就可以将这些 type 与某个 attribute 关联起来只使用一个 allow 语句，直接将source_type设置为这个attribute即可。
例：type shell，domain
上述语句表示给shell赋予一个domain属性，即将shell添加到domain这个集合里，若有一个allow domain ××语句，则同样也有allow shell ××。
2.3 内核空间策略访问控制过程
在内核空间中，存在一个SELinux LSM模块，这个模块包含有一个访问向量缓存（Access Vector Cache）和一个安全服务。安全服务负责安全访问控制逻辑，即由它来决定一个主体访问一个客体是否是合法的。这里说的主体一般是指进程，而客体是主体要访问的资源（如文件）。SELinux、LSM和内核子系统的交互过程如下：
内核中的资源在访问过程中，首先会进行DAC检查，即基于Linux UID/GID的安全检查，SELinux检查如下：
SELinux在进行安全检查的时候，首先是看自己的AVC是否已经有结果，AVC缓存有主体和对象的访问权限。如果有，直接将结果返回给相应的内核子系统；如果没有，需要到安全服务中去进行检查。检查出来的结果在返回给相应的内核子系统的同时，也会保存在自己的AVC中，以便下次可以快速地得到检查结果[5]。
图2 SELinux安全访问控制流程
通过在Android中引入SELinux安全机制，可以更好地限制系统服务的访问权限，并控制应用程序对系统资源的访问，降低恶意软件的影响，提高Android系统的安全性。
参考文献
[1] M. Bill. SELinux：NSA's Open Source Security Enhanced Linux[M]. O'Reilly, 2004.
[2] Android 中的安全增强型 Linux：https://source.android.google.cn/security/selinux?hl=zh-cn
[3] 李子健. 基于SEAndroid的敏感数据主被动防御机制分析与设计[D].北京邮电大学,2019.
[4] Mayer F, Caplan D, MacMillan K. SELinux by example: using security enhanced Linux[M]. Pearson Education, 2006.
[5] 林学森.深入理解Android内核设计思想[M].北京：人民邮电出版社，2017.
原文始发于微信公众号（vivo千镜）：Android中的SELinux机制介绍
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论