Android的Sepolicy實際上是對SELinux安全策略的描述和設置。
什麼是SELinux
安全增強型 Linux（Security-Enhanced Linux）簡稱 SELinux，它是 Linux 的一個安全子系統。SELinux 主要作用是最大限度地減小系統中服務進程可訪問的資源（最小權限原則）。對資源的訪問控制分爲兩類: DAC和MAC.
DAC
在未使用SELinux的系統上, 對資源的訪問是通過權限位來確定, 比如一個文件對所屬用戶是否有讀、寫、執行權限, 其他用戶的訪問可由所屬用戶進行配置. 這種由所屬用戶自己決定是否將資源的訪問權或部分訪問權授予其他用戶，這種控制方式是自主的，即自主訪問控制（Discretionary Access Control, DAC).
ls -l可查看權限
> ls -l note -rw-rw-r-- 1 ifantsai ifantsai 37 6月 17 13:36 note
MAC
在使用了 SELinux 的系統上，對資源的訪問除了通過權限位判定外，還需要判斷每一類進程是否擁有對某一類資源的訪問權限。這種方式對資源的訪問控制, 稱之爲強制訪問控制（Mandatory Access Control, MAC）.只給每個進程開放所需要的資源, 將權限開放到最小, 當進程出現漏洞時也只會影響到該進程所涉及的資源, 這大大提升了安全性.
SELinux工作模式
SELinux 有三種工作模式，分別爲:
- enforcing: 強制模式, 執行SELinux規則, 違反的行爲會被阻止
- permissive: 寬容模式, 執行SELinux規則, 違反的行不會被阻止
- disabled: 關閉SELinux
通過執行getenforce命令可以獲取當前SELinux的工作模式。
SELinux與Android
SELinux是Google從android 5.0開始，強制引入的一套非常嚴格的權限管理機制，主要用於增強系統的安全性。然而，在Android系統開發中，我們經常會遇到由於SELinux造成的各種權限不足，即使擁有“萬能的root權限”，也不能獲取全部的權限。
爲了澄清是否因爲SELinux導致的問題，可以嘗試將SELinux工作模式臨時改爲寬容模式看問題是否解決, 來判定是否是SELinux引起的問題.
# 修改工作模式爲寬容模式
setenforce permissive
# 臨時禁用SELinux
setenforce 0
# 獲取當前sepolicy配置
getenforce
遇到權限問題時, 在log中會打印avc denied提示缺少什麼權限, 可以通過dmesg | grep avc過濾出所有avc denied.
如果問題消失了，基本可以確認是SELinux造成的權限問題，需要通過正規的方式來解決權限問題。
遇到權限問題，在logcat或者kernel的log中一定會打印avc denied提示缺少什麼權限，可以通過命令過濾出所有的avc denied，再根據這些log各個擊破：
cat /proc/kmsg | grep avc
或
dmesg | grep avc
例如：
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
可以看到有avc denied，且最後有permissive=0，表示不允許。
解決avc denied
解決原則是：缺什麼權限補什麼，一步一步補到沒有avc denied爲止。
解決權限問題需要修改的權限文件如下位置，以.te結尾
A：Android/devicesoftwinner/astar-common/sepolicy/*.te
B：Android/external/sepolicy/*.te
其中，A是對B的overlay（覆蓋），能在A修改的儘量在A修改，儘量避免修改B，修改B可能會導致CTS fail問題，修改A不會影響CTS測試。
下面給出四個案例：
案例1
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
分析過程：
缺少什麼權限： {undefined write }權限，
誰缺少權限： scontext=u:r:kernel:s0
對哪個文件缺少權限：tcontext=u:object_r:block_device
什麼類型的文件： tclass=blk_file
完整的意思： kernel進程對block_device類型的blk_file缺少write權限。
解決方法：在上文A位置，找到kernel.te這個文件，加入以下內容：
allow kernel block_device:blk_file write;
make installclean後重新編譯，刷boot.img纔會生效
萬能公式
通過案例，我們可以總結出一般規律,以下面爲例
audit(1441759284.810:5): avc: denied { read } for pid=1494 comm="sdcard" name="0" dev="nandk" ino=245281 scontext=u:r:sdcardd:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0
某個scontext對某個tclass類型的tcontext缺乏某個權限，我們需要允許這個權限：
我們的log重新排列一下，
scontext = u:r:sdcardd
tcontex t= u:object_r:system_data_file:s0
tclass = dir
avc: denied { read }
在scontext所指的.te文件（例如sdcardd.te）中加入類似如下allow內容：
allow <scontext> <tcontext>:<tclass> {<avc: denied>}
案例2
在RK Android9.0上進行操作, 權限文件以.te爲後綴, 涉及到需要修改的路徑:
android/device/rockchip/common/sepolicyandroid/device/rockchip/rk3399/sepolicy
Android自帶的進程服務通過以上目錄配置即可 , 自己添加的第三方進程需要添加到自定義的目錄下
以如下所示的avc denied爲例講解
# avc: denied { 操作權限 } for pid=7201 comm=“進程名” scontext=u:r:源類型:s0 tcontext=u:r:目標類型:s0 tclass=訪問類別 permissive=0
avc: denied { read } for pid=7517 comm="[email protected]" name="u:object_r:default_prop:s0" dev="tmpfs" ino=11426 scontext=u:r:hal_audio_default:s0 tcontext=u:object_r:default_prop:s0 tclass=file permissive=0
主要關注以下內容:
denied {read}: 表示缺少read權限scontext=u:r:hal_audio_default:s0: 表示hal_audio_default缺少了權限tcontext=u:object_r:default_prop:s0: 表示是對default_prop缺少了權限tclass=file: 表示缺少權限的資源類型爲file
因此只要在hal_audio_default.te文件中加入下面內容即可
allow hal_audio_default tcontext:file read;
如果需要賦予read, open權限, 當有多個權限時用{}包裹
allow hal_audio_default tcontext:file { read open };
或者參考android/system/sepolicy/public/global_macros中賦予一個複合權限, 如r_file_perms 表示{ getattr open read ioctl lock map }
參考鏈接：
SELinux之解決avc denied： https://www.caiyifan.cn/p/38175be7.html
Android SELinux avc dennied權限問題解決方法： https://blog.csdn.net/tung214/article/details/72734086