如果怀疑是sepolicy权限导致的问题，首先需要确认是否真的是权限导致的。

确认方法是：关闭SELinux，查看问题是否存在。

关闭SELinux的方法：

1、运行时关闭，重启失效：

adb shell setenforce 0

2、开机阶段关闭：

1）修改kernel cmdline：

androidboot.selinux=permissive

2）修改init代码：

selinux_is_enforcing函数返回false

SELinux常见问题-denied log

在kernel log、event log或main log中，搜索denied 关键字：

08-19 14:34:40.044160 1 1 E [ 27.054100].(1)[1:init]init: avc: denied { set } for property=sys.oppo.reboot pid=1608 uid=10013 gid=10013 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:system_prop:s0 tclass=property_service permissive=0

1、查看denied信息，显示platform_app domain无法对安全上下文u:object_r:system_prop:s0的属性进行设置操作；

2、在system/sepolicy/中找到platform_app domain的定义，一般在platform_app.te中即(domain名字).te中，查看是否有对应的neverallow以及是否与要添加的权限冲突；

3、查看vendor/oppo/sepolicy/common/目录是否有platform_app.te文件，如没有则新建该文件新建文件的命名规则是：以scontext的内容为名，添加对应的权限。

a）allow platform_app system_prop:property_service { set };

b）system_prop由文件安全上下文获取，property_service由tclass获取，对应的操作就不用说了。这里提一点，在system/sepolicy/te_macros中定义了相关操作的宏，可按需要查看。

4、remake system/sepolicy后再$OUT/obj/ ETC/sepolicy_intermediates/policy.conf文件中保存了临时生成的安全策略，可查看自己的修改是否已经生效。

SELinux常见问题-mls

有时发现如下的denied log：

07-13 10:03:38.042 5587 5587 W ndroid.incallui: type=1400 audit(0.0:4215): avc: denied { add_name } for name="Recordings" scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0

在配置 allow platform_app system_data_file:dir add_name; 后，没有生效，这时候就是Mutil-Level Security（MLS）机制导致的操作被denied了。

配置：

type platform_app, domain, mlstrustedsubject; 即可

SELinux常见问题-ioctl

08-07 10:49:20.149 4795 4795 I iwpriv : type=1400 audit(0.0:3457): avc: denied { ioctl } for path="socket:[1607798]" dev="sockfs" ino=1607798 ioctlcmd=8bfc scontext=u:r:system_app:s0 tcontext=u:r:system_app:s0 tclass=udp_socket permissive=1

在setenfoce 0和配置allow system_app self:udp_socket ioctl; 后操作依然被denied，这是由于ioctl的控制在底层划分的更细，需要允许对应ioctlcmd操作。

具体方法为：

1、查找对应的ioctlcmd在ioctl_defines中的定义，如上文中的8bfc，对应的是SIOCIWFIRSTPRIV_1C

2、在对应的文件加入如下的配置：

allowxperm system_app self:udp_socket ioctl SIOCIWFIRSTPRIV_1C;

这样，在ioctl操作时，对应的ioctlcmd就会被允许了。

SELinux常见问题-新增app类型

当前系统中app的domain和文件类型默认的分配原则为：

1、platform签名 + share systemuid -> system_app + system_app_data_file；

2、platform签名 + 普通用户-> platform_app + app_data_file；

3、platform签名 + 特定用户 ： 如bluetooth，对应的domain为bluetooth + bluetooth_data_file

4、三方应用 -> untrusted_app + app_data_file

根据特性需求，需要新增app类型：

1、system/sepolicy/mac_permissions.xml

2、seapp_contexts

user=_app seinfo=theme name=com.nearme.themespace* domain=theme_app type=theme_app_data_file levelFrom=user

3、file.te

type theme_app_data_file, file_type, data_file_type;

4、theme_app.te

type theme_app, domain, mlstrustedsubject;

