2021.10.27

1. 问题澄清：
2. 河北联创项目联调支撑，新增挑战认证token认证接口；
3. 校招面试3人；
4. mcvideo赋能文档书写；
5. 支持SDS服务器版本返回空时默认为4.0版本，OTA参数增加；
6. X6版本验证

Android-SEAndroid权限问题指南

Google官网参考：https://source.android.google.cn/security/selinux/device-policy

前言

SEAndroid是在Android系统中基于SELinux推出的强制访问控制模型，来完善自主访问模型中只要取得root权限就可以为所欲为的情况。
SELinux是一种基于域-类型（domain-type）模型的强制访问控制（MAC）安全系统，其原则是任何进程想在SELinux系统中干任何事，都必须先在安全策略的配置文件中赋予权限。凡是没有在安全策略中配置的权限，进程就没有该项操作的权限。在SELinux出现之前，Linux的安全模型是DAC（DiscretionaryAccess Control），译为自主访问控制。其核心思想是进程理论上所拥有的权限与运行它的用户权限相同。比如，以root用户启动shell，那么shell就有root用户的权限，在Linux系统上能干任何事。这种管理显然比较松散。在SELinux中，如果需要访问资源，系统会先进行DAC检查，不通过则访问失败，然后再进行MAC权限检查。

为了方便调试，我们可以手动开启或关闭selinux:

• eng/userdebug版本中
  使用setenforce 命令进行设置:
  adb shell setenforce 0 //设置成permissive 模式
  adb shell setenforce 1 //设置成enforce 模式
  注意此方法重启后失效
• 在eng/userdebug/user 版本中
  使用getenforce 命令查询当前权限状态，如：
  adb shell getenforce

一.SELinux知识点分析

1.1 SEAndroid app分类和其他

SELinux(或SEAndroid)将app划分为主要三种类型(根据user不同，也有其他的domain类型)：
1.untrusted_app 第三方app，没有Android平台签名，没有system权限
2.platform_app 有android平台签名，没有system权限
3.system_app 有android平台签名和system权限
4.untrusted_app_25 第三方app，没有Android平台签名，没有system权限，其定义如下This file defines the rules for untrusted apps running with targetSdkVersion <= 25.
从上面划分，权限等级，理论上：untrusted_app < platform_app < system_app按照这个进行排序

property_contexts（系统属性）主要描述系统属性相关

1.2 seapp_contexts定义

system/sepolicy/seapp_contexts数据文件

isSystemServer=true domain=system_server
user=system seinfo=platform domain=system_app type=system_app_data_file
user=bluetooth seinfo=platform domain=bluetooth type=bluetooth_data_file
user=nfc seinfo=platform domain=nfc type=nfc_data_file
user=radio seinfo=platform domain=radio type=radio_data_file
user=shared_relro domain=shared_relro
user=shell seinfo=platform domain=shell type=shell_data_file
user=_isolated domain=isolated_app levelFrom=user
user=_app seinfo=platform domain=platform_app type=app_data_file levelFrom=user
user=_app domain=untrusted_app type=app_data_file levelFrom=user

从上面可以看出，domain和type由user和seinfo两个参数决定。
比如:
user=system seinfo=platform，domain才是system_app
user=_app，可以是untrusted_app或platform_app，如果seinfo=platform，则是platform_app。

1.3 user和seinfo判定方式

首先看user，user可以理解为UID，例如ps -Z结果如下：

u:r:system_app:s0              system    2414  1172  com.android.keychain
u:r:platform_app:s0            u0_a6     2439  1172  com.android.managedprovisioning
u:r:untrusted_app:s0           u0_a8     2460  1172  com.android.onetimeinitializer
u:r:system_app:s0              system    2480  1172  com.android.tv.settings
u:r:untrusted_app:s0           u0_a27    2504  1172  com.android.email
u:r:untrusted_app:s0           u0_a28    2523  1172  com.android.exchange
u:r:untrusted_app:s0           u0_a7     2567  1172  com.android.musicfx

