Selinux 權(quán)限問題解決方案

和你一起終身學(xué)習(xí)，這里是程序員Android

1. 概述

SELinux是Google從android 5.0開始，強(qiáng)制引入的一套非常嚴(yán)格的權(quán)限管理機(jī)制，主要用于增強(qiáng)系統(tǒng)的安全性。

然而，在開發(fā)中，我們經(jīng)常會(huì)遇到由于SELinux造成的各種權(quán)限不足，即使擁有“萬能的root權(quán)限”，也不能獲取全部的權(quán)限。本文旨在結(jié)合具體案例，講解如何根據(jù)log來快速解決90%的SELinux權(quán)限問題。

2. 調(diào)試確認(rèn)SELinux問題

為了澄清是否因?yàn)镾ELinux導(dǎo)致的問題，臨時(shí)禁用selinux ，重啟失效，可先執(zhí)行：

C:\Users\Administrator>adb shell getenforce
Enforcing
//臨時(shí)禁用selinux ，重啟失效
C:\Users\Administrator>adb shell setenforce 0
C:\Users\Administrator>adb shell getenforce
Permissive
C:\Users\Administrator>

如果問題消失了，基本可以確認(rèn)是SELinux造成的權(quán)限問題，需要通過正規(guī)的方式來解決權(quán)限問題。

遇到權(quán)限問題，在logcat或者kernel的log中一定會(huì)打印avc denied提示缺少什么權(quán)限，可以通過命令過濾出所有的avc denied，再根據(jù)這些log各個(gè)擊破：

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. 具體案例分析

解決原則是：缺什么權(quán)限補(bǔ)什么，一步一步補(bǔ)到?jīng)]有avc denied為止。

解決權(quán)限問題需要修改的權(quán)限文件如下位置，以.te結(jié)尾