这样，签名是@THEME(定义在system/sepolicy/keys.conf文件)和包名是comthemespace的应用，domain是theme_app，对应的文件类型是theme_app_data_file

SELinux常见问题-新增、修改文件类型

如某些需求，需要新增文件类型，只允许特定的domain访问，如存放字体文件的目录，只允许主题应用写入和删除，其他domain只有读的权限。

1、file_contexts

/data/system/font(/.*)? u:object_r:font_data_file:s0

2、file.te

type font_data_file, file_type, data_file_type;

3、system/core/rootdir/init.rc

在restorecon_recursive /data之前加入：

mkdir /data/system/font 0777 system system

chmod 0777 /data/system/font

这样，adb shell ls -l -Z /data/system/font 查看到的就是上面配置的文件类型：

-rwxrwxrwx 1 u0_a18 u0_a18 u:object_r:font_data_file:s0:c512,c768 3553188 2017-08-19 16:40 Regular.ttf

SELinux常见问题-新增可执行程序和service

在/system/bin下新增可执行程序，以关键log的bin为例

1、file_contexts

/system/bin/criticallog u:object_r:criticallog_exec:s0

2、critical.te

type criticallog, domain;

type criticallog_exec, exec_type, file_type;

3、system/core/rootdir/init.rc

service criticallog /system/bin/criticallog

这样，init在启动这个criticallog service时，会根据对应的exec类型设置进程的domain，可以通过 adb shell ps –Z | grep criticallog 来确认：

u:r:criticallog:s0 system 484 1 17484 4220 binder_thr 72b6e2eaa8 S /system/bin/criticallog

SELinux常见问题-新增service、无对应的bin

在init.rc中新增service，但没有对应的bin，一般通过sh脚本启动一些功能。这类service，需要在配置rc时，加上seclabel操作，之后，init启动service时，就会根据这个关键字解析出对应的context。以screen_record service为例

1、system/core/rootdir/init.rc

service screen_record /system/bin/sh /autochmod.sh "screen_record”

…

seclabel u:r:screen_record:s0

2、screen_record.te

type screen_record, domain;

type screen_record_exec, exec_type, file_type;

init_daemon_domain(screen_record)

binder_use(screen_record)

allow screen_record shell_exec:file {read open execute_no_trans execute getattr entrypoint};

allow screen_record rootfs:lnk_file {getattr};

allow screen_record rootfs:file {read open};

allow screen_record system_file:file { read open execute_no_trans };

allow screen_record toolbox_exec:file { read open execute_no_trans execute getattr};

allow screen_record self:capability dac_override;

allow screen_record self:process execmem;

如上，新增service需要的默认权限在步骤2中，需要的时候拷贝、修改screen_record为对应的service即可。

SELinux常见问题-sepolicy-inject工具

常常有这样的困扰：selinux权限要加的太多，每次提示一条，都需要重新打包，很浪费时间！

现在有了sepolicy-inject工具，可以动态添加配置，不需要重复打包。

sepolicy-inject -s  -t  -c  -p [,,,...] [-P ] [-o

以下的denied信息，就可以用sepolicy-inject工具动态配置好，最终打包一次就可以了。

01-01 08:01:57.902000 353 353 I auditd : type=1400 audit(0.0:2476): avc: denied { getattr } for comm="servicemanager" scontext=u:r:servicemanager:s0 tcontext=u:r:write_on:s0 tclass=process permissive=1

sepolicy-inject –s servicemanager –t write_on –c process –p getattr -l

由于权限的机制是有一个访问被阻止了，整个进程都会推出，因此每次可能只打印出一条denied信息，为了一次打印出尽量多的信息，可以adb shell setenforce 0之后执行，可以看到denied信息中最后permissive=1，只打印信息，不会阻止。这样就可以尽量多的得到denied信息了。

最终，所有sepolicy-inject动态添加的allow配置，都会记录在/data/seinfo.txt文件，配置完成后，将这个文件的内容复制到对应的TE文件即可。

] [-l|--load]