第一列是SContext，第二列是UID，只要UID是system的基本都是system_app，反过来一样。
其他的U0_XXX要么属于platform_app或untrusted_app
seinfo由system/sepolicy/private/mac_permissions.xml决定，内容如下：

  <!-- Platform dev key in AOSP -->
    <signer signature="@PLATFORM" >
      <seinfo value="platform" />
    </signer>

 <!-- All other keys -->
    <default>
      <seinfo value="default" />
    </default>

即如果签名是platform，seinfo就是platform,其他的比如shared等，seinfo是default。
比如上面ps -Z的结果里面，OneTimeInitializer.apk是untrusted_app，ManagedProvisioning.apk是platform_app。
分别查看这两个app的Android.mk
packages\apps\OneTimeInitializer\Android.mk 没有定义LOCAL_CERTIFICATE，默认是shared
packages\apps\ManagedProvisioning\Android.mk 有定义LOCAL_CERTIFICATE := platform
因为ManagedProvisioning.apk有platform签名，所以seinfo是platform。

1.4 RBAC和constrain

由前文可知，*.te文件内部包含各种allow, type等语句，这些都是TEAC(type enforcement access control)，属于SELinux MAC中的核心组成部分。
在TEAC之上，SELinux还有一种基于Role的安全策略，也就是RBAC（role based access control）。
e.g.
constrain file write (u1 == u2 and r1 == r2)
这句话表示只有source和targe的user相同，并且role也相同，才允许write file

1.5 mlsconstrain语句

1.5.1.MLS约束

SELinux支持两个MLS约束语句：mlsconstrain 和mlsvalidatetrans。它们两个一起让我们可以指定可选的MLS访问强制规则，除了它们允许你基于安全上下文的安全级别表示约束外，这两个语句在无MLS的副本中是等同的。你可能只能在开启了MLS特性的策略中使用MLS约束，你可以在任何策略类型中使用无MLS的约束语句。

1.5.2.mlsconstrain语句

mlsconstrain语句是以constrain语句为基础的，我们可以使用第7章"约束"中讨论的constrain语句的所有语法，为了描述基于源（l1 和 h1）和目标（l2 和 H2）的低和高安全级别的约束，mlsconstrain语句添加了新的关键词。下面是mlsconstrain语句的完整语法：

1.6 小技巧

使用allow语句的时候，可以使用下面的一些小技巧来简化命令书写；
” ~ ”号，表示除了” ~ ”以外；
”-”号，表示去除某项内容；
”*”号，表示所有内容

1.7 SELinux 策略构建和客制化

在Android8.0中，SELinux策略分离成平台（platform）和非平台（non-platform）两部分，而平台策略为了给非平台作者导出特定的类型和属性，又分为平台私有（platform private）和平台公有（platform public）部分。

1.7.1.平台公有策略（platform public seoplicy）

平台共有策略全部定义在/system/sepolicy/public下，public下的type和attribute可以被non-platform中的策略所使用，也就是说，设备制造商的sepolicy作者在non-platform下可以对platform public sepolicy的策略进行扩展。

1.7.2.平台私有策略（platform private seoplicy）

与公有策略相反，被声明为私有策略的type或attribute对non-platform的策略作者是不可见的，这里有些费解，我们举例来说，这里以8.0版本的aosp源代码中的/system/sepolicy/private/目录下的atrace.te文件为例；

• 8.0版本的aosp中的/system/sepolicy/private/file_contexts定义了“/system/bin/atrace u:object_r:atrace_exec:s0”
• 然后在/system/sepolicy/private/atrace.te中定义atrace相关的规则；
• 我们在device/qcom/sepolicy/common目录下新增一个atrace.te文件，并添加规则 "allow atrace sdcardfs:file read;"
  当我们make进行编译时会在校验的时候失败，提示我们“device/qcom/sepolicy/common/atrace.te:2:ERROR 'unknown type atrace' at token ';' on line 23355”，那么也就是说private策略中的type和attribute对我们是不可见的。

1.7.3.平台私有映射

映射主要针对旧版本的映射，应用比较少，这里不作研究；

二、实际案例分析

Android 5.x开始，引入了非常严格的SELinux权限管理机制，我们经常会遇到因为SELinux权限问题造成的各种avc denied困扰。
本文结合具体案例，讲解如何根据log来快速解决90%的权限问题。
遇到权限问题，在logcat或者kernel的log中一定会打印avc denied提示缺少什么权限，

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

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

