[Android L]SEAndroid开放设备文件结点权限(读或写)方法(涵盖常用操作:sys/xxx、proc/xxx、SystemProperties)

温馨提示

建议你先了解一下上一篇博文([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.1 SEAndroid 为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,如下:

type sysfs_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/brightness u:object_r:sysfs_wingtk_leds:s0

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

/sys/class/leds/green/brightness u: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_app sysfs_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步的实际节点时,怎么获取实际节点,方法如下:

[email protected]:/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

[email protected]:/sys/class/leds #

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

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

allow system_app sysfs_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.2 SEAndroid 为proc设备文件结点开放访问(读或写)权限的方法(如:/proc/touchscreen_feature/gesture_data),以MTK平台为例

修改记录

细节展开

3.2.1 在alps/mediatek/common/sepolicy/file.te 定义selinux type: proc_quick_gesture,如下:

type proc_quick_gesture, fs_type;

3.2.2 在 alps/mediatek/common/sepolicy/genfs_contexts,绑定proc_quick_gesture到对应的实际节点

genfscon proc /touchscreen_feature/gesture_data   u:object_r:proc_quick_gesture:s0

3.2.3 在alps/mediatek/common/sepolicy/common/system_app.te,申请权限

allow system_app proc_quick_gesture:file rw_file_perms;

3.2.4 在AndroidManifest.xml,配置:android:sharedUserId="android.uid.system"

经过以上4步,system_app进程就具备权限(读或写)访问/proc/touchscreen_feature/gesture_data等节点啦

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

问题描述

SystemProperties对自定义属性没有写权限,即set时提示没有权限,导致写不成功

解决方法

以"persist.backgrounddata.enable"为例介绍开放属性权限方法

以QCOM平台为例

3.3.1 android/device/qcom/sepolicy/common/property.te

type persist_backgrounddata_prop, property_type;

3.3.2 android/device/qcom/sepolicy/common/property_contexts

persist.backgrounddata.enable u:object_r:persist_backgrounddata_prop:s0

3.3.3 android/device/qcom/sepolicy/common/system_app.te,为system_app进程开放权限

allow system_app persist_backgrounddata_prop:property_service set;

3.3.4 在AndroidManifest.xml,配置:android:sharedUserId="android.uid.system"

经过以上4步,就可以使用SystemProperties.set("persist.backgrounddata.enable"", xx)设置属性了。

延伸阅读

如果通过以上步骤正确配置之后,你仍没有权限读写sys或proc节点,是不是DAN都碎了。再告诉你下,你需要到init.rc里面配置: chown system system 文件结点,然后chmod下文件结点。两个平台配置路径,项目不同略有差异

MTK:alps/device/mediatek/mt6735/init.mt6735.rc

QCOM:xx/xx/init.target.rc

转自:http://blog.csdn.net/yelangjueqi/article/details/46761987

时间: 11-10

[Android L]SEAndroid开放设备文件结点权限(读或写)方法(涵盖常用操作:sys/xxx、proc/xxx、SystemProperties)的相关文章

[Android L]SEAndroid增强Androd安全性背景概要及带来的影响

1  SEAndroid背景 Android对于操作系统安全性方面的增强一直沿用Linux内核所提供的MAC强制访问控制套件SELinux,对权限进行了更为深度的管理,有效地控制着进程对资源的访问.2012年才问世的SE Android将SELinux移植到Android平台上,以降低恶意应用程序攻击带来的损害,提供Android系统的防御能力. SE Android(Secutity-Enhanced Android)是Android与SE Linux的结合,由美国NSA在2012年推出的An

Android [Android L]SEAndroid增强Androd安全性背景概要及带来的影响

1  SEAndroid背景 Android对于操作系统安全性方面的增强一直沿用Linux内核所提供的MAC强制访问控制套件SELinux,对权限进行了更为深度的管理,有效地控制着进程对资源的访问.2012年才问世的SE Android将SELinux移植到Android平台上,以降低恶意应用程序攻击带来的损害,提供Android系统的防御能力. SE Android(Secutity-Enhanced Android)是Android与SE Linux的结合,由美国NSA在2012年推出的An

class_create(),device_create自动创建设备文件结点

class_create(),device_create自动创建设备文件结点 从linux 内核2.6的某个版本之后,devfs不复存在,udev成为devfs的替代.相比devfs,udev有很多优势,在此就不罗嗦了,提醒一 点,udev是应用层的东东,不要试图在内核的配置选项里找到它;加入对udev的支持很简单,以作者所写的一个字符设备驱动为例,在驱动初始化的代码里调用class_create为该设备创建一个class,再为每个设备调用 class_device_create创建对应的设备.

自动创建字符设备驱动的设备文件结点

(1)什么是udev?应用层的一个应用程序(2)内核驱动和应用层udev之间有一套信息传输机制(netlink协议)(3)应用层启用udev,内核驱动中使用相应接口(4)驱动注册和注销时信息会被传给udev,由udev在应用层进行设备文件的创建和删除5.3.7.3.内核驱动设备类相关函数(驱动接口)(1)class_create(2)device_create 首先要注册字符设备 创建一个设备类   在/sys/class下会有一个adb文件 创建一个dev,    insmod时  在/dev

Python open()函数文件打开、读、写操作详解

一.Python open()函数文件打开操作 打开文件会用到open函数,标准的python打开文件语法如下:open(name[,mode[,buffering]])open函数的文件名是必须的,而模式和缓冲参数都是可选的.比如说有个a.txt的文本文件,存放在c:\text下,那么你要打开它可以这样操作:>>>x = open(r 'c:\text\a.txt')用读的模式打开这个路径下的对应文本文件,如果要打开对像不存在,程序会报错. 二.open()函数文件打开模式参数常用值有

C#文件流的读与写

工作中遇到了文件的跨平台传送 运用了文件流 而且将计算机上的文件读取到程序内存里 反之将内存里的数据以文件的形式保存 都是比较常用的 在这里做一个简单的应用示例. 1 将内存数据“写”到计算机的文件里 const string path = @"D:\text.txt";//保存文件的路径 string content = "文件内容!!!!";//定义内存里的数据 byte[] bytes = Encoding.Default.GetBytes(content);

class_create(),device_create自动创建设备文件结点【转】

本文参考来自CSDN博客,转载请标明出处:http://blog.csdn.net/zhenwenxian/archive/2010/03/28/5424434.aspx 本文转自:http://www.cnblogs.com/hnrainll/archive/2011/06/24/2088576.html 从linux 内核2.6的某个版本之后,devfs不复存在,udev成为devfs的替代.相比devfs,udev有很多优势,在此就不罗嗦了,提醒一 点,udev是应用层的东东,不要试图在内

Android 文件的可读可写

文件流形式的保存,获取: 设立文件的私有,可读,可写,公开: 效果图: /data/data中文件夹: 新建一个项目测试文件: 得到data/data,查看文件的特性:

C# 大文件复制边读边写

using (FileStream fsRead = new FileStream(@"D:\Names.txt", FileMode.Open)) { using (FileStream fsWrite = new FileStream(@"d:\temp.txt", FileMode.Create)) { byte[] arr = new byte[200]; //记录到底读取了多少字节的数据 int count = 0; while (fsRead.Posit