Android SELinux avc dennied权限问题解决方法

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的权限便可。