Android 6.0打开串口返回-1问题

转载：http://blog.csdn.net/li7032/article/details/75095384

Android 6.0打开串口返回-1问题

type=1400 audit(0.0:17): avc: denied { read write } for name="ttyS2" dev="tmpfs" ino=4332 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:rf_ttys2_dev:s0 tclass=chr_file permissive=0

 

分析过程：

缺少什么权限： {read write }权限，

谁缺少权限： scontext=u:r: untrusted_app:s0，

对哪个文件缺少权限：tcontext=u:object_r: rf_ttys2_dev

什么类型的文件： tclass= chr_file

解决方法：untrusted_app.te

allow untrusted_apprf_ttys2_dev: chr_file{ search write add_name create};

 

参考文档：

一、

android 5.x开始，引入了非常严格的selinux权限管理机制，我们经常会遇到因为selinux权限问题造成的各种avc denied困扰。

 

本文结合具体案例，讲解如何根据log来快速解决90%的权限问题。

遇到权限问题，在logcat或者kernel的log中一定会打印avc denied提示缺少什么权限，

Command：

cat /proc/kmsg | grep avc 或 dmesg | grep avc

解决原则是：缺什么补什么，一步一步补到没有avc denied为止。

 

下面给出四个案例：

 

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_filepermissive=0

 

分析过程：

缺少什么权限： { write }权限，

谁缺少权限： scontext=u:r:kernel:s0，

对哪个文件缺少权限：tcontext=u:object_r:block_device

什么类型的文件： tclass=blk_file

 

解决方法：kernel.te

allow kernel block_device:blk_file write;

 

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

 

解决方法 ：platform_app.te

allow  platform_app  app_data_file:file execute;

 

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;

 

 

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个为例

允许某个scontext对某个tcontext拥有某个权限

我们的log重新排列一下，

scontext=u:r:sdcardd

tcontext=u:object_r:system_data_file:s0

tclass=dir

avc: denied { read }

 

得到万能套用公式如下：

在scontext所指的te文件中加入类似如下内容：

 

以上以.te为后缀的文件都在external/sepolicy/或者device/softwinner/xxxx-commm/sepolicy/下，修改之后，都要重刷boot.img。

 

补充说明：

1. 有时候avc denied的log不是一次性显示所有问题，要等你解决一个权限问题之后，才会提示另外一个权限问题。

比如提示确实某个目录的read权限，你加入read之后，再显示缺少write权限，

要你一次次一次试，一次一次加。这时你可以简单粗暴写个rw_dir_perms，这个权限包含了{open search write ...}等等很多权限。

可以查看external/sepolicy/global_macros来了解更多权限声明；

 

2. 要加入的权限很多时，可以用中括号，比如

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

 

3. 遇到问题不确定是否由于selinux问题造成，可先在adb shell 下，输入setenforce 0，让selinux失效，看是否问题还出现。

以此可以澄清是非selinux造成的问题。

 

二、

以上基本是对已经存在的进程增加权限，但对第三方进程改如何新增一个全新的te文件并赋予权限呢？

以写mac地址的setmacaddr执行文件为例（这个执行档android原生不存在，自行添加的）：

 

1. 在external/sepolicy/file_contexts中，参考其他进程声明一个：

/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的路径，并指定一个名字，一定要以_exec结尾

 

2.参考其他文件在external/sepolicy/ 创建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缺什么一步一步补什么来的。

 

转载自：http://blog.csdn.net/lushengchu_luis/article/details/52775740

android6.0第三方app如何打开串口

转载 2016年10月10日 11:00:19

• 3003

折腾了一天，用audit2allow工具解析avc错误，把所有的权限都加上了，还是不行，一直有以下提示：

[html] view plain copy

1. 01-06 23:47:28.170  1932  1932 W port_api.sample: type=1400 audit(0.0:59): avc: denied { write } for name="ttyS0" dev="tmpfs" ino=4864 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:serial_device:s0 tclass=chr_file permissive=0  

无意中看到网上这篇文章，在device.te加入type serial_device, dev_type, mlstrustedobject;这一行，问题迎刃而解，原文如下，就不标记出处了，因为我是在一个满是成人弹幕广告的网站上搜到的，嘿嘿。

第三方签名APP，在SElinux下，如何获得对一个内核节点的访问权限

 

在android6.0中，出于安全考虑，不允许第三方签名的app被分配mlstrustedsubject：

在external/sepolicy/untrusted_app.te文件中：

# Do not allow untrusted_app to be assignedmlstrustedsubject.
# This would undermine the per-user isolation model being
# enforced via levelFrom=user in seapp_contexts and the mls
# constraints.  As there is no direct way tospecify a neverallow
# on attribute assignment, this relies on the fact that fork
# permission only makes sense within a domain (hence should
# never be granted to any other domain withinmlstrustedsubject)
# and untrusted_app is allowed fork permission to itself.
neverallow untrusted_app mlstrustedsubject:process fork;

所以在使用第三方签名app时，希望第三方签名app某个进程能够对内核节点进行操作，可按如下修改：

1.在device/sprd/scx20/common/sepolicy/file_contexts 文件中添加：
/dev/abc u:object_r:abc_device:s0 
2.在device/sprd/scx20/common/sepolicy/device.te 文件中添加：
type abc_device, dev_type, mlstrustedobject;

3.在device/sprd/scx20/common/sepolicy/untrusted_app.te 文件中添加：
allow untrusted_app adc_device:chr_fileoperate;

operate为赋予的权限。

注：

mlstrustedsubject：这一attribute包含了所有能越过MLS检查的主体domain。

mlstrustedobject：这一attribute包含了所有能越过MLS检查的客体type。