Android ： SELinux 简析&修改

一 SELinux背景知识

SELinux出现之前，Linux上的安全模型叫DAC，全称是Discretionary Access Control，翻译为自主访问控制。DAC的核心思想很简单，就是：

• 进程理论上所拥有的权限与执行它的用户的权限相同。比如，以root用户启动Browser，那么Browser就有root用户的权限，在Linux系统上能干任何事情。

显然，DAC太过宽松了，所以各路高手想方设法都要在Android系统上搞到root权限。那么SELinux如何解决这个问题呢？原来，它在DAC之外，设计了一个新的安全模型，叫MAC（Mandatory Access Control），翻译为强制访问控制。MAC的处世哲学非常简单：即任何进程想在SELinux系统中干任何事情，都必须先在安全策略配置文件中赋予权限。凡是没有出现在安全策略配置文件中的权限，进程就没有该权限。来看一个SEAndroid中设置权限的例子：

allow

如果没有在netd.te中使用上例中的权限配置allow语句，则netd就无法往/proc目录下得任何文件中写数据，即使netd具有root权限。

这条语句的语法为：

• allow：TE的allow语句，表示授权。除了allow之外，还有allowaudit、dontaudit、neverallow等。
• netd：source type。也叫subject，domain。
• proc：target type。它代表其后的file所对应的Type。
• file：代表Object Class。它代表能够给subject操作的一类东西。例如File、Dir、socket等。在Android系统中，有一个其他Linux系统没有的Object Class，那就是Binder。
• write：在该类Object Class中所定义的操作。

根据SELinux规范，完整的allow相关的语句格式为：rule_name source_type target_type : class perm_set

 

SELinux中，每种东西都会被赋予一个安全属性，官方说法叫Security Context。Security Context（以后用SContext表示）是一个字符串，主要由三部分组成。例如SEAndroid中，进程的SContext可通过ps -Z命令查看，如图1所示：

以第一个进程/init的SContext为例，其值为u:r:init:s0，其中：

• u为user的意思。SEAndroid中定义了一个SELinux用户，值为u。
• r为role的意思。role是角色之意，它是SELinux中一种比较高层次，更方便的权限管理思路，即Role Based Access Control（基于角色的访问控制，简称为RBAC）。简单点说，一个u可以属于多个role，不同的role具有不同的权限。RBAC我们到最后再讨论。
• init，代表该进程所属的Domain为init。MAC的基础管理思路其实不是针对上面的RBAC，而是所谓的Type Enforcement Accesc Control（简称TEAC，一般用TE表示）。对进程来说，Type就是Domain。比如init这个Domain有什么权限，都需要通过[例子1]中allow语句来说明。
• S0和SELinux为了满足军用和教育行业而设计的Multi-Level Security（MLS）机制有关。简单点说，MLS将系统的进程和文件进行了分级，不同级别的资源需要对应级别的进程才能访问

再来看文件的SContext，读者可通过ls -Z来查看，如图2所示：

以第一行acct目录为例，其信息为u:object_r:cgroup:s0 ：

• u：同样是user之意，它代表创建这个文件的SELinux user。
• object_r：文件是死的东西，它没法扮演角色，所以在SELinux中，死的东西都用object_r来表示它的role。
• cgroup：死的东西的Type，和进程的Domain其实是一个意思。它表示acct目录对应的Type是cgroup。
• s0：MLS的级别。

根据SELinux规范，完整的SContext字符串为：

user:role:type[:range]

注意，方括号中的内容表示可选项。s0属于range中的一部分,MAC基本管理单位是TEAC（Type Enforcement Accesc Control），然后是高一级别的Role Based Accesc Control。RBAC是基于TE的，而TE也是SELinux中最主要的部分。

 

三、Security Labeling：

Android系统启动后（其他Linux发行版类似），init进程会将一个编译完的安全策略文件传递给kernel以初始化kernel中的SELinux相关模块（姑且用Linux Security Module:LSM来表示它把），然后LSM可根据其中的信息给相关Object打标签。

LSM初始化时所需要的信息以及SContext信息保存在两个特殊的文件中，以Android为例，它们分别是：

• initial_sids：定义了LSM初始化时相关的信息。SID是SELinux中一个概念，全称是Security Identifier。SID其实类似SContext的key值。因为在实际运行时，如果老是去比较字符串（还记得吗，SContext是字符串）会严重影响效率。所以SELinux会用SID来匹配某个SContext。
• initial_sid_context：为这些SID设置最初的SContext信息。

 

四、SEAndroid源码分析

　　本节主要看Google是如何在Android平台定制SELinux的。如前文所示，Android平台中的SELinux叫SEAndroid。

