SELinux（Security-Enhanced Linux）是一种在 Linux 系统中实现强制访问控制（MAC）的安全机制。它能够对系统资源进行细粒度的访问控制，提高系统的安全性和防范能力。

SELinux 基本概念和原理

SELinux 是基于 Mandatory Access Control（强制访问控制）的安全机制，在 Linux 内核上运行。它通过给每个系统资源（如文件、设备、进程）分配一个安全标签，并在策略中定义详细的权限规则，来限制进程对资源的访问。与传统的 Discretionary Access Control（自主访问控制）相比，SELinux 提供了更细粒度的安全控制，使得即使某个进程被入侵或者存在漏洞，入侵者也难以获得系统资源和敏感信息。

SELinux 的安装和启用

1. 通常，在 Linux 发行版中，SELinux 已经默认安装并启用。可以使用命令 sestatus 来查看 SELinux 的状态。
2. 如果 SELinux 未安装或未启用，可以通过安装相关软件包和编辑配置文件进行设置。

SELinux 策略

SELinux 的核心是策略，它定义了安全上下文的规则和权限。策略文件通常位于 /etc/selinux 目录下，可以使用工具来管理和配置策略。

设置 SELinux 标签

在 SELinux 中，所有系统资源都有一个唯一的安全上下文标签。对于文件和目录，可以使用命令 ls -Z 来查看和更改安全上下文标签。对于进程，可以使用 ps -eZ 查看其安全上下文。当系统资源被创建时，SELinux 会自动分配适当的安全上下文标签。

SELinux 策略模式

SELinux 可以可以在三种不同的策略模式下运行：强制（Enforcing）、警告（Permissive）和禁用（Disabled）。在强制模式下，SELinux 会严格执行策略规则，并记录违反规则的操作。在警告模式下，SELinux 同样会执行策略规则，但只会输出警告信息而不阻止操作。在禁用模式下，SELinux 不会应用任何策略规则。

配置 SELinux 策略

可以通过修改策略文件或使用命令行工具来配置 SELinux 策略。要修改策略文件，需要熟悉策略语言和规则。要使用命令行工具，可以使用 setsebool 来设置布尔值， semanage 来管理策略模块和端口，以及 restorecon 来恢复文件的安全上下文。

SELinux 日志

SELinux 会将违反策略规则的操作记录到系统日志中。可以使用命令 ausearch 、 sealert 和 audit2allow 来查看和分析 SELinux 日志，以了解系统中发生的安全事件和违规行为。

SELinux 上下文管理

SELinux 使用安全上下文标签来标识和管理资源。安全上下文由三个部分组成：用户（user）、角色（role）和类型（type）。可以使用 chcon 命令来更改文件或目录的安全上下文，而 semanage fcontext 命令用于持久性地配置文件上下文。

SELinux 和服务管理

在 Linux 系统中，很多服务都运行在不同的进程中，每个进程都有一个特定的安全上下文。当启用 SELinux 时，需要对服务的安全上下文进行配置，以确保服务能够正常运行并与其他资源进行交互。可以使用 semanage 命令来管理服务的策略模块和端口。

SELinux 和应用程序

对于自定义开发的应用程序，在启用 SELinux 时，需要进行应用程序的 SELinux 策略配置。这包括定义应用程序需要的安全上下文类型和访问规则，以及使用工具来检查和调试应用程序与 SELinux 的交互。

SELinux 和审计

SELinux 通过审计机制记录违反策略规则的操作。可以使用工具来分析和审计 SELinux 日志，以识别和调查安全事件和违规行为。

结论

使用 SELinux 进行 Linux 系统安全加固可以大大提高系统的安全性。通过实施强制访问控制、细粒度的访问控制规则和审计机制，SELinux 有助于保护系统资源、防止未经授权的访问，并增强系统的整体安全性。

SELinux权限

在了解SELinux之前，我们先来了解一下Linux的两种访问控制策略：DAC和MAC

