Android SELinux——基础介绍（一）

Android 系统的安全策略是保护用户的隐私和数据不受侵害的重要保证，一个相对安全的计算环境对于确保移动设备的安全至关重要。随着新的威胁不断出现，Android 的安全策略也在不断发展和完善，以应对新的挑战。

一、概念介绍

1、SELinux

SELinux（Security-Enhanced Linux）是一种基于强制访问控制 MAC 的安全增强模块，最初由美国国家安全局（NSA）开发，用于提高 Linux 操作系统的安全性。

它基于 FLASK（Flux Advanced Security Kernel）模型，这是一个由美国国防部门开发的安全内核模型。SELinux 通过 LSM 接口集成到 Linux 内核中，提供了比传统的自主访问控制 DAC 更强的安全性和灵活性。SELinux 的安全策略定义了系统中的所有对象（如文件、目录、网络端口等）和主体（如进程）之间的访问关系，确保只有经过授权的操作才能被执行。

DAC

DAC 即 Discretionary Access control，⾃主访问控制，即系统只提供基本的验证，特定资源的所有者可以控制与该资源关联的访问权限。这种系统通常⽐较粗放，并且容易出现⽆意中提权的问题。

Linux DAC 采⽤了⼀种⾮常简单的策略，将资源访问者分成三类，分别是Owner、Group 和 Other，资源针对这三类访问者设置不同的访问权限。⽽访问权限⼜分成 read、write 和 execute。
访问者通常是进程，有⾃⼰的 uid/gid，通过 uid/gid 和⽂件权限匹配，来确定是否可以访问。将 root 权限根据不同的应⽤场景划分成许多的 Root Capabilities，其中如果CAP_DAC_OVERRIDE 这项的话，可以直接绕过 Linux DAC 限制。
Linux DAC 有明显的不⾜，其中⼀个重要点就是 root 权限“⽆法⽆天”，⼏乎可以做任意情，⼀旦⼊侵者拿到 root 权限，即已经完全掌控了系统。另外，每⼀个进程默认都拿到对应这个⽤⼾的所有权限，可以改动/删除这个⽤⼾的所有⽂件资源，很明显，这个难以防⽌恶意软件。

MAC

MAC 即 Mandatory Access control，强制性访问控制，即系统针对每⼀项访问都进⾏严格限制，每次收到访问请求时都先咨询核⼼机构，再做出决定。

Linux MAC 针对 DAC 的不⾜，要求系统对每⼀项访问进⾏检查，每访问⼀个⽂件资源都需要进⾏对性的验证。⽽这个针对性的验证是根据已经定义好了的策略进⾏的。在 Linux Kernel，所有 MAC 机制都是搭建在 Linux Security Modules（LSM）基础上，包括有：SELinuxApparmor、Smack 和 TOMOYO Linux 等。⽬前 SELinux 已经成了事实上的⾏业标准。
针对 Linux DAC，MAC 可以明显弥补 DAC 的缺陷，⼀⽅⾯限制 root 权限，即使你有 root 权限，如果⽆法通过 MAC 验证，那么⼀样的⽆法真正执⾏相关的操作。另外对每⼀项权限进⾏了更加整的细化，可限制⽤⼾对资源的访问⾏为。

2、SEAndroid

SEAndroid (Security-Enhanced Android) 是 SELinux 在 Android 系统上的应用，它是在 Android 4.4 版本中正式引入的。

SEAndroid 为 Android 提供了一种基于 SELinux 的强制访问控制系统，增强了移动设备的安全性。它同样使用了 SELinux 的 MAC 模型来限制应用程序和服务的权限，从而防止恶意软件或误操作导致的数据泄露或其他安全问题。SEAndroid 的实现允许 Android 系统中的每个应用程序运行在一个受限的安全环境中，这样即使某个应用程序被攻破，攻击者也难以访问其他应用程序或系统数据。

演变过程

SELinux 在 Android 平台上的演变经历了多个阶段，逐步加强了系统的安全性。以下是各个版本的主要变化：

