Android selinux 权限添加
1.问题排查
当某个功能不能正常使用且日志有相关的avc denial时，首先排查是不是SELinux权限引发的问题，通过 setenforce 命令关闭SELinux。
关闭SELinux （Permissive）后， 功能正常了，说明就是权限问题，此时需要增加相关的权限。
Permissiver 仅用于问题排查，添加权限时，需要为 Enforcing 状态。
2.日志解析
例如：[ 29.428184][ T423] type=1400 audit(1773301890.624:4): avc: denied { search } for comm="BootAnimation" name="data" dev="dm-51" ino=301 scontext=u:r:bootanim:s0 tcontext=u:object_r:system_data_file:s0:c512,c768 tclass=dir permissive=0
denied { search } ： 被拒绝的操作，这里是搜索，相应的还有getattr read open 等等。
comm="BootAnimation"：触发该操作的进程名。
name="data"：尝试访问的文件/目录名。
dev="dm-51"：设备映射器，表示加密/分区设备，不重要。
scontext=u:r:bootanim:s0：源上下文：进程的上下文。
tcontext=u:object_r:system_data_file:s0:c512,c768：目标上下文：被访问的文件/目录的上下文。
tclass=dir：目标类型，相应的还有file lnk_file等等。
permissive=0：enforcing 模式（非 permissive）。
这表明：BootAnimation 进程尝试搜索 /data 目录，但被 SELinux 阻止了。
根本原因是：SELinux 策略中，bootanim 域缺少对 system_data_file 类型目录的 search 权限。
3.添加权限
找到相关的策略文件，在 device/cix/sky1/sky1_evb/sepolicy 目录下找到 bootanim.te 文件，如果没有就创建，然后在该文件中添加：
allow bootanim system_data_file:dir { search };
即 allow 源上下文 目标上下文：目标类型 { 需要的权限 } 即可。
如果不想手动编写策略，可以在主机上下载相应的工具 audit2allow 和 selinux 策略文件，安装命令如下：
sudo apt install policycoreutils
sudo apt install selinux-policy-default
在开发板中收集 avc denial
dmesg | grep avc > dmesg_avc.log
logcat | grep avc > logcat_avc.log
将上面的 log 传到主机上，然后执行 audit2allow -i dmesg_avc.log && audit2allow -i logcat_avc.log
亲测不好用，不推荐，建议手动分析编写或者把日志提交给AI。
4.特殊情况
4.1 ioctl 权限的添加
如果有类似 avc: denied { ioctl } 的权限问题，比如：
avc: denied { ioctl } for comm="system_server" path="/dev/__properties__" dev="tmpfs" ino=123 ioctlcmd=0x7701 scontext=u:r:system_server:s0 tcontext=u:object_r:properties_device:s0
除了添加 allow system_server properties_device:file { ioctl }; 之外，还需要额外指定具体的 ioctl 命令：
allowxperm system_server properties_device:file ioctl { 0x7701 };
4.2 解决neverallow冲突
添加好规则后进行编译，可能会造成冲突，比如有如下规则：
avc: denied { read } for comm="bootanim" path="/sys/devices/platform/special/special_file" scontext=u:r:bootanim:s0 tcontext=u:object_r:sysfs:s0 tclass=file
按照之前的分析，我们需要添加 allow bootanim sysfs:file { read }; 但这样后直接违反neverallow，造成编译错误。
此时需要在 bootanim.te 中定义新类型：
type bootanim_special_file, fs_type, sysfs_type, file_type;
然后在 genfs_contexts 中为目标文件绑定标签：
genfscon sysfs /devices/platform/special/special_file u:object_r:bootanim_special_file:s0
最后在 bootanim.te 中添加规则：
allow bootanim bootanim_special_file:file { read };
这样即规避了neverallow冲突，同时也给目标文件增加了相应的访问权限。
一般在以下几种情况考虑这种添加方式：
- 访问 /sys/ 下特定文件（sysfs）
- 访问 /proc/ 下特定文件（procfs）
- 访问 /dev/ 下自定义设备节点
- 访问特定应用程序数据目录
- 直接添加allow规则编译失败，提示违反neverallow
绑定标签时，需要判断目标文件所在的文件系统，以选择正确的配置文件：
| 路径前缀 | 文件系统类型 | 配置文件 | 语法示例 |
|----------|--------------|----------|----------|
| `/sys/` | sysfs | `genfs_contexts` | `genfscon sysfs /devices/... u:object_r:type:s0` |
| `/proc/` | procfs | `genfs_contexts` | `genfscon proc /... u:object_r:type:s0` |
| `/dev/` | devtmpfs | `file_contexts` | `/dev/xxx u:object_r:type:s0` |
| `/data/` | ext4/f2fs | `file_contexts` | `/data/xxx u:object_r:type:s0` |
| `/system/` | ext4/erofs | `file_contexts` | `/system/xxx u:object_r:type:s0` |
| `/vendor/` | ext4/erofs | `file_contexts` | `/vendor/xxx u:object_r:type:s0` |
对于虚拟文件系统，大部分是 path 为 sys、proc、dev 开头的文件，将绑定的语法添加到 genfs_contexts 文件中，genfs_contexts不支持通配符和正则表达式，需要进行精确匹配。
对于普通文件系统，大部分是 path 为 data、system、vendor 开头的文件，需要将绑定的语法添加到 file_contexts 文件中，file_contexts支持通配符和正则表达式。对于其他不确定的文件，直接用AI判断。
添加之后，可在系统中通过命令 "ls -alZ 文件路径" 来判断该文件的标签是否绑定成功。
4.3 unknown type & duplicate declaration
对于平台定义好的类型，比如
avc: denied { create } for comm="app_process" anonclass=[userfaultfd] scontext=u:r:tradeinmode:s0 tcontext=u:object_r:tradeinmode:s0 tclass=anon_inode
/system/sepolicy/private 已经存在 tradeinmode.te 文件，如果按照以前的方式添加，编译时会遇到 unknown type ，即使添加相应 type 后又会遇到 duplicate declaration。
此时我们需要在 device/cix/sky1/sky1_evb/sepolicy 目录下添加 system_ext/private 目录，然后添加 tradeinmode.te 文件。
在该文件第一行添加 userfaultfd_use(tradeinmode) 然后再添加相应的 allow，此外，还需要更改device/cix/sky1/sky1_evb/BoardConfig.mk 文件，添加下面内容：
SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS += $(CIX_DEVICE_PATH)/sepolicy/system_ext/private
这样保证 Vendor 策略和 Platform 策略是两路编译。