DAC，自主访问控制（Discretionary Access control）。系统只提供基本的验证, 完整的访问控制由开发者自己控制。DAC将资源访问者分成三类：Owner、Group、Other 。将访问权限也分成三类：read、write、execute 资源针对资源访问者设置不同的访问权限。访问者通常是各个用户的进程，有自己的uid/gid，通过uid/gid 和文件权限匹配, 来确定是否可以访问。DAC机制下，每一个用户进程默认都拥有该用户的所有权限。 DAC 有两个严重问题：问题一：因为Root用户是拥有所有权限的，所以DAC对Root用户的限制是无效的。并且在Linux Kernel 2.1以后，Linux将Root权限根据不同的应用场景划分成许多的Root Capabilities, 普通用户也可以被设置某个Root Capability。普通用户如果被设置了CAP_DAC_OVERRIDE， 也可以绕过 DAC 限制。问题二：用户进程拥有该用户的所有权限，可以修改/删除该用户的所有文件资源, 难以防止恶意软件。

可见，DAC 有明显的缺陷，一旦被入侵，取得Root权限的用户进程就可以无法无天，胡作非为，早期android版本就深受其害。

MAC， 强制性访问控制（Mandatory Access control）。 系统针对每一项访问都进行严格的限制, 具体的限制策略由开发者给出。

Linux MAC 针对DAC 的不足, 要求系统对每一项访问, 每访问一个文件资源都需要根据已经定义好了的策略进行针对性的验证。系统可以针对特定的进程与特定的文件资源来进行权限的控制。即使是root用户，它所属的不同的进程，并不一定能取得root权限，而得要看事先为该进程定义的访问限制策略。如果不能通过MAC 验证，一样无法执行相关的操作。

与DAC相比，MAC访问控制的“主体”变成了“进程”而不是用户。这样可以限制了Root 权限的滥用，另外要求对每一项权限进行了更加完整的细化, 可以限制用户对资源的访问行为。

SELinux就是目前最好的MAC机制，也是目前的行业标准。

SELinux，安全增强Linux（Security-Enhanced Linux），是由美国国家安全局(NSA)发起, 多个非营利组织和高校参与开发的强制性安全审查机制（Mandatory Access control，简称MAC）。SELinux最早于2000年12月采用GPL许可发布。目前，Linux Kernel 2.6 及以上的版本都已经集成了SELinux。

SELinux 分成三种模式：

Android 5.x及以上强制开启，因此，disabled(关闭)模式并没有什么用了。 通常在调试时，我们会启用Permissve(宽容模式), 以便尽可能的发现多的问题, 然后一次修正。 在量产时启用Enfocing mode(强制模式)来保护系统。

查看SELinux模式：adb shell getenforce 设置SELinux模式：adb shell setenforce 1 //0是Permissve，1是Enfocing

SELinux 的访问控制示意图：

通常我们开发的过程中，就是配置Subject、Object、Security Policy。

SELinux 给Linux 的所有对象都分配一个安全上下文(Security Context)， 描述成一个标准的字符串。

安全上下文的标准格式： user:role:type[:range]

Security Label 用来绑定被访问资源和安全上下文，描述它们的对应关系。标准格式为：resource security_context。即：res user:role:type[:range]。这里也可以使用通配符，例如 net.就可以绑定所有以net.开头的属性，除此之外，还有类似正则表达式的*、？等等通配符。Security Label 都定义在type_contexts当中，例如file的定义在file_contexts中，service定义在service_contexts中，property定义在property_contexts中。 举例： file_contexts:

service_contexts:

查看进程安全上下文： ps -AZ 。例如，查看Settings进程的安全上下文，ps -AZ | grep settings： u:r:system_app:s0 system 1381 585 0 0 S 查看文件安全上下文： ls -Z 。例如，查看文件的安全上下文： u:object_r:system_file:s0

Type Enforcement (TE) 是根据Security Context中的 type 进行权限审查, 审查 subject type 对 object type 的某个class 类型中某种permission 是否具有访问权限，是目前使用最为广泛的MAC 审查机制, 简单易用。

TE控制语句格式 : rule_namesource_typetarget_type : class perm_set

Type Enforcement规则说明：

举个例子，、中定义的TE规则： allow logd runtime_event_log_tags_file:file rw_file_perms; dontaudit domain runtime_event_log_tags_file:file { open read }; auditallow tombstoned anr_data_file:file { append write }; neverallow logd { app_data_file system_data_file }:dir_file_class_set write;