低于 Android 4.3：默认不支持 SELinux。在 Android 4.3 之前的版本中，默认情况下不启用 SELinux。SELinux 可能作为一个可选组件存在，但大多数设备并未启用。
Android 4.3：宽容模式（Permissive Mode）。在 Android 4.3 中，SELinux 被引入并默认处于宽容模式。在宽容模式下，SELinux 会记录所有违反安全策略的行为，但不会阻止这些行为。这主要是为了让开发者和系统管理员逐渐适应 SELinux，并检查现有系统是否存在潜在的安全问题。
Android 4.4：部分强制模式（Partial Enforcing Mode）。在 Android 4.4 中，SELinux 默认仍然是宽容模式，但在某些设备上开始尝试部分强制模式。在部分强制模式下，SELinux 对某些关键系统组件和资源进行强制访问控制。大多数设备依然处于宽容模式，但部分设备开始逐步过渡到强制模式。
Android 5.1：默认强制模式（Enforcing Mode）。在 Android 5.1 中，SELinux 默认启用强制模式。在强制模式下，SELinux 会严格地执行安全策略，阻止所有未授权的访问。这标志着 SELinux 在 Android 平台上全面启用，并成为默认的安全机制。
Android 8.0：强制模式且 Sepolicy 规则被分成多个部分。在 Android 8.0 中，SELinux 继续强化其安全性，并对 Sepolicy（安全策略）进行了改进。Sepolicy 规则被分成多个部分，以更好地组织和管理复杂的策略。这种拆分有助于提高策略的可读性和可维护性，同时也便于开发者和系统管理员进行更细粒度的控制。

通过这些演变，SELinux 在 Android 平台上逐步成为了重要的安全机制，显著提升了系统的安全性。

3、二者区别

应用场景：SELinux 主要应用于桌面和服务器环境的 Linux 系统，而 SEAndroid 是 SELinux 在移动操作系统 Android 上的具体实现。
定制化：SEAndroid 针对移动设备的特点进行了定制，例如，它考虑了移动设备特有的硬件组件和服务，如相机、GPS、Wi-Fi 等，以及移动应用生态系统的需求。
策略配置：虽然两者都基于 SELinux 的 MAC 模型，但是 SEAndroid 的安全策略可能更侧重于移动设备的安全需求，包括应用程序隔离、用户数据保护等方面。
兼容性：SEAndroid 在设计时考虑到了与 Android 系统的兼容性，确保在不影响用户体验的情况下提供安全增强功能。

总的来说，SEAndroid 是 SELinux 在 Android 平台上的特定实现，它继承了 SELinux 的许多特性，同时针对移动设备进行了优化和调整。

命名习惯

在 Android 平台上，尽管技术基础是 SELinux，但我们通常听到的是 SELinux 而不是 SEAndroid，这是因为：

命名习惯：SELinux 已经是一个广为人知的品牌和技术名词，在技术社区中有很高的知名度。因此，即使是 Android 中使用的版本，也倾向于沿用这个名称，以便于理解和沟通。
技术一致性：SEAndroid 实际上就是 SELinux 在 Android 系统中的一个实例化应用。它的架构和机制与 SELinux 完全相同，只是针对 Android 系统进行了一些必要的调整和适配，以适应移动设备的特殊需求。
品牌统一：Google 在推广 Android 安全性时，可能会选择使用更为人熟知的 SELinux 名称，而不是创造一个新的品牌 SEAndroid。这样可以利用 SELinux 的声誉来增强用户对 Android 安全性的信任。
文档和资料：由于 SELinux 的文档和资料非常丰富，使用 SELinux 这个术语也有助于开发者更容易地找到相关的文档和支持资料。

尽管如此，在某些场合下，特别是在讨论 Android 安全特性的具体实现时，SEAndroid 这个术语仍然会被提及，以强调这是 SELinux 在 Android 上的应用。然而，在日常交流中，SELinux 这个术语更加通用。

二、SELinux架构

1、SELinux作⽤

提⾼ Android 安全性。⾮法操作会被阻⽌，并且尝试进⾏的所有违规⾏为都会被内核记录到 dmesg 和 logcat 中。

