1. 權限修改
方法1: adb在線修改seLinux
$ getenforce; //獲取當前seLinux狀態，Enforcing(表示已打開)，Permissive（表示已關閉） $ setenforce 1; //打開seLinux $ setenforce 0; //關閉seLinux
方法2: 從kernel中徹底關閉
修改LINUX/android/kernel/arch/arm64/configs/xxx_defconfig文件， 去掉CONFIG_SECURITY_SELINUX=y 的配置項
方法3: sepolicy中添加權限
修改依據: 通過指令cat /proc/kmsg | grep denied，或者kernel的Log中定位到標志性log。
修改步驟: 找相應的源類型.te文件，此文件可能的存放路徑 (其中源類型見下方的標志性log格式) ：
LINUX/android/external/sepolicy
LINUX/android/device/qcom/sepolicy/common
標志性log 格式:
avc: denied { 操作權限 } for pid=7201 comm=“進程名” scontext=u:r:源類型:s0 tcontext=u:r:目標類型:s0 tclass=訪問類型 permissive=0
在相應源類型.te文件，添加如下格式的一行語句：(結尾別忘了分號)
格式：allow 源類型 目標類型:訪問類型 {操作權限};
實例:
Kernel Log：
avc: denied {getattr read} for pid=7201 comm="xxx.xxx" scontext=u:r:system_app:s0 tcontext=u:r:shell_data_file:s0 tclass=dir permissive=0
修改方案
在system_app.te文件中，添加下面語句：
allow system_app shell_data_file:dir{getattr read};
scontext: start context，發起方
tcontext：target context, 接受方
若發起方訪問接受方沒有權限，一般權限配置在發起方，但是由權限接受方模塊負責人配置。
2. 將selinux報錯信息轉換為配置
# audit2allow -i selicx.txt
selicx.txt中存放的是“avc: denied”報錯打印，audit2allow不但會給出權限配置，而且還會給出配置的位置。
3.audit2why工具
~/tmp/selinux$ cat se_error.txt avc: denied { write } for comm="init" name="iostats" dev="sysfs" ino=67139 scontext=u:r:init:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=0 avc: denied { write } for comm="init" name="scheduler" dev="sysfs" ino=67122 scontext=u:r:init:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=0 ~/tmp/selinux$ ~/tmp/selinux$ audit2why -i se_error.txt avc: denied { write } for comm="init" name="scheduler" dev="sysfs" ino=67122 scontext=u:r:init:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=0 Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access.
解釋avc報錯原因。
4.查看文件的selinux屬性
/sys/class/wakeup # ls -la -Z total 0 drwxr-xr-x 2 root root u:object_r:sysfs_wakeup:s0 0 1970-01-01 08:00 . //selinux配置使用sysfs_wakeup drwxr-xr-x 112 root root u:object_r:sysfs:s0 0 1970-01-01 08:00 .. //selinux配置使用sysfs lrwxrwxrwx 1 root root u:object_r:sysfs:s0 0 2020-08-28 20:04 wakeup0 -> ../../devices/platform/.../c440000.qcom,spmi:qcom,pm8150@0:qcom,power-on@800/wakeup/wakeup0
5.file_context文件是設置節點或文件的selinux屬性類型的，.te文件是設置訪問權限的。通俗的理解，file_context是定義屬性的類型，.te文件是使用屬性類型。
6.看selinux報的是哪個文件的權限錯誤
As an example , In the following path ino , 82228 / 69931 / 49391 08-03 00:22:47.555 684 684 W Binder:684_2: type=1400 audit(0.0:3709): avc: denied { read } for name="wakeup58" dev="sysfs" ino=82228 scontext=u:r:system_suspend:s0 tcontext=u:object_r:sysfs:s0 tclass=dir permissive=0 08-03 00:22:47.555 684 684 W Binder:684_2: type=1400 audit(0.0:3710): avc: denied { read } for name="wakeup48" dev="sysfs" ino=69931 scontext=u:r:system_suspend:s0 tcontext=u:object_r:sysfs:s0 tclass=dir permissive=0 We have to see which path its pointing to using “find /sys -inum <number that is showing in the denials > “ this will change in each run where running with the right number will give you the path it was trying for .
舉例：
log： 01-01 00:00:53.725 1373 1373 W vendor-oplus-ha: type=1400 audit(0.0:1866): avc: denied { read } for name="u:object_r:system_prop:s0" dev="tmpfs" ino=13478 scontext=u:r:usage_hidl:s0 tcontext=u:object_r:system_prop:s0 tclass=file permissive=0 130|OP4AF7:/ # find /sys/ -inum 13478 /sys/firmware/devicetree/base/soc/xxx/port@4/endpoint/slave-mode
7.se context 屬性是 per inode， 鏈接的節點相當於新的節點了， 取決於是否對此節點是否賦予新的context.
8. 查看文件、進程、屬性的selinux安全上下文
(1) 查看某個屬性的selinux權限：# getprop -Z vendor.qcom.bluetooth.soc
u:object_r:vendor_bluetooth_prop:s0
給platform_app加此屬性的獲取權限，在platform_app.te中添加：get_prop(platform_app, vendor_bluetooth_prop)
(2) 查看某個進程的安全上下文：ps -AZ | grep com.android.myapp
(3) 查看某個文件的安全上下文：ls -laZ
9. 案例
案例1：avc: denied { write }之類的缺少權限
audit(0.0:67): avc: denied { write } for path="/dev/block/vold/93:96" dev="tmpfs" ino=/1263 scontext=u:r:kernel:s0 tcontext=u:object_r:block_device:s0 tclass=blk_file permissive=0
語法：rule_name source_type target_type : class perm_set**
萬能公式：
缺少什么權限：{ write }權限
誰缺少權限：scontext=u:r:kernel:s0
對誰缺少權限：tcontext=u:object_r:block_device:s0
什么類型：tclass=blk_file
kernel.te: allow kernel block_device:blk_file write;
寫操作一般還伴隨open、append等，所以一般使用w_file_perms宏替代單一的write
TODO: 解釋剩余命令的作用
~/tmp/selinux$ audi [tab]
audispd audit2allow audit2why auditctl auditd
TODO: 優秀博文
https://blog.csdn.net/yanjun821126/article/details/80828908
https://blog.csdn.net/shichaog/article/details/53728893
https://blog.csdn.net/xct841990555/article/details/82714322
https://blog.csdn.net/w2064004678/article/details/105515244/
selinux屬性模糊配置：
https://blog.csdn.net/iaMay_____/article/details/80344592
參考：
SELinux 權限問題: http://gityuan.com/2015/06/13/SEAndroid-permission/
屬性問題展開的selinux權限介紹：https://www.jianshu.com/p/88a92d101532