android 11添加property遇到的selinux问题

android 11 项目中添加新的property启动sh脚本，遇到如下几个问题。

问题1 ：coredomaim编译报错

The following domain(s) must be associated with the "coredomain" attribute because they are executed off of /system:
addnewservice

此处log 提示 addnewservice必须是coredomain类型的，为此我们在system/seploicy/public/addnewservice.te中添加修改

-type addnewservice, domain, mlstrustedsubject;
+type addnewservice, domain, coredomain, mlstrustedsubject;

之后重新编译报如下错误

The following domain(s) must be associated with the "coredomain" attribute because they are executed off of /system:
addnewservice

此时log显示addnewservice却又不能被设置为coredomain。
这就叫人很纠结了。不添加coredomain，编译报错必须是coredomain，添加coredomain之后编译又提示禁止被设置成coredomain。
分析log可知android 11 在system/bin/目录下执行的sh脚本必须是coredomain，如果不想设置成coredomain可以将sh脚本放到vendor/bin/目录下,这样就不会遇到coredomain问题，但是这种方式有时候会遇到一些必须修改到system/sepolicy目录下权限才能执行的，这样就必须将sh脚本放置到system/bin/目录下。
sh脚本必须防止在system/bin/目录下，修改方案如下所示：

/system/sepolicy/private/file_contexts

+/system/bin/new.sh u:object_r:addnew_exec:s0

/system/sepolicy/public/目录下添加addnew.te 文件

type addnew, domain;
type addnew_exec, exec_type, file_type, system_file_type;
allow addnew shell_exec:file { read getattr};
...

/system/sepolicy/private/目录下添加addnew.te 文件

typeattribute addnew coredomain;
init_daemon_domain(addnew)
...

问题2 ：xxx.ignore.cil使用

添加新的te文件，必须在prebuilt目录下将之前所有的文件夹中添加te，但是不同版本有些typeattribute没有会导致编译报错，如果我们不想在prebuilt/目录下都添加addnew.te文件，只需要在29.0文件中添加如下修改，则29.0之前版本28.0，27.0，26.0中就不再需要添加addnew和addnew_exec相关的修改。

--- a/system/sepolicy/private/compat/29.0/29.0.ignore.cil
+++ b/system/sepolicy/private/compat/29.0/29.0.ignore.cil
@@ -72,6 +72,8 @@
     iorap_prefetcherd_data_file
+    addnew
+    addnew_exec

问题3： dac_override 权限如何添加（neverallow权限如何添加）

dac_override 是一种典型的neverallow权限，要添加dac_override权限必须是coredomain才能添加，如果不是coredomain是没有办法添加这种neverallow权限的，也就是说在device/qcom/sepolicy/目录下添加的文件是不可能有dac_override权限的，如何添加coredomain修改如问题1所示
添加dac_override修改如下所示：

--- a/system/sepolicy/private/domain.te
+++ b/system/sepolicy/private/domain.te
@@ -311,8 +311,9 @@ define(`dac_override_allowed', `{
   vold
   vold_prepare_subdirs
   zygote
+  addnew
 }')
-neverallow ~dac_override_allowed self:global_capability_class_set dac_override;
+neverallow ~{ dac_override_allowed addnew} self:global_capability_class_set dac_override;
 # Since the kernel checks dac_read_search before dac_override, domains that
 # have dac_override should also have dac_read_search to eliminate spurious
 # denials.  Some domains have dac_read_search without having dac_override, so
@@ -323,6 +324,7 @@ neverallow ~{
   iorap_prefetcherd
   traced_perf
   traced_probes
+  addnew
   userdebug_or_eng(`heapprofd')
 } self:global_capability_class_set dac_read_search;

--- a/system/sepolicy/private/file_contexts
+++ b/system/sepolicy/private/file_contexts
@@ -301,6 +301,7 @@
 /system/bin/iorapd          u:object_r:iorapd_exec:s0
+/system/bin/new.sh u:object_r:addnew_exec:s0
 /system/bin/iorap\.inode2filename u:object_r:iorap_inode2filename_exec:s0

注意这边添加dac_override修改不确定是否会导致CTS测试fail，目前没有CTS测试需求，所以没有测试过，如果CTS测试fail则需要看看是否有其他方式绕开。

说明：

1)untrusted_app 第三方app，没有Android平台签名，没有system权限
2)platform_app 有android平台签名，没有system权限
3)system_app 有android平台签名和system权限
从上面划分，权限等级，理论上：untrusted_app < platform_app < system_app

问题4：selinux security level引起的denied u:r:untrusted_app:s0:c512,c768问题

最近selinux遇到问题：avc: denied { sigkill } for pid=12755 comm="sh" scontext=u:r:AAAA:s0 tcontext=u:r:untrusted_app:s0:c512,c768 tclass=process permissive=0

发现即使加了 allow AAAA untrusted_app:process sigkill;的规则也不行。

后来发现是security level专为MLS访问机制所添加的安全上下文的扩展部分mlstrustedsubject 捣的鬼。

需要加上type AAAA, domain,mlstrustedsubject;问题就解决了。

关于mlstrustedsubject 具体参考博客：http://blog.youkuaiyun.com/l173864930/article/details/17194899

问题5：Android R selinux 解决实例

问题如下，新增一个 设备 /dev/video7， 在 应用访问时 log 中 报出 avc: denied， 是 selinux 问题， 初始的 log 如下：

06-17 20:23:09.244 19650 19650 I pool-4-thread-1: type=1400 audit(0.0:530): avc: denied { read } for name="video7" dev="tmpfs" ino=224395 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:video_device:s0 tclass=chr_file permissive=1
06-17 20:23:09.244 19650 19650 I pool-4-thread-1: type=1400 audit(0.0:532): avc: denied { ioctl } for path="/dev/video7" dev="tmpfs" ino=224395 ioctlcmd=5600 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:video_device:s0 tclass=chr_file permissive=1

解决方法：

scontext=u:r:untrusted_app_25:s0:c512,c768

tcontext=u:object_r:video_device:s0

tclass=chr_file

根据这个信息，一般的做法是 在 untrusted_app_25.te 中增加  allow untrusted_app_25 video_device:chr_file { read ioctl }; 现在 android 也自带了一个 命令 audio2allow -i error.txt （把avc: denied 的log 拷贝出来存成 error.txt）,就可以生成需要增加的语句。但是这样修改后发现， 编译时包 neverallow， 是因为 video_device 是已经定义过的设备， 修改已经定义的设备的权限就可能包 neverallow。

libsepol.report_failure: neverallow on line 384 of system/sepolicy/public/app.te (or line 8744 of policy.conf) violated by allow untrusted_app_25 video_device:chr_file { read };
libsepol.check_assertions: 1 neverallow failures occurred

那么，我们怎么修改呢， 可以单独定义一个设备，在 file_contexts 中定义

/dev/video7    u:object_r:video_usb_device:s0

在 device.te 中定义类型(dev_type 类型的貌似需要以 device 结尾，一开始我定义的 video_device_usb, 编译报错)：

type video_usb_device, dev_type;

然后在 untrusted_app_25.te 中 增加：

allow untrusted_app_25 video_usb_device:chr_file rw_file_perms;

理论上 加了 rw_file_perms，这个权限，已经包含了 读 写的 全部权限， 但是 实际情况是 还是 有 avc: denied

06-18 11:48:14.459 8709 8709 W com.cloudminds.roboticservice: type=1400 audit(0.0:286): avc: denied { write } for comm=43616D657261205375726661636554 name="video7" dev="tmpfs" ino=88535 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:video_usb_device:s0 tclass=chr_file permissive=0
06-18 11:48:14.979 8709 8709 W com.cloudminds.roboticservice: type=1400 audit(0.0:288): avc: denied { write } for comm=43616D657261205375726661636554 name="video7" dev="tmpfs" ino=88535 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:video_usb_device:s0 tclass=chr_file permissive=0
06-18 11:48:15.489 8709 8709 W com.cloudminds.roboticservice: type=1400 audit(0.0:289): avc: denied { write } for comm=43616D657261205375726661636554 name="video7" dev="tmpfs" ino=88535 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:video_usb_device:s0 tclass=chr_file permissive=0

这个 write 权限还是有问题， 看到 红色的标记了吗，正常的情况是没有 这两个 c512， c768的。seAndroid 主要采用了两种强制访问的方法： TE  MLS。 我们经常接触到的都是 TE。 这个恰好是 MLS 相关的，这个部分比较难理解，详细的可以读下面连接的文档

https://blog.youkuaiyun.com/l173864930/article/details/17194899。 我用到的只参考了下面的部分：

在SEAndroid中共定义了三个拥有巨大权限的attribute分别是mlstrustedsubject、mlstrustedobject、unconfineddomain，被分类到mlstrustedsubject的type在充当主体domain是可以越过MLS检查，被分类到mlstrustedobject的type在充当客体时可以越过MLS检查，被分到unconfineddomain的type则拥有所有权限可对客体进行任意操作。
在SEAndroid中被分在mlstrustedsubject attribute中的type有adbd、debuggerd、drmserver、init、installd、kernel、mediaserver、netd、surfaceflinger、su、system、vold、zygote。
被分在mlstrustedobject attribute中的type有alarm_device、ashmem_device、binder_device、log_device、mtp_device、nv_device、powervr_device、ptmx_device、null_device、cgroup、sysfs、sysfs_writable、sysfs_writable、sysfs_writable、debugfs、apk_data_file、cache_file、dnsproxyd_socket。
被分在unconfineddomain的type有init、kernel、su。

按照上面的说明，我可以把 untrusted_app_25 类型定义的时候加上 mlstrustedsubject, 但是增加后 编译报错，因为 untrusted_app_25 是已经定义好的类型， 再定义会冲突。 那么只能修改 video_usb_device 设备的类型了，这个是我们新建的，可以定义， 在 类型定义中，我增加了 mlstrustedobject， 问题解决。

type video_usb_device, dev_type, mlstrustedobject;

下面两种常见类型：

1，基于proc下出现selinux权限问题
第一步 在device/qcom/sepolicy/vendor/common/file.te 定义selinux type: proc_xxxx，如下：
type proc_xxxx, fs_type;

第二步 device/qcom/sepolicy/vendor/common/genfs_contexts,绑定proc_xxxx到对应的实际节点
genfscon proc /touchscreen/glove u:object_r:proc_xxxx:s0

第三步 device/qcom/sepolicy/vendor/common/system_app.te,申请权限system_app的权限
allow system_app proc_xxxx:file rw_file_perms;

2，基于sys下出现selinux权限问题
第一步 在device/qcom/sepolicy/vendor/common/file.te 定义selinux type: proc_xxxx，如下：
type sys_xxxx, fs_type;

第二步 device/qcom/sepolicy/vendor/common/file_contexts,绑定sys_到对应的实际节点。 sys/bus/i2c/devices/xxxx/xxx u:object_r:sys_xxxx:s0

第三步 device/qcom/sepolicy/vendor/common/system_app.te,申请权限system_app的权限
allow system_app sys_xxxx:file rw_file_perms;

注：绑定时，需要给予实际路径，可以去find 查找一下具体实际路径。

参考：

Android SElinux 权限_selinux 访问 proc-优快云博客