前言
工作中可能會遇到SELinux 的一些錯誤，希望本文可以幫助工程師提高開發(fā)效率
知識點：
1.Android O 版本 SELinux Policy 路徑的一些思考
2.Android O 版本 APP 如何獲取sys file system 中節(jié)點的寫權(quán)限
3.Android O 版本 APP 如何獲取proc file system 中節(jié)點的寫權(quán)限
1.SELinux Policy 路徑
O 版本: 將SELinux Policy 文件存放在下面目錄
1). Google 原生目錄 alps/system/sepolicy
2). MTK 配置目錄 alps/device/mediatek/sepolicy/
注意的是里面有basic, bsp, full 目錄.
其中basic 目錄所有的版本都會吃到; bsp 目錄則是bsp 版本 + Turnkey 版本都會吃到; full 目錄則是只有Turnkey 版本會吃到
那么我們到底應(yīng)該改basic, bsp, full哪個路徑呢？
device/mediatek/mt6580/BoardConfig.mk
如果MTK_BSP_PACKAGE為yes，那么系統(tǒng)將編譯basic, bsp這2個目錄
否則編譯basic, bsp，full這三個目錄
MTK_BSP_PACKAGE定義在
device/mediateksample/tecno8321p2_6953/ProjectConfig.mk
結(jié)論：修改basic和bsp任意一個目錄都可以，最終這2個目錄下都會整合成一個te文件?。?！
2.Android O APP 如何獲取sys file system 中節(jié)點的寫權(quán)限
平時工作中，我們會自定義節(jié)點去做一些功能，例如：
創(chuàng)建節(jié)點: /sys/devices/virtual/torch/torch/torch_level
寫入1 ，后手電筒亮，寫入0 ，后手電筒滅。
當你添加完需求之后，可能會遇到SELinux的錯誤
avc: denied { write } for name="torch_level" dev="sysfs" ino=9205
scontext=u:r:system_app:s0 tcontext=u:object_r:sysfs:s0 tclass=file
permissive=0
分析過程：
缺少什么權(quán)限： { write }權(quán)限，
誰缺少權(quán)限： scontext=u:r:system_app:s0
對哪個文件缺少權(quán)限：tcontext=u:object_r:sysfs:s0
什么類型的文件： tclass=file
解決方法：誰缺少權(quán)限，我們就改動{誰.te},這里改動system_app.te
方案一：暴力解決方案，不推薦
-
device/mediatek/sepolicy/basic/non_plat/system_app.te
或者device/mediatek/sepolicy/bsp/non_plat/system_app.te
allow system_app sysfs:file { write };
2.system/sepolice/private/app.te
注釋掉谷歌官方邏輯
這樣改雖然可以解決問題， 但是Google 默認禁止app , 包括system app, radio app
等直接寫/sys 下面的文件, 認為這個是有安全風險的。
如果直接放開SELinux 權(quán)限, 會導致CTS 無法通過.因此不推薦這種改法。
方案二：自定義類型，推薦
- 在device/mediatek/sepolicy/basic/non_plat/file.te 定義torch_level SELinux type
type app_torch_file, fs_type,sysfs_type;
//這里app_torch_file名字可以隨意取，原則是方便理解
- 在device/mediatek/sepolicy/bsp/non_plat/file_context 綁定 torch_level 對應(yīng)的label
/sys/devices/virtual/torch/torch/torch_level u:object_r:app_torch_file:s0
- 在device/mediatek/sepolicy/basic/non_plat/system_app.te 中申請權(quán)限.
allow app system_app_torch_file:file rw_file_perms;
這里的rw_file_perms是一個包含所有的讀寫權(quán)限
define(r_file_perms',{ getattr open read ioctl lock }')
define(w_file_perms',{ open append write }')
define(rw_file_perms',{ r_file_perms w_file_perms }')
- 為其它的process 申請相關(guān)的權(quán)限（如果需要）
device/mediatek/sepolicy/basic/non_plat/system_server.te
allow system_server app_torch_file:file rw_file_perms;
5.device/mediatek/mt6580/init.mt6580.rc
或者device/mediateksample/{Project}/init.project.rc
如果以上4步都無法訪問，請?zhí)砑右韵聶?quán)限
chmod 0666 /sys/devices/virtual/torch/torch/torch_level
chown root system /sys/devices/virtual/torch/torch/torch_level
方案三：綁定service訪問，推薦 (需要應(yīng)用工程師配合)
通過system server service 或者 init 啟動的service 讀寫,
然后app 通過binder/socket 等方式連接APP 訪問.
此類安全可靠, 并且可以在service 中做相關(guān)的安全審查, 推崇這種方法.
3.Android O APP 如何獲取proc file system 中節(jié)點的寫權(quán)限
同樣有3種方案，這里只講
方案二：自定義類型，推薦
具體的做法下面以 fm app 控制/proc/fm_antenna_en來說明.
方案二：自定義類型，推薦
- 在device/mediatek/sepolicy/basic/non_plat/file.te 定義proc_fm_antenna_en SELinux type
type proc_fm_antenna_en, fs_type;
//這里proc_fm_antenna_en名字可以隨意取，原則是方便理解
- 在sepolicy/basic/non_plat/genfs_contexts 綁定 proc_fm_antenna_en對應(yīng)的label
genfscon proc /fm_antenna_en u:object_r:proc_fm_antenna_en:s0
//這里格式要注意， /fm_antenna_en是去掉proc后具體的節(jié)點路徑
- 在device/mediatek/sepolicy/basic/non_plat/platform_app.te 中申請權(quán)限.
allow platform_app proc_fm_antenna_en:file rw_file_perms;
