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 查找一下具体实际路径。
参考: