android P 修改sysfs的 u:object_r:失效问题分析

本文参考https://blog.csdn.net/pen_cil/article/details/89434349
部分修改
我在Android P项目上遇到和Kian_G类似的问题，但是按照他文档的描述并没有完全解决u:object_r:sysfs:so 切换成我自定义my_sysfs。
如下部分为参考部分
在Android P上要开发一个开机过程中运行bin程序，在Android O上权限问题还算比较好解决，而在 Android P上面由于谷歌收紧了 Android SElinux控制，增加了许多neverallow规则，导致调试权限十分不便
开发的bin程序由于要开机运行，因此需要通过init.rc去启动这个bin程序severe。而这个bin程序要去控制“data”分区文件和“sys”文件节点状态。因此该功能涉及到selinux权限有两部分，一部分是sys下的权限，一部分是data下的权限
在userdebug下SElinux 权限调试模式
由于该功能在开机阶段，不能直接用setenforce 0方式去设置SElinux权限为permissive进行debug，可以采用在自己的te文件添加对自己该部分的permissive权限用于调试，以此bin程序举例
type egbin, domain;
type egbin_exec, exec_type, file_type;
permissive egbin;
#注意：该功能只能用在userdebug、eng版本，user版本会导致编译不通过
init_daemo_domain(egbin)
12345
sys下的权限由于Android P收紧的对sysfs 的权限，导致直接配置对sysfs的SElinux权限，会触发编译时的neverallow规则，如
……
allow egbin sysfs:file { read getattr open ioctl }
allow egbin sysfs:dir { search }
……
1234
上述规则在Android P之前是可以编译通过的，在Android P上是不可以的。编译后报如下错误：
FAILED:
out/target/product/xxx/obj/ETC/sepolicy_neverallows_intermediates/sepolicy_neverallows
/bin/bash -c "(rm -f
out/target/product/xxx/obj/ETC/sepolicy_neverallows_intermediates/sepolicy_neverallows
) && (ASAN_OPTIONS=detect_leaks=0 out/host/linux-x86/bin/checkpolicy -M
-c 30 -o
out/target/product/xxx/obj/ETC/sepolicy_neverallows_intermediates/sepolicy_neverallows
out/target/product/xxx/obj/ETC/sepolicy_neverallows_intermediates/policy.conf
)"libsepol.report_failure: neverallow on line 31 of system/sepolicy/private/domain.te
(or line 27782 of policy.conf) violated by allow system_app sysfs:file { read
};
推测原因可能是Android P收紧了对“sys”底下的文件权限，如果直接给应用sysfs权限，会导致应用权限太大，可以在sys下干许多事情，很不安全。因此需要细化sys下的权限，对于上面问题需要在file.te和file_contexts下添加对于sys具体目录下的组别
#Path:/device/qcom/sepolicy/vendor/common/file.te
##file_contexts
#egbin
sys/fs/features(/.)? u:object_r:sysfs_egbin:s0
sys/fs/sda(/.)? u:object_r:sysf_egbin:s0
#Path:/device/qcom/sepolicy/vendor/common/file_contexts
##file.te
#egbin
type sysfs_egbin, fs_type, sysfs_type
123456789
在自己的te文件重新定义规则
……
allow egbin sysfs_egbin:file { read getattr open ioctl }
allow egbin sysfs_egbin:dir { search }
……
1234
注意（一个坑）
按道理这样就已经没有什么问题了，但是在debug的时候还有报sys下权限问题，此时可能不是权限配的有问题，有可能是在file.te 中配置的规则不生效，如在sys/fs/看到的情况如下：
adb shell ls -alZ /sys/fs/

drwxr-xr-x 4 root root u:object_r:sysfs:s0 0 1970-01-29 19:16 .
drwxr-xr-x 11 root root u:object_r:sysfs:s0 0 1970-01-29 19:16 …
drwxr-xr-x 2 root root u:object_r:sysfs_egbin:s0 0 1970-01-29 19:16 features
drwxr-xr-x 2 root root u:object_r:sysfs:s0 0 2018-10-30 18:16 sda
1234
可以发现features配置成功，而sda10未配置成功，这部分原因是sda是在开机过程中文件系统创建的debug节点之前是不存在的，因此配置不生效。

下面为我遇到的问题
我这边遇到的问题跟Kian_G 有点不一样，一样的是我修改u:object_r不成功，不一样的是我创建的是sys/class/目录下的节点而不是sys/fs/目录下的节点，我按照Kian_G添加并没有完全解决我的问题，所以后面我没有贴上来，如果有和Kian_G一样的问题，可以参考他的修改。
2.1 创建class的file文件而不是device的file
通过排查，我遇到问题的原因是由于我创建sys/class节点方式是class_create – > device_create – > device_create_file 实现的，由于我创建的device是virtual的所以我只在vendor/common/file_contexts中添加
sys/class/mysysfs/(/.*)? u:object_r:sysf_egbin:s0
并没有生效，如果我们创建sys/class节点方式是class_create – > class_create_file，那么按照上面的方式在vendor/common/file_contexts中添加对应的u:object_r:是可以解决问题的。
第一种方式根据创建file所属不同对应的u:object_r:生效与否也不一致，这种方式不一定能完全解决selinux的问题，有些节点我们不在class目录下就没有办法使用这种方式，2.2就是针对其他目录下的解决方案
2.2 通过修改解决genfscon解决问题
在system/sepolicy目录下修改修改如下
aosp/platform/system/sepolicy
/ public/file.te中添加新的type类型
type my_sysfs,
fs_type, sysfs_type;
aosp/platform/system/sepolicy
/ private/genfs_contexts 中添加genfscon语句
genfscon /sys/fs/ u:object_r:my_sysfs:s0
需要配套修改aosp/platform/system/sepolicy
/ prebuilts/api/28.0/目录下的文件否则会导致编译报错的问题
之后编译，下载adb shell
ls -alZ /sys/class/mysysfs/ 查看修改是否生效
drwxr-xr-x 4 root root u:object_r:sysfs:s0 0 1970-01-29 19:16 .
drwxr-xr-x 11root root u:object_r:sysfs:s0 0 1970-01-29 19:16 .
drwxr-xr-x 2 root root u:object_r: my_sysfs:s0 0 1970-01-29 19:16 aaa
drwxr-xr-x 2 root root u:object_r: my_sysfs:s0 0 2018-10-30 18:16 xxx
genfscon语句用于运行时标记伪文件系统和不支持扩展属性的传统文件系统。在SEAndroid中文件系统rootfs、proc、selinuxfs、cgroup、sysfs、inotifyfs、vfat、debugfs、fuse，都是采用这一方式进行安全上下文的标记，在ocontexts文件中定义了这些文件系统相应的安全上下文内容。
我的理解是开机的时候会根据genfs_contexts生成对应sysfs文件的object_r所以，如果我们创建文件是通过sysfs_create_file创建的话，默认生成的文件u:object_r:sysfs:s0，就需要在genfs_contexts中添加对应的类型。
2.2的方式能解决我目前遇到的所有的u:object_r:配置失效的问题。