SELinux 中每一个进程或者文件都对应一个type, 而每一个type 都对应有一个或几个attribute。所有常见的attribute定义在以下文件中： system/sepolicy/public/attributes system/sepolicy/prebuilts/api/[build version]/public/attributes system/sepolicy/prebuilts/api/[build version]/private/attributes 其中的[build version]即为android版本号，例如android O为28.0。常见的attribute定义：

Type对应一个或者几个attribute，Type的定义格式： type type_name, attribute1, attribute2； Type的定义通常分散在各个te文件中。例如，常用普通文件的type定义在中：

SEAndroid对于不同的资源类型，定义了不同的Class。比如普通的file、socket等等，比如SELinux 使用的security, 比如针对每个process 参数的process 等定义相关的class。这些class，每一个class 都有相对应的permissions。 比如file 就有 read, write, create, getattr, setattr, lock, ioctl 等等. 比如process 就有fork, sigchld, sigkill, ptrace, getpgid, setpgid 等等。这些相关的class, 以及他们具有那些Permissions都定义在以下文件中： system/sepolicy/private/access_vectors system/sepolicy/reqd_mask/access_vectors system/sepolicy/prebuilts/api/版本号/private/access_vectors 例如：

定义完之后，在以下对应的security_classes 文件中声明定义的classes。 system/sepolicy/private/security_classes system/sepolicy/reqd_mask/security_classes system/sepolicy/prebuilts/api/版本号/private/security_classes 例如：

注意，Classes 和Permissions的定义与Kernel 中相关API是强相关的，普通用户严禁修改。

在SELinux 中, 我们通常称一个进程是一个domain, 一个进程fork 另外一个进程并执行(exec) 一个执行档时, 我们往往会涉及到domain 的切换. 比如init 进程, SELinux 给予了它很大的权限, 而它拉起的服务, 我们要限制这个服务的权限，于是就涉及到从一个domain 切换到另外一个domain, 不然默认就使用init 进程的domain.

在SELinux 里面有专门的一条语法: type_transition statement. 在准备切换前我们先要确保有相关的权限操作：

如下面的demo, init 拉起apache 并且切换到 apache 的domain. (1). 首先，你得让init_t域中的进程能够执行type为apache_exec_t的文件 allow init_t apache_exec_t : file {read getattr execute}; (2). 然后，你还得告诉SELinux，允许init_t做DT切换以进入apache_t域 allow init_t apache_t : process transition; (3). 然后，你还得告诉SELinux，切换入口（对应为entrypoint权限）为执行apache_exec_t类型 的文件 allow apache_t apache_exec_t : file entrypoint; (4).最后，Domain Transition type_transition init_t apache_exec_t : process apache_t;

可以看到，整个domain切换过程写起来非常麻烦。因此，Google 为了使用方便, 在system/sepolicy/public/te_macros 文件中定义了宏：

我们可以使用这些宏来完成domain切换。

举例： kernel启动init进程切换domain: domain_auto_trans(kernel, init_exec, init) init启动netd、vold、zygote、installd切换domain: init_daemon_domain(netd) init_daemon_domain(vold) init_daemon_domain(zygote) init_daemon_domain(installd)

一个进程创建在一个目录下创建文件时, 默认是沿用父目录的Security Context, 如果要设置成特定的Label, 就必须进行Object Transitions. 同样是使用：type_transition statement. 对应的必须有两个前提条件:

下面是一个demo, ext_gateway_t 这个domain 在类型为in_queue_t 的目录下，创建类型为 in_file_t 的文件.

(1). 首先，你得让ext_gateway_t 对in_queue_t 目录具备访问权限 allow ext_gateway_t in_queue_t : dir { write search add_name }; (2). 然后，你还得告诉SELinux，允许ext_gateway_t访问in_file_t的文件 allow ext_gateway_t in_file_t : file { write create getattr }; (3).最后，Object Transition type_transition ext_gateway_t in_queue_t : file in_file_t;

同样的，为了方便使用，Google 也在system/sepolicy/public/te_macros 文件中定义了宏:

使用举例： file_type_auto_trans(factory, system_data_file, factory_data_file)