SELinux 使⽤类型强制来改进强制访问控制。所有的主体（程序进程）对客体（⽂件/socket等资源）的访问都有⼀条 TE 规则来许可。当程序访问⼀个资源的时候，系统会搜索所有的 TE 规则集，并根据结果进⾏处理。这个规则集是由访问向量规则（AV， Access Vector）来描述的。

内核向外部暴露允许访问的资源权限，由 TE 来描述主体拥有什么样的访问权。

TE：即 Type Enforcement，它是根据 Security Label 中的 type 进⾏权限审查，审查 subject type 对 object type 的某个 class 类型中某种 permission 是否具有访问权限，是⽬前使⽤最为⼴泛的 MAC 审查机制，简单易⽤。
AVC：即Access Vector Cache，它是访问缓存，⽤来记录以往的访问验证情况，以便提⾼效率，快速处理。

2、SELinux架构

SELinux 是典型的 MAC - Mandatory Access Controls 实现，对系统中每个对象都⽣成⼀个安全上下⽂ (Security Context)，每⼀个对象访问系统的资源都要进⾏安全上下⽂审查。审查的规则包括类型强制检测（type enforcement），多层安全审查（Multi-Level Security），以及基于⻆⾊的访问控制（RBAC: Role Based Access Control）。

整体结构

SELinux 包含五个基本组成：

Security Policy Database：这是 SELinux 安全策略的核心部分，包含了所有的安全策略规则。这些规则定义了系统中不同安全标签（security labels）之间的访问权限。策略数据库决定了哪些主体（如进程）可以访问哪些客体（如文件），并且规定了访问的方式。
selinuxfs：⽤于处理⽂件系统的辅助模块。它是一个虚拟文件系统，它允许 SELinux 存储和检索有关系统状态的信息，比如当前的策略设置、上下文信息等。开发者和系统管理员可以通过访问 selinuxfs 来获取或修改 SELinux 的状态和配置。
Access Vector Cache (AVC)：访问向量缓存。AVC 是一种缓存机制，用于存储最近的访问决策结果，以加速未来的访问控制决策过程。当一个访问请求首次发生时，SELinux 会根据策略数据库做出决策并将结果缓存起来。如果同样的请求再次发生，SELinux 可以直接从 AVC 中获取结果，从而提高性能。
Policy enforcement server：⽤于验证 security context。这个组件负责实际执行安全策略，当一个进程尝试访问一个资源时，它会检查该进程的安全上下文（security context）是否允许它进行访问。如果访问请求违反了安全策略，policy enforcement server 将拒绝访问，并且可能记录 AVC 日志条目。
集成 Linux Security Modules 的 hooks sets：SELinux 作为 LSM（Linux Security Module）框架的一部分，使用了一系列的 hook 函数，这些函数在关键的系统调用点被调用。这些 hook 函数允许 SELinux 在适当的时候介入并实施其安全策略，从而确保所有的访问请求都符合定义的安全规则。

访问流程

访问流程如下，展示了进程通过系统调用访问某个资源时，SELinux 的验证过程：

进程发起系统调用：进程通过系统调用（System Call）尝试访问某个资源。
内核基本检测：进入内核后，首先进行一些基本的检测（如参数合法性检查等）。如果发现异常，则直接返回错误给用户空间。
Linux Kernel DAC 审查：内核会对请求进行自主访问控制 DAC 审查。如果 DAC 检查失败，则直接返回错误给用户空间。
调用 LSM hooks：如果 DAC 审查通过，内核会调用 LSM 的相关 hooks。这些 hooks 允许不同的安全模块介入访问控制流程。
SELinux hooks 进行 MAC 验证：SELinux 通过 LSM hooks 接收到访问请求，并进行强制访问控制 MAC 验证。SELinux 会检查请求的安全上下文（security context）是否允许访问目标资源。如果 MAC 验证失败，则直接返回错误给用户空间。
访问真正的系统资源：如果所有检查都通过，内核将继续执行系统调用，并访问真正的系统资源。
返回用户态，将结果反馈：内核将访问结果返回给用户态进程。

这个流程确保了 SELinux 在整个访问过程中能够有效地进行安全控制。