如果懷疑是sepolicy權(quán)限導(dǎo)致的問題，首先需要確認(rèn)是否真的是權(quán)限導(dǎo)致的枉疼。
確認(rèn)方法是：關(guān)閉SELinux现喳，查看問題是否存在吟税。
關(guān)閉SELinux的方法：
1、運(yùn)行時(shí)關(guān)閉稀轨，重啟失效：
adb shell setenforce 0
2扼脐、開機(jī)階段關(guān)閉：
1）修改kernel cmdline：
androidboot.selinux=permissive
2）修改init代碼：
selinux_is_enforcing函數(shù)返回false
SELinux常見問題-denied log
在kernel log、event log或main log中奋刽，搜索denied 關(guān)鍵字：
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的屬性進(jìn)行設(shè)置操作佣谐；
2脏榆、在system/sepolicy/中找到platform_app domain的定義，一般在platform_app.te中即(domain名字).te中台谍，查看是否有對應(yīng)的neverallow以及是否與要添加的權(quán)限沖突须喂；
3、查看vendor/oppo/sepolicy/common/目錄是否有platform_app.te文件趁蕊，如沒有則新建該文件新建文件的命名規(guī)則是：以scontext的內(nèi)容為名坞生，添加對應(yīng)的權(quán)限。
a）allow platform_app system_prop:property_service { set };
b）system_prop由文件安全上下文獲取掷伙，property_service由tclass獲取是己，對應(yīng)的操作就不用說了。這里提一點(diǎn)任柜，在system/sepolicy/te_macros中定義了相關(guān)操作的宏卒废，可按需要查看。
4宙地、remake system/sepolicy后再$OUT/obj/ ETC/sepolicy_intermediates/policy.conf文件中保存了臨時(shí)生成的安全策略摔认，可查看自己的修改是否已經(jīng)生效。
SELinux常見問題-mls
有時(shí)發(fā)現(xiàn)如下的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; 后宅粥，沒有生效参袱，這時(shí)候就是Mutil-Level Security（MLS）機(jī)制導(dǎo)致的操作被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的控制在底層劃分的更細(xì)抹蚀，需要允許對應(yīng)ioctlcmd操作。
具體方法為：
1企垦、查找對應(yīng)的ioctlcmd在ioctl_defines中的定義环壤，如上文中的8bfc，對應(yīng)的是SIOCIWFIRSTPRIV_1C
2钞诡、在對應(yīng)的文件加入如下的配置：
allowxperm system_app self:udp_socket ioctl SIOCIWFIRSTPRIV_1C;
這樣郑现，在ioctl操作時(shí)湃崩，對應(yīng)的ioctlcmd就會被允許了。
SELinux常見問題-新增app類型
當(dāng)前系統(tǒng)中app的domain和文件類型默認(rèn)的分配原則為：
1懂酱、platform簽名 + share systemuid -> system_app + system_app_data_file竹习；
2誊抛、platform簽名 + 普通用戶-> platform_app + app_data_file列牺；
3、platform簽名 + 特定用戶 ： 如bluetooth拗窃，對應(yīng)的domain為bluetooth + bluetooth_data_file
4瞎领、三方應(yīng)用 -> untrusted_app + app_data_file
根據(jù)特性需求，需要新增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的應(yīng)用，domain是theme_app诈铛，對應(yīng)的文件類型是theme_app_data_file
SELinux常見問題-新增乙各、修改文件類型
如某些需求，需要新增文件類型幢竹，只允許特定的domain訪問耳峦，如存放字體文件的目錄，只允許主題應(yīng)用寫入和刪除焕毫，其他domain只有讀的權(quán)限蹲坷。
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常見問題-新增可執(zhí)行程序和service
在/system/bin下新增可執(zhí)行程序疙咸，以關(guān)鍵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在啟動這個(gè)criticallog service時(shí)，會根據(jù)對應(yīng)的exec類型設(shè)置進(jìn)程的domain腔召，可以通過 adb shell ps –Z | grep criticallog 來確認(rèn)：
u:r:criticallog:s0 system 484 1 17484 4220 binder_thr 72b6e2eaa8 S /system/bin/criticallog
SELinux常見問題-新增service杆查、無對應(yīng)的bin
在init.rc中新增service，但沒有對應(yīng)的bin臀蛛，一般通過sh腳本啟動一些功能亲桦。這類service崖蜜，需要在配置rc時(shí)，加上seclabel操作客峭，之后豫领，init啟動service時(shí)，就會根據(jù)這個(gè)關(guān)鍵字解析出對應(yīng)的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需要的默認(rèn)權(quán)限在步驟2中课蔬，需要的時(shí)候拷貝、修改screen_record為對應(yīng)的service即可郊尝。
SELinux常見問題-sepolicy-inject工具
常常有這樣的困擾：selinux權(quán)限要加的太多二跋，每次提示一條，都需要重新打包流昏，很浪費(fèi)時(shí)間扎即！
現(xiàn)在有了sepolicy-inject工具，可以動態(tài)添加配置况凉，不需要重復(fù)打包谚鄙。
sepolicy-inject -s? -t? -c? -p [,,,...] [-P ] [-o
以下的denied信息，就可以用sepolicy-inject工具動態(tài)配置好茎刚，最終打包一次就可以了襟锐。
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
由于權(quán)限的機(jī)制是有一個(gè)訪問被阻止了，整個(gè)進(jìn)程都會推出膛锭，因此每次可能只打印出一條denied信息粮坞，為了一次打印出盡量多的信息，可以adb shell setenforce 0之后執(zhí)行初狰，可以看到denied信息中最后permissive=1莫杈，只打印信息，不會阻止奢入。這樣就可以盡量多的得到denied信息了筝闹。
最終，所有sepolicy-inject動態(tài)添加的allow配置腥光，都會記錄在/data/seinfo.txt文件关顷，配置完成后，將這個(gè)文件的內(nèi)容復(fù)制到對應(yīng)的TE文件即可武福。
] [-l|--load]