android O 以前sepolicy 集中放在boot image 。前面提到SELinux在Android的主要变更历史时，有提到android O 开始，Google将system image 和 vendor image 分离。因此，sepolicy 也相应的被分离存放到system image 以及 vendor image。与system 相关的sepolicy 就存放system image, 与SoC vendor 相关的sepolicy 就存放在vendor image。

对于原生AOSP，Google 设定了不同的存放目录, 以便进行分离, 以Google 默认的sepolicy 为例，sepolicy主目录为 /system/sepolicy，我们主要关注三个子目录：

对于不同的平台，不同平台厂商也设定了不同的存放目录，以MTK平台为例： 首先，根据不同的platform共用sepolicy、platform独有、project独有，分为：

对应的，不同版本会导入不同目录下的sepolicy配置

以mt6763平台为例，导入时： [common] 路径为：/device/mediatek/sepolicy [platfrom] 路径为：/device/mediatek/mt6763/sepolicy/ 具体的定义在文件中:

然后，basic、bsp、full又可以主要细分为：

Google 在system/sepolicy 中定义了相关的neverallow 规则, 对SELinux Policy 的更新进行了限制, 以防止开发者过度开放权限，从而引发安全问题。并且还会通过CTS测试检测开发者是否有违法相关的规则。

因此，我们需要注意以下几点：

出现SELinux Policy Exception时常见的两种解决方案：

(1). 修改对应节点的SELinux Security Label, 为特定的Subject，如system_app、platform_app、priv_app，例如Settings，SystemUI等内置APP开启权限, 但严禁为untrsted app 开启权限。 (2). 通过system server service 或者 init 启动的service 读写操作, 然后app 通过binder/socket 等方式连接访问. 此类安全可靠, 并且可以在service 中做相关的安全审查, 推荐这种方法.

情景:定义由 init 进程启动的service, factory, 其对应的执行档是 /vendor/bin/factory。

(1).在device/mediatek/mt6763/sepolicy/basic/non_plat 目录下创建一个 , 然后将te文件加入编译，如放到这种指定目录下不需要额外配置，sytem/sepolicy/中定义的build_policy函数会遍历指定目录导入te文件。

(2).在 中定义factory类型，init 启动service 时类型转换, type factory, domain; type factory_exec, exec_type, file_type, vendor_file_type; init_daemon_domain(factory)

(3).在file_contexts中绑定执行档 /(system/vendor|vendor)/bin/factory u:object_r:factory_exec:s0

(4).根据factory需要访问的文件以及设备,定义其它的权限在 中. #Purpose: For key and touch event allow factory input_device:chr_file r_file_perms; allow factory input_device:dir rw_dir_perms;

情景:添加一个自定义的system property： ，并为platform_app设置读写权限

(1).在中定义system property类型 type demo_prop, property_type

(2).在property_contexts中绑定system property的安全上下文。  u:object_r:demo_prop:s0

(3). 在platform_ 中新增写权限，可以使用set_prop宏。 set_prop(platform_app, demo_prop)

(4). 在platform_ 中新增读权限，可以get_prop 宏。 get_prop(platform_app, demo_prop)

情景:有一个设备节点/dev/demo，有一个platform_app进程需要读写这个设备节点。

(1). 在中定义device 类型 type demo_device dev_type;

(2). 在 file_contexts中绑定demo_device /dev/demo u:object_r:demo_device:s0

(3). 在platform_中，允许platform_app使用demo device 的权限 allow platform_app demo_device:chr_file rw_file_perms;

情景:有一个扩展的系统服务demo_service供APP调用。

(1). 在 中定义service 类型 type demo_service, app_api_service, system_server_service, service_manager_type;

(2).在service_contexts 中绑定service demou:object_r:demo_service:s0

(3).在frameworks/base/core/java/android/content/中定义服务常量 public static final String DEMO_SERVICE = demo;

(4).在frameworks/base/core/java/android/app/中，参照其它系统服务注册demo_service

(5).在frameworks/base/services/java/com/android/server/中，启动DemoService，添加到service_manager进行管理。

(6).最后一步，参考其它系统服务，实现DemoManager、DemoService，并定义如IDemoService等等的AIDL接口。

情景:一个native service 通过init 创建一个socket 并绑定在 /dev/socket/demo, 并且允许某些process 访问.