下面给出几个具体案例：

2.1.案例分析一

分析过程：

• 缺少什么权限： { 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.2.案例分析二

解决方法 ：platform_app.te

allow  platform_app  app_data_file:file  execute;

2.3.案例分析三

解决方法 ：engsetmacaddr.te

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

2.4.案例分析四

解决方法 ：sdcardd.te

allow  ****sdcardd  system_data_file:dir  read;  或者****
allow  ****sdcardd  system_data_file:dir  rw_dir_perms****

(rw_dir_perms包含read write，可以参考system/sepolicy/public/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为后缀的文件都在system/sepolicy/或者device/softwinner/xxxx-commm/sepolicy/下，修改之后，都要重刷boot.img。(重点，在Android7和Android 8上面.te后缀的文件都在system/sepolicy或者device/softwinner/xxxx-commm/sepolicy/下面这个需要注意，且此时需要烧录system.img或者vendor.img)

补充说明：

1. 有时候avc denied的log不是一次性显示所有问题，要等你解决一个权限问题之后，才会提示另外一个权限问题。比如提示确实某个目录的read权限，你加入read之后，再显示缺少write权限，要你一次次一次试，一次一次加。这时你可以简单粗暴写个rw_dir_perms，这个权限包含了{open search write ...}等等很多权限。可以查看system/sepolicy/public/global_macros来了解更多权限声明(相对应的在Android 7和Android 8对应的就是system/sepolicy/public/global_macros，如果有定义的话)；
2. 要加入的权限很多时，可以用中括号，比如

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

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

2.5.后话

有一个开源的工具audit2allow，没有具体使用过，网上流程如下而对于如何解决该类权限问题，一般的做法是，缺少什么就补什么，先介绍一下简化方法：
简化方法：

• 1、 提取所有的avc LOG. 如 adb shell "cat /proc/kmsg | grepavc" > avc_log.txt
• 2、 使用 audit2allow tool 直接生成policy. audit2allow -i avc_log.txt 即可自动输出生成的policy

还是建议不要使用这个工具，最好自己手动编写相关的策略。因为上面这个工具知识机械的转化，不一定符合具体的要求

三、特殊案例分析

image.png

3.1.android系统增加native本地服务

上述就以E/SELinux ( 261): avc: denied { add } for service=PaxApiService scontext=u:r:init:s0 tcontext=u:object_r:default_android_service:s0 tclass=service_manager
为例说明，这个错误主要是添加ServiceManager添加Native Service没有配置SELinux权限导致，由于现在SELinux的启用是在展讯平台，所以这里就以以展讯平台来说明,步骤如下：
1.vi编辑device/sprd/sharkle/common/plat_sepolicy/private/service_contexts在其最后添加

#add for PaxApiService
PaxApiService                     u:object_r:PaxApiService_service:s0

2.vi编辑device/sprd/sharkle/common/plat_sepolicy/public/service.te在其最后添加

#type for PaxApiService
type PaxApiService_service, service_manager_type;

3.vi编辑device/sprd/sharkle/common/sepolicy/system_server.te在其最后添加

#add for PaxApiService
allow system_server PaxApiService_service:service_manager { add find };

4.vi编辑device/sprd/sharkle/common/sepolicy/platform_app.te在其最后添加

#add for PaxService
allow platform_app PaxApiService_service:service_manager { find };

5.最后根据在使用中报什么avc的错误，然后再按照规则添加相关规则

3.2.android系统增加java层服务

上述就以E/SELinux ( 261): avc: denied { add } for service=PaxSystemUtil scontext=u:r:system_app:s0 tcontext=u:object_r:default_android_service:s0 tclass=service_manager，这个错误主要是添加ServiceManager添加Native Service没有配置SELinux权限导致，由于现在SELinux的启用是在展讯平台，所以这里就以以展讯平台来说明,步骤如下：
1.vi编辑device/sprd/sharkle/common/plat_sepolicy/private/service_contexts在其最后添加

#add for PaxSystemUtil
PaxSystemUtil  u:object_r:PaxSystemUtil_service:s0

2.vi编辑device/sprd/sharkle/common/plat_sepolicy/public/service.te在其最后添加

#type for PaxSystemUtil
type PaxSystemUtil_service, service_manager_type;

3.vi编辑device/sprd/sharkle/common/sepolicy/system_server.te在其最后添加

#add for PaxSystemUtil
allow system_server PaxSystemUtil_service:service_manager { add find };

4.vi编辑device/sprd/sharkle/common/sepolicy/platform_app.te在其最后添加

#add for PaxSystemUtil
allow platform_app PaxSystemUtil_service:service_manager { find };

四、新增加权限文件

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

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

以写mac地址的setmacaddr执行文件为例（这个执行档android原生不存在，自行添加的）,这个案例可以扩展到我们的paxservice添加在init脚本自运行启动的的案例,且由于paxservice是运行在/system/bin里面情况更加的特殊

1. 在device/sprd/sharkle/common/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
/system/bin/paxservice  u:object_r:paxservice_exec:s0

指定setmacaddr和paxservice的路径，并指定一个名字，一定要以_exec结尾

2.参考其他文件在device/sprd/sharkle/common/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缺什么一步一步补什么来的。

3.1针对paxservice在device/sprd/sharkle/common/plat_sepolicy/private/ 创建paxservice.te文件，内容如下：

typeattribute paxservice coredomain;
init_daemon_domain(paxservice)

3.2在device/sprd/sharkle/common/plat_sepolicy/public创建paxservice.te文件，添加如下内容：

type paxservice, domain, mlstrustedsubject;
type paxservice_exec, exec_type,file_type;

3.3在device/sprd/sharkle/common/sepolicy/创建paxservice.te文件，添加如下内容：

allow paxservice servicemanager:binder {  call };   #call "dumpsys"
allow paxservice system_server:binder {  call };   #call "dumpsys"
allow servicemanager paxservice:dir { search };
allow servicemanager paxservice:file { read };

4.2.新设备节点增加访问权限

驱动创建了一个新的设备节点，即使权限是777，android层也是没有访问权限的。

下面以一个/dev/wifi_bt节点为示范，让此节点被用户空间的system_server进程访问。

1. 由于我们的SELinux的启动是在展讯平台上面，所以编辑编辑device/sprd/sharkle/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，将/dev/wf_bt节点声明为第1步定义的wf_bt_device:

/dev/block/by-name/misc         u:object_r:misc_block_device:0
/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的权限即可。

4.3.常见错误

01-02 10:01:37.596   238   300 W YLOG    : [01-02 10:01:37.596] ylog<critical> android cacheline write wrong 4317 -> 1008

01-02 10:01:37.598   217   217 E SELinux : avc:  denied  { add } for service=PaxSystemUtil pid=4311 uid=1000 scontext=u:r:system_app:s0 tcontext=u:object_r:PaxSystemUtil_service:s0 tclass=service_manager permissive=0

01-02 10:01:37.599   217   217 E ServiceManager: add_service('PaxSystemUtil',91) uid=1000 - PERMISSION DENIED

libsepol.report_failure: neverallow on line 554 of system/sepolicy/private/system_server.te (or line 31144 of policy.conf) violated by allow system_app SettingsManagerService_service:service_manager { add };

Caused by: java.lang.RuntimeException: failed to set system property

01-01 11:11:39.434 E/SELinux (  218): avc:  denied  { add } for service=PaxApiService pid=2021 uid=0 scontext=u:r:paxservice:s0 tcontext=u:object_r:PaxApiService_service:s0 tclass=service_manager permissive=0

01-01 11:11:39.435 E/ServiceManager(  218): add_service('PaxApiService',92) uid=0 - PERMISSION DENIED

调试技巧：

由于SELinux的问题，而且由于adb连接比较慢，必须借串口抓相关的日志，现在通过属性控制paxsservice的启动

on post-fs-data

on property:pax.ctrl.paxservice=1
     start paxservice

service paxservice /system/bin/paxservice

    class core
    user root
    group root
    disabled

4.4 进程无法访问直接访问data 目录的说明

[Description]
[SELinux] Android M 版本后进程无法访问直接访问data 目录的说明

[Keyword]
SELinux, data, 拒绝, permission denied, 安全 , security

[Version]
android >= 6.0

[Solution]
Google 在android M 版本后, 通过SELinux 的neverallow 语法强制性限制了普通进程访问data 目录的权限. 严禁除init system_server installd system_app 之外的其他进程直接操作/data 目录比如在data 目录下面创建文件，写文件，重命名文件等等.

有很多客户都会在data 目录下创建文件, 保存资讯, 在M 版本上这个操作会被SELinux 直接拦截下来，并且没法直接添加访问system_data_file 的权限, 需要按下面的流程操作。
(1). 在init.rc 或者 其他的init.xxx.rc 的on post-fs-data 段 添加:

mkdir /data/xxxx 0770 root system

(2). 在/device/mediatek/common/sepolicy/file.te 里面添加：

type xxxx_data_file, file_type, data_file_type;

(3). /device/mediatek/common/sepolicy/file_contexts 里面添加：

/data/xxxx(/.*)? u:object_r:xxxx_data_file:s0

(4). 给你的进程添加权限, 比如你的进程的SELinux domain 是 yyyy

allow yyyy xxxx_data_file:dir create dir_perms;
allow yyyy xxxx_data_file:file create_file_perms;

这样你才能绕过Google 的设置. 这个xxxx 目录随你定义.
下面是一个完整的添加过程：

出于历史原因，项目需要对/data/resource目录下面的目录文件进行访问，在没有开启SELinux检测之前，只需要对目录开启相应的读写访问权限即可，可是开启SELinux之后就不同了。通过SELinux 的neverallow 语法强制性限制了普通进程访问data 目录的权限. 严禁除init system_server installd system_app 之外的其他进程直接操作/data 目录比如在data 目录下面创建文件，写文件，重命名文件等等.在O版本上面有很多客户都会在data 目录下创建文件, 保存资讯, 这个操作会被SELinux 直接拦截下来，并且没法直接添加访问system_data_file 和data_file_type的权限, 需要按下面的流程操作。

1.在system/sepolicy/public/file.te和system/sepolicy/prebuilts/api/26.0/public/file.te添加

type paxdroid_share_file, file_type, data_file_type, mlstrustedobject;#其中mlstrustedobject这个很重要后面会重点强调

2.system/sepolicy/prebuilts/api/26.0/private/file_contexts和system/sepolicy/private/file_contexts添加

/data/resource(/.*)? u:object_r:paxdroid_share_file:s0

3.在system/sepolicy/prebuilts/api/26.0/private/app_neverallows.te和system/seplicy/private/app_neverallows.te下面做如下修改

#neverallow all_untrusted_apps file_type:file link;

#不允许all_untrusted_apps对file_type进行访问，除开paxdroid_share_file

neverallow {all_untrusted_apps} {file_type -paxdroid_share_file}:file link;

#同上

neverallow { all_untrusted_apps -mediaprovider } {

fs_type

-fuse # sdcard

-sdcardfs # sdcard

-vfat

file_type

-app_data_file # The apps sandbox itself

-media_rw_data_file # Internal storage. Known that apps can

# leave artfacts here after uninstall.

-user_profile_data_file # Access to profile files

userdebug_or_eng(`

-method_trace_data_file # only on ro.debuggable=1

-coredump_file # userdebug/eng only

')

-paxdroid_share_file

}:dir_file_class_set { create unlink };

4.然后在device/sprd/sharkle/common/sepolicy/paxdroid_share_file.te增加该文件，然后增加相关的权限

allow system_app paxdroid_share_file:file {create write setattr relabelfrom relabelto append unlink link rename open getattr read lock };

allow untrusted_app paxdroid_share_file:dir { search write create add_name remove_name setattr relabelfrom relabelto append unlink link rename getattr};

allow untrusted_app paxdroid_share_file:file {create write setattr relabelfrom relabelto append unlink link rename open getattr read lock };

allow untrusted_app_25 paxdroid_share_file:dir {search write create add_name remove_name setattr relabelfrom relabelto append unlink link rename getattr};

allow untrusted_app_25 paxdroid_share_file:file {create write setattr relabelfrom relabelto append unlink link rename open getattr read lock };

allow platform_app paxdroid_share_file:dir { search write create add_name remove_name setattr relabelfrom relabelto append unlink link rename getattr};

allow platform_app paxdroid_share_file:file { create write setattr relabelfrom relabelto append rename open getattr read lock };

allow paxservice paxdroid_share_file:dir { search write create add_name remove_name setattr relabelfrom relabelto append unlink link rename getattr};

allow paxservice paxdroid_share_file:file { create write setattr relabelfrom relabelto append rename open getattr read lock };

5..重点来了，后面发现怎么修改都untrusted_app_25都不能对该文件进行修改，后面发现了是由于mls规则导致,错误类似如下：

type=1400 avc: denied { connectto } for pid=6884 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:r:bluetooth:s0 tclass=unix_stream_socket permissive=0

在system/sepolicy/private/mls存在如下的规则，所以就需要对paxdroid_share_file加上mlstrustedobject才可以

mlsconstrain dir { write setattr rename add_name remove_name reparent rmdir }

(t2 == app_data_file or l1 eq l2 or t1 == mlstrustedsubject or t2 == mlstrustedobject);

mlsconstrain { file lnk_file sock_file chr_file blk_file } { write setattr append unlink link rename }

(t2 == app_data_file or l1 eq l2 or t1 == mlstrustedsubject or t2 == mlstrustedobject);

具体可以参考如下的博客文章：SELinux中的MLC规则约束

4.5.添加属性访问权限

由于历史原因，前面的开发过程中使用了很多的property属性，但是由于现在平台开启了SELinux的控制，在移植以前代码的过程中经常会出现Caused by: java.lang.RuntimeException: failed to set system property的错误，这就需要我们制定相关的策略来满足对特定属性的访问需求，具体的制定流程如下：

1.在device/sprd/sharkle/common/plat_sepolicy/private/property_contexts最后添加如下定义

# add property contexts for pax

pax.ctrl.                       u:object_r:pax_ctrl_prop:s0
pax.soc.                        u:object_r:pax_ctrl_prop:s0
com.pax.                        u:object_r:pax_ctrl_prop:s0  
pax.sp.                         u:object_r:pax_ctrl_prop:s0
persist.pax.                    u:object_r:pax_ctrl_prop:s0
ro.epay.serial                  u:object_r:pax_ctrl_prop:s0
ro.ums.manufacturer.info        u:object_r:pax_ctrl_prop:s0
pax.sys.                        u:object_r:pax_ctrl_prop:s0
pax.sdk.                        u:object_r:pax_ctrl_prop:s0
pax.persist.                    u:object_r:pax_ctrl_prop:s0
pax.param.                      u:object_r:pax_ctrl_prop:s0
ro.pax.                         u:object_r:pax_ctrl_prop:s0

2.在device/sprd/sharkle/common/plat_sepolicy/public/property.te最后添加如下的定义，具体如下

#add for pax.ctrl  property

type pax_ctrl_prop, property_type;

3.最后就是对定义的属性访问，添加相应的访问规则了，由于太多就不一一表述出来，可以参见下面的截图

4.6 增加NTFS格式外接U盘访问权限

由于Android原生只支持VFAT格式的U盘挂载，现在需要增加NTFS格式的U盘挂载，今天的重点不是怎么增加NTFS格式的支持，重点是怎么在SELinux增加NTFS格式U盘的挂载。原来以为非常的简单只需要参照VFAT格式的做就ok了，但是发现就是一个坑根本行不懂，尝试了很多办法，最好通过内核打印发现了如下的信息：

sdcardfs: mounted on top of /mnt/media_rw/exsdcard0 type fuseblk

sdcardfs: mounted on top of /mnt/media_rw/exsdcard0 type vfat

驱动的小哥哥根本挂载的不是把U盘挂载称为utfs格式的而是fuseblk类型的，所以发现了这个点问题就迎刃而解了，只需要参照VFAT格式的添加SELinux权限就ok了，这里需要注意地是虚拟文件系统的安全上下文和关键词genfscon。