[ Android实战 ] selinux 策略修改不生效的问题解决

尊重原创，转载请注明出处！
创作不易，如有帮助请点赞支持~

背景

前段时间移植系统应用到新平台的时候，发现存在一个selinux的问题。按照平时的方式加了对应的selinux策略后，依然会报同样的selinux权限错误。因此借此机会研究了一下selinux的问题，写下了此篇博客。

问题处理

我要移植的系统应用，主要是作为蓝牙通讯的服务端，客户端是通过 BluetoothSocket 的形式与其建立蓝牙连接。但是在Android10 上，报了 selinux 权限的错误。具体报错信息如下：

type=1400 audit(0.0:275): avc: denied { connectto } for path=0042545F5072696E746572 scontext=u:r:untrusted_app_25:s0:c512,c768 
tcontext=u:r:system_app:s0 tclass=unix_stream_socket permissive=0 app=com.bluetooth.demo

这里顺便说一下定位和解决 selinux 报错的一般思路，很多人可能已经很熟悉了，但是有一些人可能不知道。

开发调试阶段，如果某个应用在其他平台功能正常，而在新平台却不正常，可以用以下方法快速定位是否 selinux 问题：

Android 系统启动后，先执行 adb shell setenforce 0 暂时关闭 selinux，再测试相关功能。如果此时功能正常，基本确定是 selinux 权限导致的问题。

接下来就是抓 logcat，过滤 avc 关键字，即可找到缺少的 selinux 权限，然后就是评估是否需要添加对应的 selinux 权限了。

简单的 selinux 策略添加，也有一个万能公式。比如我上面的那个报错，可以套用公式：

	scontext	tcontext:	tclass	avc denied的权限
allow	untrusted_app_25	system_app:	unix_stream_socket	connectto

即在 untrusted_app_25.te 中添加策略：allow untrusted_app_25 system_app:unix_stream_socket { connectto };

So easy！ 修改完执行 make selinux_policy 编译，编译完成后更新相应的 selinux 文件：

adb push out\target\product\xxx\vendor\etc\selinux /vendor/etc/
adb push out\target\product\xxx\system\etc\selinux /system/etc/

注意：按照上述方式直接更新 selinux 相关文件在某些平台可能不生效，那就编译 vendor 或 system 镜像烧录即可。

重启机器后进行测试，fine，还是报同样的错误。。。

添加了 selinux 策略却不生效？百度了一圈，总算找到一个类似的问题：SELinux 添加一个权限

搜索了一下代码，发现果然在 system/sepolicy/private/mls 中做了限制：

# Stream connect:  Client must be equivalent to server unless one of them
# is trusted.
mlsconstrain unix_stream_socket { connectto }
             (l1 eq l2 or t1 == mlstrustedsubject or t2 == mlstrustedsubject);

从 mls 可以看出，必须满足以上 3 个条件之一才能授予 unix_stream_socket 的 connectto 权限：

1、根据 avc 报错，l1=s0:c512,c768，l2=s0，因此 l1 和 l2 不相等，l1 eq l2 不成立

2、t1 为 untrusted_app_25，根据 system/sepolicy/public/untrusted_app.te 的定义，不属于 mlstrustedsubject

3、t2 为 system_app，根据 system/sepolicy/public/system_app.te 的定义，同样不属于 mlstrustedsubject

3 个条件都不满足，难怪加了对应的 selinux 策略后不生效，依然报错！

看懂了问题发生的原因，解决这个问题也就简单了。参考公司其他平台的做法，修改 system/sepolicy/public/system_app.te ，将 system_app 设置为 mlstrustedsubject，最终问题得到了解决~

-type system_app, domain;
+type system_app, domain, mlstrustedsubject;

总结

问题解决了，还是得总结一下，当添加某些 allow 策略后，如果发现不起作用，可能是 MLS 作祟，限制了访问。这时可以查看一下 MLS 策略文件： system/sepolicy/private/mls，看看是否对自己所添加的权限进行了限制，再进行相应的处理。

此外，一些 selinux 相关基本的概念还是有必要知道的：

MLS：即 Multi-Level Security，在 selinux 的基础上加了不同安全等级的限制。

u1，u2：分别表示 source 和 target 的 user。

r1，r2：分别表示 source 和 target 的 role。比如 object_r

t1，t2：分别表示 source 和 target 的 type，即对象的类型。比如 system_app，untrusted_app 等

l1，l2：分别表示 source 和 target 的 level，即 selinux 等级，由 sensitive 和 category 组成。比如 s0:c512,c768，s0 表示 sensitive，c512,c768 表示 category。

参考文章

SEAndroid的MLS相关知识以及配置方法
SELinux 添加一个权限