(1). 在中定义socket 的类型 type demo_socket, file_type;

(2). 在file_contexts中绑定socket 的类型 /dev/socket/demo_socket u:object_r:demo_socket:s0

(3). 允许所有的process 访问，使用宏unix_socket_connect(clientdomain, socket, serverdomain) unix_socket_connect(appdomain, demo, demo)

(1).在device/mediatek/mt6763/sepolicy/basic/non_plat目录下创建一个。

(2).在 中定义demo 类型，init 启动service 时类型转换。并可以根据demo 需要访问的文件以及设备,定义其它的权限在 中。 typedemo, domain; type demo_exec, exec_type, file_type; init_daemon_domain(demo)

(3).绑定执行档 file_context 类型 /vendor/bin/demou:object_r:demo_exec:s0

(4). 创建demo的入口执行档demo_exec、并配置相应的权限。

(1). 将SELinux 调整到Permissive 模式复测 使用eng/userdebug 版本，adb shell setenforce 0 将SELinux 模式调整到Permissive 模式，然后复测。如果还能复现问题，则与SELinux 无关； 如果原本很容易复现, 而Permissive mode 不能再复现, 那么就可能与SELinux相关。

(2). 查看LOG 中是否有标准的SELinux Policy Exception. 在Kernel LOG / Main Log 中查询关键字 avc: denied 看看是否有与目标进程相关的SELinux Policy Exception, 并进一步确认这个异常是否与当时的逻辑相关。

一般情况我们在符合Google sepolicy策略及neverallow策略的前提下，根据LOG中的内容，需要什么权限就加什么权限。例如LOG： 2020-03-27 14:11:02.596 1228-1228/ W/FaceIdThread: type=1400 audit(0.0:481): avc: denied { read } for dev=tmpfs ino= scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device:s0 tclass=chr_file permissive=0

LOG说明如下：

一般我们需要重点关注的是四个：permission、source type、target type、target class

根据这四个就可以配置出的所需要的selinux权限：  allow [source type] [target type]: [target class] [permission] 例1： 03-27 03:45:22.632 2958 2958 W Camera: type=1400 audit(0.0:314): avc: denied { read } for dev=tmpfs ino=2649 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:graphics_debug_prop:s0 tclass=file permissive=0

解决方案： 按正常的套公式，应该是这样修改platform_，增加： allow platform_app graphics_debug_prop:file r_file_perms; 这里我们利用system/sepolicy/te_macros中定义的宏get_prop：

更多相关的宏定义请参考：system/sepolicy/public/te_macros。 所以最终简化后，修改platform_，增加： get_prop(platform_app, graphics_debug_prop)

例2： 03-27 14:11:02.596 1228-1228/ W/BackThread: type=1400 audit(0.0:481): avc: denied { read } for dev=tmpfs ino= scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device:s0 tclass=chr_file permissive=0

解决方案： 修改platform_增加： allow platform_app als_ps_device:chr_file r_file_perms;

(1). 不符合neverallow规则或者修改了neverallow规则 编译报错： neverallow check failed at xxx CTS测试项failed： #testNeverallowRulesXXX 这类问题在android O vendor和system分离之后，尤其容易出现。基本上这类问题都是因为修改或者增加的te配置不符合neverallow规则，导致编译报错。而为了解决编译报错，又修改了neverallow规则，最终在跑CTS时，没法通过相关的测试项。

解决思路：

(2). init进程fork新进程没有做domain切换 CTS测试项failed：  # testInitDomain

解决思路： fork进程时，参考3.4节中做domain切换。

本文主要参考了MTK-Online的Quick-start中《SELinux 问题快速分析》的内容，感谢原作者们的辛勤付出。另外，结合源码和自身开发实践，增加了一些自身理解和实践内容。

如何解决SELinux阻止虚拟机访问文件