Android平台中：（注：Android7.0开始目录为 system/sepolicy/）

• external/sepolicy：提供了Android平台中的安全策略源文件。同时，该目录下的tools还提供了诸如m4,checkpolicy等编译安全策略文件的工具。注意，这些工具运行于主机（即不是提供给Android系统使用的）
• external/libselinux：提供了Android平台中的libselinux，供Android系统使用。
• external/libsepol：提供了供安全策略文件编译时使用的一个工具checkcon。

对我们而言，最重要的还是external/sepolicy。通过如下make命令查看执行情况： mmm external/sepolicy  --just-print

• sepolicy的重头工作是编译sepolicy安全策略文件。这个文件来源于众多的te文件，初始化相关的文件（initial_sid,initial_sid_context,users,roles,fs_context等）。
• file_context：该文件记载了不同目录的初始化SContext，所以它和死货打标签有关。
• seapp_context：和Android中的应用程序打标签有关。
• property_contexts：和Android系统中的属性服务（property_service）有关，它为各种不同的属性打标签。
  
  

----------【例子1】：通过修改shell的权限，使其无法设置属性：

先来看shell的te，如下所示：

[external/sepolicy/shell.te]

unconfied_domain是一个宏，它将shell和如下两个attribute相关联：

[external/sepolicy/te_macros]

unconfineddomain权限很多，它的allow语句定义在unconfined.te中：

[external/sepolicy/unconfined.te]

从上面可以看出，shell所关联的unconfineddomain有权限设置属性。所以，我们把它改成：

通过一个“-”号，将shell的权限排除。

然后：

• 我们mmm external/sepolicy，得到sepolicy文件。
• 将其push到/data/security/current/sepolicy目录下
• 接着调用setprop selinux.reload_policy 1，使得init重新加载sepolicy，由于/data目录下有了sepolicy，所以它将使用这个新的。

图示为整个测试的例子：

• 重新加载sepolicy之前，笔者可通过"setprop wlan.driver.status test_ok"设置该属性的值为test_ok。
• 当通过 setprop selinux.reload_policy 1 的命令后，init重新加载了sepolicy。
• 笔者setprop wlan.driver.status

图示为dmesg输出，可以看出，当selinux使用了data目录下这个新的sepolicy后，shell的setprop权限就被否了！

提示：前面曾提到过audit，日志一类的事情。日志由kernel输出，可借助诸如audit2allow等host上的工具查看哪些地方有违反权限的地方。

 

----------【例子2】：Nerverallow 实例分析：

　　项目中想要添加与 audio 相关的功能，添加完后，编译版本，在关闭 selinux 的情况下，功能正常，打开 selinux 即有问题，且
在 log 中有 selinux 相关的 log，所以判断此问题为 selinux 问题，根据关闭 selinux 的 log 我们解析出两句 allow 语句：
allow hal_audio_default default_prop:property_service set;
allow audioserver default_prop:property_service set;

　　根据上文生成的.te 语句，我们在代码中创建对应的.te 文件（没有则创建），编译代码，发现代码编译不过，log 如下：

　　libsepol.report_failure: neverallow on line 447 of system/sepolicy/public/domain.te (or line 8935 of policy.conf) violated by allow hal_audio_default default_prop:property_service { set };
libsepol.report_failure: neverallow on line 447 of system/sepolicy/public/domain.te (or line 8935 of policy.conf) violated by allow audioserver default_prop:property_service { set }; libsepol.check_assertions: 2 neverallow failures occurred

　　分析可知：我 们 添 加 的 代 码 与system/sepolicy/public/domain.te 中的如下代码有冲突：
　　　　Nerverallow { domain -init } default_prop:property_service set;

　　我们来对比一下：
　　allow hal_audio_default default_prop:property_service set;
　　allow audioserver default_prop:property_service set;
　　结果很显然，是因为我们的主体对 default_prop 这个 type 进行了 set 操作，所以我们需要绕过去。

　　因为 default_prop 是一个很宏观的概念，所以我们需要查清我们的主体到底是对什么属性进行了 set 操作，所以需要查代码，看代码中具体做了什么操作，代码如下：

　　property_set("pmc.audio.spkoff_w_bths_status", "true");

　　property_set("pmc.audio.spkoff_w_bths_status", "false");

　　由此便得知，我们的主体是对 pmc.audio.这个属性进行了 set操作，所以我们需要给 pmc.audio.重新打一个标记，给属性打标记需要在 property_contexts 中添加，代码如下：

　　pmc.audio. u:object_r:audio_prop:s0

　　属性是比较特殊的我们可以直接通过 set_prop 来添加权限，代码如下:

　　set_prop(audioserver, audio_prop)；

　　set_prop(hal_audio_default, audio_prop)；

 

 

五、修改方法简结：

1.1 提取所有的avc LOG. 如 adb shell “cat /proc/kmsg | grep avc” > avc_log.txt

注意audit2allow 它自动机械的帮您将LOG 转换成policy, 而无法知道你操作的真实意图，有可能出现权限放大问题，经常出现policy 无法编译通过的情况。

此方法需要工程人员对SELinux 基本原理，以及SELinux Policy Language 有了解.

然后添加新的policy：

如果直接按照avc: denied 的LOG 转换出SELinux Policy, 往往会产生权限放大问题. 比如因为要访问某个device, 在这个device 没有细化SELinux Label 的情况下, 可能出现:

如果直接按照此LOG 转换出SELinux Policy: allow mediaserver device:chr_file {read write}; 那么就会放开mediaserver 读写所有device 的权限. 而Google 为了防止这样的情况, 使用了neverallow 语句来约束, 这样你编译sepolicy 时就无法编译通过.

3.2 绑定文件与SELinux type.

3.3 添加对应process/domain 的访问权限.

那么哪些访问对象通常会遇到此类呢？(以L 版本为例)

• File 类型:

• 虚拟File 类型:

• Service 类型:

• Property 类型:

• 通常我们强烈反对更新google default 的policy, 大家可以更新device目录下对应OEM厂商的policy.

 

 

六、新版本遇到的问题

　1.Android 8.1 以上，非系统进程设置系统域属性问题:

　　权限异常的log:

　　查找代码源头是设置了如下属性：property_set("persist.audio.debug.search", "");

　　但是Android 8.1 及以上版本系统添加了权限限制，不允许普通进程设置系统属性，所以按照之前的方法添加会遇到如下编译错误:

解决方案 1:

允许 hal_audio_default 进程设置 persist.audio.debug.xxx属性

（1）property_contexts 添加：

（2）hal_audio_default.te 添加：

（3） 添加：

解决方案 2:

非系统域的属性设置则没有如上限制，可以将 audio 属性修改为vender 域的属性如: persist.vendor.audio.

 

　2.Android9.0为系统服务添加SELinux权限：

　　从Android 4.4到Android 7.0的SELinux策略构建方式合并了所有sepolicy片段(平台和非平台)，然后在根目录生成单一文件，而Android 8.0开始关于selinux架构也类似于HIDL想把系统平台的selinux策略和厂商自己维护的策略剥离开来, 允许合作伙伴单独自己的策略，构建他们的镜像(.img)引导，这样便可以独立于平台更新这些.img，反之亦然(即：在不更新合作伙伴镜像的情况下执行平台更新)。

　　关于8.0 selinux架构介绍官方文档（SELinux_Treble.pdf）: https://pan.baidu.com/s/161_OpZRqx7PvOmcQ4G-CwA

  1、例如：xxx service权限异常有如下log：

　　则需要对selinux进行权限配置：（参考公式：allow SourceContext TargetContext:TargetClass Permission）

　　allow system_server default_android_service:service_manager { add };

  2、以下部分是对selinux权限进行定义（实际需根据SDK的版本修改对应目录）：

（1）https://www.cnblogs.com/blogs-of-lxl/p/system/sepolicy/prebuilts/api/26.0/nonplat_sepolicy.cil

（2）https://www.cnblogs.com/blogs-of-lxl/p/system/sepolicy/prebuilts/api/27.0/nonplat_sepolicy.cil

（3）https://www.cnblogs.com/blogs-of-lxl/p/system/sepolicy/prebuilts/api/28.0/private/compat/26.0/26.0.cil

（4）https://www.cnblogs.com/blogs-of-lxl/p/system/sepolicy/prebuilts/api/28.0/private/compat/27.0/27.0.cil

（5）https://www.cnblogs.com/blogs-of-lxl/p/system/sepolicy/prebuilts/api/28.0/private/service_contexts

（6）https://www.cnblogs.com/blogs-of-lxl/p/system/sepolicy/prebuilts/api/28.0/public/service.te

（7）https://www.cnblogs.com/blogs-of-lxl/p/system/sepolicy/private/compat/26.0/26.0.cil

（8）https://www.cnblogs.com/blogs-of-lxl/p/system/sepolicy/private/compat/27.0/27.0.cil

（9）https://www.cnblogs.com/blogs-of-lxl/p/system/sepolicy/private/service_contexts

（10）https://www.cnblogs.com/blogs-of-lxl/p/system/sepolicy/public/service.te

 

  3、使用修改selinux权限的系统服务：