Android SELinux avc denied解决
參考：Android SELinux avc dennied權限問題解決方法
https://blog.csdn.net/tung214/article/details/72734086
?
解決原則：缺什么權限補什么，直到沒有avc denied為止。
解決方法：在對應的.te中增加allow語句。
?
格式一般如下：
avc: denied { 操作權限 } for pid=7201 comm=“進程名” scontext=u:r:源類型:s0 tcontext=u:r:目標類型:s0 tclass=訪問類型 permissive=0
?
案例：
audit: type=1400 audit(1113.763:288): avc:? denied? { write } for? pid=328 comm="fastbootd" name="mmcblk0p29" dev="tmpfs" ino=7915 scontext=u:r:fastbootd:s0 tcontext=u:object_r:mmcblk_device:s0 tclass=blk_file permissive=1
scontext和tcontext都是安全上下文，分別稱為主體和客體，主體一般都是進程，客體則是主體訪問的資源。
缺少什么權限：?????????????? { write }權限，
誰缺少權限：??????????????????? scontext=u:r:fastbootd:s0
對哪個資源缺少權限：???? tcontext=u:object_r:mmcblk_device:s0
什么類型的資源：??????????? tclass=blk_file
完整的意思： fastbootd進程對mmcblk_device類型的blk_file缺少write權限。
?
解決方法：在fastbootd.te文件（若沒有則添加）加入內容：
???? allow fastbootd mmcblk_device:blk_file { read write getattr open ioctl };
即允許fastbootd對mmcblk_device類型的blk_file進行read/write/ioctl等操作。
————————————————
版權聲明：本文為CSDN博主「wuzoujing」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/wuzoujing/article/details/89562505
這篇文字本人原創于2015年，并作為原廠發布文檔release，當時并未上傳博客，估計已經被很多網友發表了。
1. 概述
SELinux是Google從android 5.0開始，強制引入的一套非常嚴格的權限管理機制，主要用于增強系統的安全性。
然而，在開發中，我們經常會遇到由于SELinux造成的各種權限不足，即使擁有“萬能的root權限”，也不能獲取全部的權限。本文旨在結合具體案例，講解如何根據log來快速解決90%的SELinux權限問題。
2. 調試確認SELinux問題
為了澄清是否因為SELinux導致的問題，可先執行：
setenforce 0 （臨時禁用掉SELinux）
getenforce? （得到結果為Permissive）
如果問題消失了，基本可以確認是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，表示不允許。
3. 具體案例分析
解決原則是：缺什么權限補什么，一步一步補到沒有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
?
分析過程：
缺少什么權限：????? { 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才會生效。
?
案例2
audit(0.0:53): avc: denied { execute } for? path="/data/data/com.mofing/qt-reserved-files/plugins/platforms/libgnustl_shared.so" dev="nandl" ino=115502 scontext=u:r:platform_app:s0 tcontext=u:object_r:app_data_file:s0 tclass=file permissive=0
?
分析過程：
缺少什么權限：????? { execute}權限，
誰缺少權限：??????? scontext = u:r:platform_app:s0
對哪個文件缺少權限：tcontext = u:object_r:app_data_file
什么類型的文件：??? tclass= file
完整的意思： platform_app進程對app_data_file類型的file缺少execute權限。
?
解決方法：在上文A位置，找到platform_app.te這個文件，加入以下內容：
allow? platform_app? app_data_file:file? execute;
make installclean后重新編譯，刷boot.img才會生效。
?
案例3
audit(1444651438.800:8): avc: denied { search } for pid=158 comm="setmacaddr" name="/" dev="nandi" ino=1 scontext=u:r:engsetmacaddr:s0 tcontext=u:object_r:vfat:s0 tclass=dir permissive=0
解決方法 ：engsetmacaddr.te
allow? engsetmacaddr? vfat:dir? { search write add_name create }; 或者
allow? engsetmacaddr?? vfat:dir? create_dir_perms;
(create_dir_perms包含search write add_name create可參考external/sepolicy/global_macros的定義聲明)
?
案例4
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
解決方法 ：sdcardd.te
allow? sdcardd? system_data_file:dir? read;? 或者
allow? sdcardd? system_data_file:dir? rw_dir_perms;
?(rw_dir_perms包含read write，可參考external/sepolicy/global_macros的定義聲明)
?
?
4. 萬能公式
通過這四個案例，我們可以總結出一般規律,
以第案例4為例：
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）中加入類似如下allowe內容：
?
5. TIPS
1. 以上以.te為后綴的文件都在以下位置：
A：Android/devicesoftwinner/astar-common/sepolicy/*.te
B：Android/external/sepolicy/*.te
其中，A是對B的overlay（覆蓋），能在A修改的盡量在A修改，修改B可能會導致CTS fail問題，修改A不會影響CTS測試。修改之后，為了節約驗證時間，只重刷boot.img即可看效果；
?
2. 有時候avc denied的log不是一次性暴露所有權限問題，要等解決一個權限問題之后，才會暴露另外一個權限問題。比如提示缺少某個目錄的read權限，加入read之后，才顯示缺少write權限，要一次次一次試，一次一次加，時間成本極大。
針對dir缺少的任何權限，建議賦予create_dir_perms，基本涵蓋對dir的所有權限，比如：
{ open search write read rename create rmdir getattr }等等。
針對file缺少的任何權限，建議賦予rwx_file_perms，基本涵蓋對file的所有權限，比如：
包含{ open read write open execute getattr create ioctl }等等。
更多內容請參考external/sepolicy/global_macros來了解更多權限聲明。
3. 要加入的權限很多時，可以用中括號，比如：
allow engsetmacaddr? vfat:dir { search write add_name create};
4. 修改A位置的.te文件遇到編譯錯誤怎么辦？
（首先請排除拼寫錯誤）說明此項權限是SELinux明確禁止的，也是Google CTS禁止的，如果產品不需要過CTS，可以修改。一般來說，編譯出錯的log會提示相關哪個文件哪一行出錯，文件位置一定會在B里的.te文件。比如B規定了以下neverallow,
neverallow system_server sdcard_type:dir { open read write };
那么system_server是不能擁有這些權限的，如果賦予這些權限就編譯報錯，解決方法是根據編譯錯誤提示的行號，把這一句注釋掉即可。
?
?
6. 高級進階
6.1. 新建.te安全策略文件方法
以上基本是對已經存在的進程增加權限，但對第三方進程改如何新增一個全新的te文件并賦予權限呢？
以寫mac地址的setmacaddr執行文件為例（這個執行檔android原生不存在，自行添加的）：
在init.xxx.rc中如下服務：
service engsetmacaddr? /system/bin/setmacaddr? /data/misc/wifi/wifimac.txt
??? class main
??? disabled
oneshot
?
?
1. 在device/softwinner/astar-common/sepolicy/file_contexts中，參考其他進程聲明一個scontext：
……
/system/bin/install-recovery.sh u:object_r:install_recovery_exec:s0
/system/bin/dex2oat???? u:object_r:dex2oat_exec:s0
/system/bin/patchoat??? u:object_r:dex2oat_exec:s0
/system/bin/setmacaddr u:object_r:engsetmacaddr_exec:s0
指定setmacaddr的路徑，并指定一個名字，一定要以service名+_exec結尾
?
2.參考其.te文件在device/softwinner/astar-common/sepolicy/file_contexts 創建engsetmacaddr.te文件，內容如下：
type engsetmacaddr, domain;
type engsetmacaddr_exec, exec_type, file_type;
init_daemon_domain(engsetmacaddr)
allow engsetmacaddr? vfat:dir { search write add_name create};
allow engsetmacaddr? vfat:file { create read write open };
allow engsetmacaddr? engsetmacaddr:capability dac_override;
allow engsetmacaddr? shell_exec:file { execute read open execute_no_trans};
allow engsetmacaddr? system_data_file:dir { write add_name remove_name };
allow engsetmacaddr? system_data_file:file { create execute_no_trans write open setattr};
allow engsetmacaddr? system_file:file { execute_no_trans};
以上賦予的權限全部是根據avc denied的log缺什么一步一步補什么來的。
?
6.2. 新設備節點增加訪問權限
驅動創建了一個新的設備節點，即使權限是777，android層也是沒有訪問權限的。
下面以一個/dev/wifi_bt節點為示范，讓此節點被用戶空間的system_server進程訪問。
1. 編輯devicesoftwinner/astar-common/sepolicy/device.te，仿照這個文件里的寫法，定義一個dev_type類型的wifi_bt_device設備：
type misc_block_device, dev_type;
type private_block_device, dev_type;
……
type wf_bt_device, dev_type; ?
?
2. 編輯file_contexts.te，將/dev/wf_bt節點聲明為第1步定義的wf_bt_device:
/dev/block/by-name/misc???????? u:object_r:misc_block_device:s0
/dev/block/by-name/alog???????? u:object_r:log_block_device:s0
/dev/block/by-name/private????? u:object_r:private_block_device:s0
# We add here ?
/dev/wf_bt????????????? u:object_r:wf_bt_device:s0 ?
?
3. 在system_server.te，根據dmesg | grep avc允許system_server對wf_bt_device這個節點可讀可寫：
# Read/Write to /proc/net/xt_qtaguid/ctrl and and /dev/xt_qtaguid. ?
allow system_server qtaguid_proc:file rw_file_perms; ?
allow system_server qtaguid_device:chr_file rw_file_perms; ?
?……
allow system_server wf_bt_device:chr_file rw_file_perms; ?
其他進程如需訪問/dev/wf_bt節點，依樣畫葫蘆，增加對wf_bt_device的權限即可。
————————————————
版權聲明：本文為CSDN博主「縹緲孤鴻影_love」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/tung214/article/details/72734086
總結
以上是生活随笔為你收集整理的Android SELinux avc denied解决的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Greenplum实战--检查集群状态g
- 下一篇： linux运行虚幻引擎4,虚幻引擎4.2