android 8.1 安全机制 — SEAndroid & SELinux

1. SELinux 背景知识

1.1 DAC 与 MAC

在 SELinux 出现以前，Linux 上的安全模型叫 DAC，全称是 Discretionary Access Control，翻译为自主访问控制。

DAC 的核心思想很简单，就是：进程理论上所拥有的权限与执行它的用户的权限相同。好比，以 root 用户启动 Browser，那么 Browser 就有 root 用户的权限，在 Linux 系统上能干任何事情。

显然，DAD 管理太过宽松，只要想办法在 Android 系统上获取到 root 权限就能够了。那么 SELinux 是怎么解决这个问题呢？在 DAC 以外，它设计了一种新的安全模型，叫 MAC（Mandatory Access Control），翻译为强制访问控制。

MAC 的理论也很简单，任何进程想在 SELinux 系统上干任何事情，都必须在《安全策略文件》中赋予权限，凡是没有出如今安全策略文件中的权限，就不行。

关于 DAC 和 MAC，能够总结几个知识点：

1. Linux 系统先作 DAC 检查。若是没有经过 DAC 权限检查，则操做直接失败。经过 DAC 检查以后，再作 MAC 权限检查
2. SELinux 有本身的一套规则来编写安全策略文件，这套规则被称之为 SELinux Policy 语言。

1.2 SEPolicy 语言

Linux中有两种东西，一种死的（Inactive），一种活的（Active）。死的东西就是文件（Linux哲学，万物皆文件。注意，万不可狭义解释为File），而活的东西就是进程。此处的 死 和 活 是一种比喻，映射到软件层面的意思是：进程能发起动做，例如它能打开文件并操做它。而文件只能被进程操做。

根据 SELinux 规范，完整的 Secure Context 字符串为：user:role:type[:range]

1.2.1 进程的 Secure Context

在 SELinux 中，每种东西都会被赋予一个安全属性，官方说法叫作 Security Context，Security Context 是一个字符串，主要由三个部分组成，例如 SEAndroid 中，进程的 Security Context 可经过 ps -Z 命令查看：

rk3288:/ $ ps -AZ
u:r:hal_wifi_supplicant_default:s0 wifi      1816     1   11388   6972 0                   0 S wpa_supplicant
u:r:platform_app:s0:c512,c768  u0_a14        1388   228 1612844  57396 0                   0 S android.ext.services
u:r:system_app:s0              system        1531   228 1669680 119364 0                   0 S com.android.gallery3d
u:r:kernel:s0                  root           582     2       0      0 0                   0 S [kworker/1:2]
u:r:radio:s0                   radio          594   228 1634876  89296 0                   0 S com.android.phone
u:r:system_app:s0              system         672   228 1686204 141716 0                   0 S com.android.settings
u:r:platform_app:s0:c512,c768  u0_a18         522   223 1721656 152116 0                   0 S com.android.systemui

上面的最左边的一列就是进程的 Security Context，以第一个进程 wpa_supplicant 为例

u:r:hal_wifi_supplicant_default:s0

其中:

• u 为 user 的意思，SEAndroid 中定义了一个 SELinux 用户，值为 u
• r 为 role 的意思，role 是角色之意，它是 SELinux 中一个比较高层次，更方便的权限管理思路。简单点说，一个 u 能够属于多个 role，不一样的 role 具备不一样的权限。
• hal_wifi_supplicant_default 表明该进程所属的 Domain 为 hal_wifi_supplicant_default。MAC（Mandatory Access Control）强制访问控制 的基础管理思路实际上是 Type Enforcement Access Control（简称TEAC，通常用TE表示），对进程来讲，Type 就是 Domain，好比 hal_wifi_supplicant_default 须要什么权限，都须要经过 allow 语句在 te 文件中进行说明。
• s0 是 SELinux 为了知足军用和教育行业而设计的 Multi-Level Security（MLS）机制有关。简单点说，MLS 将系统的进程和文件进行了分级，不一样级别的资源须要对应级别的进程才能访问

1.2.2 文件的 Secure Context

文件的 Secure Context 能够经过 ls -Z 来查看，以下

rk3288:/vendor/lib $ ls libOMX_Core.so -Z
u:object_r:vendor_file:s0 libOMX_Core.so

• u：一样是 user 之意，它表明建立这个文件的 SELinux user
• object_r：文件是死的东西，它无法扮演角色，因此在 SELinux 中，死的东西都用 object_r 来表示它的 role
• vendor_file：type，和进程的 Domain 是一个意思，它表示 libOMX_Core.so 文件所属的 Type 是 vendor_file
• s0：MLS 的等级

1.3 TE 介绍

MAC 基本管理单位是 TEAC（Type Enforcement Accesc Control），而后是高一级别的 Role Based Accesc Control。RBAC 是基于 TE 的，而 TE 也是 SELinux 中最主要的部分。上面说的 allow 语句就是 TE 的范畴。

根据 SELinux 规范，完整的 SELinux 策略规则语句格式为：

allow domains types:classes permissions;

- Domain - 一个进程或一组进程的标签。也称为域类型，由于它只是指进程的类型。
- Type - 一个对象（例如，文件、套接字）或一组对象的标签。
- Class - 要访问的对象（例如，文件、套接字）的类型。
- Permission - 要执行的操做（例如，读取、写入）。

= allow ： 容许主体对客体进行操做
= neverallow ：拒绝主体对客体进行操做
= dontaudit ： 表示不记录某条违反规则的决策信息
= auditallow ：记录某项决策信息，一般 SElinux 只记录失败的信息，应用这条规则后会记录成功的决策信息。

使用政策规则时将遵循的结构示例：

语句：
allow appdomain app_data_file:file rw_file_perms;

这表示全部应用域均可以读取和写入带有 app_data_file 标签的文件

—> 相关实例

1. SEAndroid 中的安全策略文件 policy.conf
# 容许 zygote 域中的进程向 init 域中的进程（Object Class 为 process）发送 sigchld 信号
allow zygote init:process sigchld;
2. # 容许 zygote 域中的进程 search 或 getattr 类型为 appdomain 的目录。
# 注意，多个 perm_set 可用 {} 括起来
allow zygote appdomain:dir { getattr search };

3. # perm_set 语法比较奇特，前面有一个 ~ 号。
   # 它表示除了{entrypoint relabelto}以外，{chr_file #file}这两个object_class所拥有的其余操做 
  allow unconfineddomain {fs_type dev_type file_type}:{ chr_file file }   \
  ~{entrypoint relabelto};