A：Android/devicesoftwinner/astar-common/sepolicy/*.te

B：Android/external/sepolicy/*.te

其中，A是對(duì)B的overlay（覆蓋），能在A修改的盡量在A修改，盡量避免修改B，修改B可能會(huì)導(dǎo)致CTS fail問題，修改A不會(huì)影響CTS測(cè)試。

（如果不需要深入了解，請(qǐng)直接跳到萬能公式這一章閱讀更簡(jiǎn)潔）

下面給出四個(gè)案例：

案例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

分析過程：

缺少什么權(quán)限：{ write }權(quán)限，

誰缺少權(quán)限：scontext=u:r:kernel:s0

對(duì)哪個(gè)文件缺少權(quán)限：tcontext=u:object_r:block_device

什么類型的文件：tclass=blk_file

完整的意思：kernel進(jìn)程對(duì)block_device類型的blk_file缺少write權(quán)限。

解決方法：在上文A位置，找到kernel.te這個(gè)文件，加入以下內(nèi)容：

allow  kernel  block_device:blk_file  write;

make installclean && make bootimage
后重新編譯 ，刷boot.img才會(huì)生效。

案例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

分析過程：

缺少什么權(quán)限：{ execute}權(quán)限，

誰缺少權(quán)限：scontext = u:r:platform_app:s0

對(duì)哪個(gè)文件缺少權(quán)限：tcontext = u:object_r:app_data_file

什么類型的文件：tclass= file

完整的意思：platform_app進(jìn)程對(duì)app_data_file類型的file缺少execute權(quán)限。

解決方法：在上文A位置，找到platform_app.te這個(gè)文件，加入以下內(nèi)容：

allow  platform_app  app_data_file:file  execute;

make installclean后重新編譯，刷boot.img才會(huì)生效。

案例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. 萬能公式

通過這四個(gè)案例，我們可以總結(jié)出一般規(guī)律,

以第案例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

某個(gè)scontext對(duì)某個(gè)tclass類型的tcontext缺乏某個(gè)權(quán)限，我們需要允許這個(gè)權(quán)限：

我們的log重新排列一下，

scontext = u:r:sdcardd

tcontex t= u:object_r:system_data_file:s0

tclass = dir

avc: denied { read }

得到萬能套用公式如下：

在scontext所指的.te文件（例如sdcardd.te）中加入類似如下allowe內(nèi)容：

5. TIPS

1. 以上以.te為后綴的文件都在以下位置：

A：Android/devicesoftwinner/astar-common/sepolicy/*.te

B：Android/external/sepolicy/*.te

其中，A是對(duì)B的overlay（覆蓋），能在A修改的盡量在A修改，修改B可能會(huì)導(dǎo)致CTS fail問題，修改A不會(huì)影響CTS測(cè)試。修改之后，為了節(jié)約驗(yàn)證時(shí)間，只重刷boot.img即可看效果；

2. 有時(shí)候avc denied的log不是一次性暴露所有權(quán)限問題，要等解決一個(gè)權(quán)限問題之后，才會(huì)暴露另外一個(gè)權(quán)限問題。比如提示缺少某個(gè)目錄的read權(quán)限，加入read之后，才顯示缺少write權(quán)限，要一次次一次試，一次一次加，時(shí)間成本極大。
   針對(duì)dir缺少的任何權(quán)限，建議賦予create_dir_perms，基本涵蓋對(duì)dir的所有權(quán)限，比如：
   { open search write read rename create rmdir getattr }等等。
   針對(duì)file缺少的任何權(quán)限，建議賦予rwx_file_perms，基本涵蓋對(duì)file的所有權(quán)限，比如：
   包含{ open read write open execute getattr create ioctl }等等。

更多內(nèi)容請(qǐng)參考external/sepolicy/global_macros來了解更多權(quán)限聲明。

3. 要加入的權(quán)限很多時(shí)，可以用中括號(hào)，比如：

allow engsetmacaddr  vfat:dir { search write add_name create};

4. 修改A位置的.te文件遇到編譯錯(cuò)誤怎么辦？
   （首先請(qǐng)排除拼寫錯(cuò)誤）說明此項(xiàng)權(quán)限是SELinux明確禁止的，也是Google CTS禁止的，如果產(chǎn)品不需要過CTS，可以修改。一般來說，編譯出錯(cuò)的log會(huì)提示相關(guān)哪個(gè)文件哪一行出錯(cuò)，文件位置一定會(huì)在B里的.te文件。比如B規(guī)定了以下neverallow,
   neverallow system_server sdcard_type:dir { open read write };
   那么system_server是不能擁有這些權(quán)限的，如果賦予這些權(quán)限就編譯報(bào)錯(cuò)，解決方法是根據(jù)編譯錯(cuò)誤提示的行號(hào)，把這一句注釋掉即可。

6. 高級(jí)進(jìn)階

6.1. 新建.te安全策略文件方法

以上基本是對(duì)已經(jīng)存在的進(jìn)程增加權(quán)限，但對(duì)第三方進(jìn)程改如何新增一個(gè)全新的te文件并賦予權(quán)限呢？

以寫mac地址的setmacaddr執(zhí)行文件為例（這個(gè)執(zhí)行檔android原生不存在，自行添加的）：

在init.xxx.rc中如下服務(wù)：

service engsetmacaddr  /system/bin/setmacaddr  /data/misc/wifi/wifimac.txt

    class main

    disabled

oneshot

1. 在device/softwinner/astar-common/sepolicy/file_contexts中，參考其他進(jìn)程聲明一個(gè)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的路徑，并指定一個(gè)名字，一定要以service名+_exec結(jié)尾

2.參考其.te文件在device/softwinner/astar-common/sepolicy/file_contexts 創(chuàng)建engsetmacaddr.te文件，內(nèi)容如下：

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};

以上賦予的權(quán)限全部是根據(jù)avc denied的log缺什么一步一步補(bǔ)什么來的。

6.2. 新設(shè)備節(jié)點(diǎn)增加訪問權(quán)限

驅(qū)動(dòng)創(chuàng)建了一個(gè)新的設(shè)備節(jié)點(diǎn)，即使權(quán)限是777，android層也是沒有訪問權(quán)限的。

下面以一個(gè)/dev/wifi_bt節(jié)點(diǎn)為示范，讓此節(jié)點(diǎn)被用戶空間的system_server進(jìn)程訪問。

1. 編輯devicesoftwinner/astar-common/sepolicy/device.te，仿照這個(gè)文件里的寫法，定義一個(gè)dev_type類型的wifi_bt_device設(shè)備：

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節(jié)點(diǎn)聲明為第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，根據(jù)dmesg | grep avc允許system_server對(duì)wf_bt_device這個(gè)節(jié)點(diǎn)可讀可寫：

# 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;

其他進(jìn)程如需訪問/dev/wf_bt節(jié)點(diǎn)，依樣畫葫蘆，增加對(duì)wf_bt_device的權(quán)限即可。

作者：縹緲孤鴻影_love
原文鏈接：https://blog.csdn.net/tung214/java/article/details/72734086

至此，本篇已結(jié)束，如有不對(duì)的地方，歡迎您的建議與指正。同時(shí)期待您的關(guān)注，感謝您的閱讀，謝謝！

點(diǎn)個(gè)在看，方便您使用時(shí)快速查看！