Android SELinux

架构

从上层到驱动层的调用流程，但是我们重点关注sContext:

注：

• file_contexts //系统中所有file_contexts安全上下文

• seapp_contexts //app安全上下文

• property_contexts //属性的安全上下文

• service_contexts //service文件安全上下文

• genfs_contexts //虚拟文件系统安全上下文

以上文件system/sepolicy中都有对应的内容，例如：通过adb shell ls –Z指令查看文本的sContext，通过adb shell ps -Z指令可以查看进程的sContext

背景

在 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. SELinux则是由美国NSA（国安局）和一些公司（RedHat、Tresys）设计的一个针对Linux的安全加强系统

2. SELinux 按照默认拒绝的原则运行：任何未经明确允许的行为都会被拒绝

3. SELinux的两种模式

   • 宽容模式：权限拒绝事件会被记录下来，但不会被强制执行。

   • 强制模式：权限拒绝事件会被记录下来并强制执行。

作用

提高Android安全性。非法操作会被阻止，并且尝试进行的所有违规行为都会被内核记录到 dmesg 和 logcat 中。例如，app访问文件：/proc/sys/kernel/printk，app设置属性：persist.sys.log.level等

SEPolicy语言

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

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

相关设置

关闭 SELinux

• 临时关闭：setenforce

  $ setenforce 0

setenforce命令修改的是 /sys/fs/selinux/enforce 节点的值，是 kernel 意义上的修改 selinux 的策略。断电之后，节点值会复位。

• 永久关闭

  • kernel关闭selinux：SECURITY_SELINUX设置为false，重新编译kernel

  • 设置ro.boot.selinux=permissive属性，并且修改在system/core/init/Android.mk 中设置用于user版本下selinux模式为permissive

avc-denied问题解决

目前所有的 SELinux 权限检测失败，在 Kernel Log 或者 Android Log 中都有对应的 avc-denied log 与之对应。反过来，有 avc-denied log，并非就会直接失败，还需要确认当时 SELinux 的模式是 Enforcing 还是 Permissve。

如果是 Enforcing 模式，就要检测对应的进程访问权限资源是否正常？是否有必要添加？ 如果有必要添加，可以按照下面的方式生成需要的 sepolicy 规则并添加到对应 te 文件。

1. 从 logcat 或串口中提取相应的 avc-denied log，下面的语句为提取所有的 avc- denied log

   $ adb shell "cat /proc/kmsg | grep avc" > avc_log.txt

2. 使用 audit2allow 工具生成对应的 policy 规则

   audio2allow 使用必须先 source build/envsetup.sh，导入环境变量

   $ audit2allow -i avc_log.txt -p $OUT/vendor/etc/selinux/precompiled_sepolicy

3. 将对应的policy 添加到 te 文件中

   一般添加在 /device//common/sepolicy 或者 /device//$DEVICE/sepolicy 目录下:

   BOARD_SEPOLICY_DIRS += device/$SoC/common/sepolicy //通过这个命令添加厂家自定义的 sepolicy 规则

怎么抓取SELinux Log

1. adb shell dmesg----抓kernel log

   (特别说明：adb shell “cat /proc/kmsg | grep avc” > avc_log.txt 可以直接提出avc的log)

2. adb logcat –b events

   关键字：avc: denied

SEAndroid 安全机制框架

SELinux 系统比起通常的 Linux 系统来，安全性能要高的多，它通过对于用户，进程权限的最小化，即使受到攻击，进程或者用户权限被夺去，也不会对整个系统造成重大影响。

我们知道，Android 系统是基于 Linux 内核实现，针对 Linux 系统，NSA 开发了一套安全机制 SELinux，用来加强安全性。然而，由于 Android 系统有着独特的用户空间运行时，因此 SELinux 不能完全适用于 Android 系统。为此，NSA 针对 Android 系统，在 SELinux 基础上开发了 SEAndroid。

SEAndroid 安全机制所要保护的对象是系统中的资源，这些资源分布在各个子系统中，例如我们经常接触的文件就是分布文件子系统中的。实际上，系统中需要保护的资源非常多，除了前面说的文件之外，还有进程、socket 和 IPC 等等。对于 Android 系统来说，由于使用了与传统 Linux 系统不一样的用户空间运行时，即应用程序运行时框架，因此它在用户空间有一些特有的资源是需要特别保护的，例如系统属性的设置等。

以 SELinux 文件系统接口问边界，SEAndroid 安全机制包含内核空间和用户空间两部分支持。

这些内核空间模块与用户空间模块空间的作用及交互有：

1. 内核空间的 SELinux LSM 模块负责内核资源的安全访问控制

2. 用户空间的 SEAndroid Policy 描述的是资源安全访问策略。

   系统在启动的时候，用户空间的 Security Server 需要将这些安全访问策略加载内核空间的 SELinux LSM 模块中去，这是通过SELinux文件系统接口实现的。

3. 用户空间的 Security Context 描述的是资源安全上下文。

   SEAndroid 的安全访问策略就是在资源的安全上下文基础上实现的。

4. 用户空间的 Security Server 一方面需要到用户空间的 Security Context 去检索对象的安全上下文，另一方面也需要到内核空间去操作对象的安全上下文。

5. 用户空间的 libselinux 库封装了对 SELinux 文件系统接口的读写操作。

   用户空间的 Security Server 访问内核空间的 SELinux LSM 模块时，都是间接地通过 libselinux进行的。这样可以将对 SELinux 文件系统接口的读写操作封装成更有意义的函数调用。

6. 用户空间的 Security Server 到用户空间的 Security Context 去检索对象的安全上下文时，同样也是通过 selinux 库来进行的。