[Android L]SEAndroid开放设备文件结点权限(读或写)方法(涵盖常

温馨提示

建议你先了解一下上一篇博文([Android L]SEAndroid增强Androd安全性背景概要及带来的影响)所讲的内容，先对SEAndroid窥个全貌，然后再继续本节内容。

1 现象描述

基于Android L版本源码环境进行开发时，根据项目需求，APP层需要操作sys/xxx 或 proc/xxx下面的文件结点，但是会报出以下权限异常，无法直接操作这些结点

LedLightFileUtil( 4671): java.io.FileNotFoundException: /sys/class/leds/green/brightness: open failed: EACCES (Permission denied)

LedLightFileUtil( 4671): at libcore.io.IoBridge.open(IoBridge.java:456)

LedLightFileUtil( 4671): at java.io.FileOutputStream.<init>(FileOutputStream.java:87)

LedLightFileUtil( 4671): at java.io.FileOutputStream.<init>(FileOutputStream.java:127)

LedLightFileUtil( 4671): at java.io.FileOutputStream.<init>(FileOutputStream.java:116)

2 问题原因

自Android L版本，Google对源码环境普遍启用SELinux安全访问机制，APP及framework层默认情况下再无权限访问设备节点如(sys/xxx,proc/xxx)

3 解决方法

下面以三种常用操作角度阐述为system app进程或system server进程开放权限的方法

1) SEAndroid 为sys设备文件结点开放访问(读或写)权限的方法(如：/sys/class/leds/green/brightness)

2)SEAndroid 为proc设备文件结点开放访问(读或写)权限的方法(如：/proc/touchscreen_feature/gesture_data)

3)SEAndroid 为SystemProperties的自定义属性开放set(写)权限的方法

3.1SEAndroid 为sys设备文件结点开放访问(读或写)权限的方法(如：/sys/class/leds/green/brightness)

以操作LED灯的设备文件节点为例进行说明，如绿灯:/sys/class/leds/green/brightness，为APP层system app进程开放该节点访问权限(读或写)

绿灯:

/sys/class/leds/green/brightness //快捷方式

/sys/devices/soc.0/gpio-leds.66/leds/green/brightness //实际节点

PS:默认是在external/sepolicy目录下面，但是MTK平台和QCOM平台都创建了自己管理SELinux policy的目录：

MTK:alps/device/mediatek/common/sepolicy

QCOM:android/device/qcom/sepolicy/common

所以建议你在其平台的相应目录下面去操作，下面以QCOM平台为例，MTK平台配置步骤方法是一样的(alps/device/mediatek/common/sepolicy)

3.1.1 在android/device/qcom/sepolicy/common/file.te,定义selinux type:sysfs_wingtk_leds,如下:

typesysfs_wingtk_leds, fs_type, sysfs_type;

3.1.2 在android/device/qcom/sepolicy/common/file_contexts,绑定sysfs_wingtk_leds到对应的实际节点,注意是实际节点

/sys/devices/soc.0/gpio-leds.66/leds/green/brightnessu:object_r:sysfs_wingtk_leds:s0

PS:可以把/sys/class/leds/green/brightness也声明下,该句不是必须的:

/sys/class/leds/green/brightnessu:object_r:sysfs_wingtk_leds:s0

汇总:file_contexts的修改如下:

/sys/class/leds/green/brightness u:object_r:sysfs_wingtk_leds:s0

/sys/devices/soc.0/gpio-leds.66/leds/green/brightness u:object_r:sysfs_wingtk_leds:s0

3.1.3 在android/device/qcom/sepolicy/common/system_app.te,申请权限:

allow system_appsysfs_wingtk_leds:file rw_file_perms;

PS:也可以为其他process申请相关的权限,如:system_server,在android/device/qcom/sepolicy/common/system_server.te

allow system_server sysfs_wingtk_leds:file rw_file_perms;

PS:配置第2步的实际节点时,怎么获取实际节点,方法如下:

root@K31-t7:/sys/class/leds #ll -Z

lrwxrwxrwx root root u:object_r:sysfs:s0 flashlight -> ../../devices/soc.0/flashlight.64/leds/flashlight

lrwxrwxrwx root root u:object_r:sysfs:s0 green -> ../../devices/soc.0/gpio-leds.66/leds/green

lrwxrwxrwx root root u:object_r:sysfs:s0 lcd-backlight -> ../../devices/soc.0/1a00000.qcom,mdss_mdp/qcom,mdss_fb_primary.124/leds/lcd-backlight

lrwxrwxrwx root root u:object_r:sysfs:s0 mmc0:: -> ../../devices/soc.0/7824900.sdhci/leds/mmc0::

lrwxrwxrwx root root u:object_r:sysfs:s0 mmc1:: -> ../../devices/soc.0/7864900.sdhci/leds/mmc1::

lrwxrwxrwx root root u:object_r:sysfs:s0 red -> ../../devices/soc.0/gpio-leds.66/leds/red

lrwxrwxrwx root root u:object_r:sysfs:s0 torch-light0 -> ../../devices/soc.0/qcom,camera-led-flash.65/leds/torch-light0

root@K31-t7:/sys/class/leds #

通过ll -Z命令就可以查到。

3.1.4 在AndroidManifest.xml,配置:android:sharedUserId="android.uid.system",该步时必须的,因为第三步是:

allow system_appsysfs_wingtk_leds:file rw_file_perms;//仅允许system_app进程访问.

经过以上四步,APP层就可以正常读写:/sys/class/leds/green/brightness

为了更好地控制访问权限,如果存在APP层和framework层都要访问某个设备节点,笔者认为最好以此模式来访问设备节点,即不让system_app进程访问,仅仅允许system_server进程来访问,如下:

allow system_server sysfs_wingtk_leds:file rw_file_perms;

缺点:需要在framework层添加随系统启动的service,增加代码量

优点:1.可以自由控制哪些应用可以访问,哪些应用禁止访问已经开放的设备节点,可以更好的保护安全问题

2.framework层和APP层都可以访问该设备节点.不用再另外进行权限申请

3.2SEAndroid 为proc设备文件结点开放访问(读或写)权限的方法(如：/proc/touchscreen_feature/gesture_data)，以MTK平台为例

修改记录

正如我总是意犹未尽的想起你。