几乎可以肯定每个人都听说过 SELinux (更准确的说，尝试关闭过)，甚至某些过往的经验让您对 SELinux 产生了偏见。 不过随着日益增长的 0-day 安全漏洞，或许现在是时候去了解下这个在 Linux 内核中已经有8年历史的强制性访问控制系统(MAC)了。 SELinux 与强制访问控制系统SELinux 全称 Security Enhanced Linux (安全强化 Linux)，是 MAC (Mandatory Access Control，强制访问控制系统)的一个实现，目的在于明确的指明某个进程可以访问哪些资源(文件、网络端口等)。 强制访问控制系统的用途在于增强系统抵御 0-Day 攻击(利用尚未公开的漏洞实现的攻击行为)的能力。 所以它不是网络防火墙或 ACL 的替代品，在用途上也不重复。 举例来说，系统上的 Apache 被发现存在一个漏洞，使得某远程用户可以访问系统上的敏感文件(比如 /etc/passwd 来获得系统已存在用户)，而修复该安全漏洞的 Apache 更新补丁尚未释出。 此时 SELinux 可以起到弥补该漏洞的缓和方案。 因为 /etc/passwd 不具有 Apache 的访问标签，所以 Apache 对于 /etc/passwd 的访问会被 SELinux 阻止。 相比其他强制性访问控制系统，SELinux 有如下优势：●控制策略是可查询而非程序不可见的。 ●可以热更改策略而无需重启或者停止服务。 ●可以从进程初始化、继承和程序执行三个方面通过策略进行控制。 ●控制范围覆盖文件系统、目录、文件、文件启动描述符、端口、消息接口和网络接口。 那么 SELinux 对于系统性能有什么样的影响呢?根据 Phoronix 在 2009 年使用 Fedora 11 所做的横向比较来看，开启 SELinux 仅在少数情况下导致系统性能约 5% 的降低。 SELinux 是不是会十分影响一般桌面应用及程序开发呢?原先是，因为 SELinux 的策略主要针对服务器环境。 但随着 SELinux 8年来的广泛应用，目前 SELinux 策略在一般桌面及程序开发环境下依然可以同时满足安全性及便利性的要求。 以刚刚发布的 Fedora 15 为例，笔者在搭建完整的娱乐(包含多款第三方原生 Linux 游戏及 Wine 游戏)及开发环境(Android SDK + Eclipse)过程中，只有 Wine 程序的首次运行时受到 SELinux 默认策略的阻拦，在图形化的“SELinux 故障排除程序”帮助下，点击一下按钮就解决了。 了解和配置 SELinux1. 获取当前 SELinux 运行状态getenforce可能返回结果有三种：Enforcing、Permissive 和 Disabled。 Disabled 代表 SELinux 被禁用，Permissive 代表仅记录安全警告但不阻止可疑行为，Enforcing 代表记录警告且阻止可疑行为。 目前常见发行版中，RHEL 和 Fedora 默认设置为 Enforcing，其余的如 openSUSE 等为 Permissive。 2. 改变 SELinux 运行状态setenforce [ Enforcing | Permissive | 1 | 0 ]该命令可以立刻改变 SELinux 运行状态，在 Enforcing 和 Permissive 之间切换，结果保持至关机。 一个典型的用途是看看到底是不是 SELinux 导致某个服务或者程序无法运行。 若是在 setenforce 0 之后服务或者程序依然无法运行，那么就可以肯定不是 SELinux 导致的。 若是想要永久变更系统 SELinux 运行环境，可以通过更改配置文件 /etc/sysconfig/selinux 实现。 注意当从 Disabled 切换到 Permissive 或者 Enforcing 模式后需要重启计算机并为整个文件系统重新创建安全标签(touch / && reboot)。 3. SELinux 运行策略配置文件 /etc/sysconfig/selinux 还包含了 SELinux 运行策略的信息，通过改变变量 SELINUXTYPE 的值实现，该值有两种可能：targeted 代表仅针对预制的几种网络服务和访问请求使用 SELinux 保护，strict 代表所有网络服务和访问请求都要经过 SELinux。 RHEL 和 Fedora 默认设置为 targeted，包含了对几乎所有常见网络服务的 SELinux 策略配置，已经默认安装并且可以无需修改直接使用。 若是想自己编辑 SELinux 策略，也提供了命令行下的策略编辑器 seedit 以及 Eclipse 下的编辑插件 eclipse-slide 。 4. coreutils 工具的 SELinux 模式常见的属于 coreutils 的工具如 ps、ls 等等，可以通过增加 Z 选项的方式获知 SELinux 方面的信息。