获取root权限失败(厉害，发现 iOS 16.1.2 新漏洞，是否可用于越狱？)

获取root权限失败(厉害，发现 iOS 16.1.2 新漏洞，是否可用于越狱？)

获取root权限失败文章列表:

• 1、厉害，发现 iOS 16.1.2 新漏洞，是否可用于越狱？
• 2、小米3为何没有获取系统最高权限
• 3、小米手机怎样获得root权限呢
• 4、工作日报 2021.10.27 Android-SEAndroid权限问题指南
• 5、如何解除手机Root？

厉害，发现 iOS 16.1.2 新漏洞，是否可用于越狱？

关于 iOS 15.0 - 15.1.1 系统 XinaA15 越狱工具下一个版本进展，目前仍然在解决中，下一个版本将要修复三点问题，包括：

可能出现输入法键盘冻结的问题

安装应用级插件出现白图标的问题

玩游戏出现误封的问题（指正常游戏情况下）

关于 iOS 15.2 - 15.4.1 系统越狱进展，目前还没有消息，对于 CoolStar 和 Pwn20wnd 越狱大神，也没有透露相关越狱进展，不知道是不是已经放弃还是什么？这就未知了，Pwn20wnd 已经很久没发推了。

所以大家都把希望寄托在国内朱心浪大神身上，不过！朱心浪目前仍然在解决 iOS 15.0 - 15.1.1 上问题，还没有那么快研究 iOS 15.2 - 15.4.1 系统，之前也研究过，但发现并没有那么简单，需要时间。

对于 iOS 15.5 系统设备越狱，之前 simo 大神分享多个漏洞，对于这些漏洞大概率是可以利用的，可以实现root权限，但还需要时间去研究，并不会那么快出现，得知可获取root权限，你还需要研究完成无根越狱。

下图是 simo 大神测试设备及系统是有效的。

对于 iOS 15.6 - 16.0 系统，上述提到内核漏洞，它是支持的，但是！沙盒逃逸已在 iOS 15.6 上修复了，也就是说，需要一个新沙盒逃逸你才能顺利在 iOS 15.0 - 15.6 上获取root权限，不然是无效的。

关于 iOS 16.0 - 16.0.3 系统，在11月25日下午时段，Project Zero Bugs 官方公布 Ian Beer 一些漏洞，而此漏洞涉及到 iOS 16.0.3 及以下的，据说能实现应用程序使用内核权限执行任意代码，不知道是否可利用。

直到！12月11日凌晨时段，simo 大神又发推了，分享一张截图，从截图的信息可见，这是使用 iPhone 14 Pro Max 利用 iOS 16.1.2 系统上内核漏洞实现攻击，显然！这就证明该系统存在可利用漏洞，但不确定是否会公开。

如果能实现 root 权限，对于越狱确实有一定帮助的，重点还不确定是否公开。

当然了！低版本系统我是不建议你们升级，iOS 16 A12 - A15越狱仍然需要等很久，假设他真的公布此漏洞，那也未必能马上越狱，所以说低版本应该保留，已经升级到 iOS 16.2 系统，应当降级回去。

不过！simo 今天公布告知 iOS 16.1.2 存在漏洞，不知道是不是暗示着，在 iOS 16.2 系统上已经修补。如果已经修补了，意味着在 iOS 16.2 安全内容网页中，也会出现 simo 大神，显然赏金应该已经拿到。

你们认为这个漏洞赏金值多少钱？下图是苹果官网给出漏洞赏金价格。

未授权访问敏感数据（5000 - 100000 美元）

所有应用的可预测枚举（5000美元）

应用程序访问通常受TCC提示保护的少量敏感数据（25000美元）

对敏感数据的部分应用访问通常受 TCC 提示保护（50000美元）

对敏感数据的广泛应用访问，通常受TCC提示或平台沙箱保护（100000美元）

特权提升获取root（5000 - 150000 美元）

Gatekeeper bypass（5000美元）

root到内核权限提升（15000美元）

用户到root权限提升（50000美元）

用户到根权限提升（100000美元）

可从应用访问的内核代码执行（150000美元）

看到上面赏金价格，你们应该知道，能免费分享漏洞的大神，真的是活雷锋。但这些安全研究人员并不会参与越狱，只需要实现获取root权限就行，因为这样就能达到赏金条件，对于完成越狱，还需要花费很多时间，再加上 iOS 15.2 系统起，苹果已经加大难度阻止越狱，因此以后越狱都是罕见。

重点！这些安全研究人员并不会花太多时间去投入越狱，众所周知！开发越狱真的免费做，免费弄就算了，还会被骂，所以很多人都会选择会放弃，能坚持为我们弄越狱的，真的是活雷锋，这无须质疑。

对于 iOS 15.0 - 15.7.1 A9 - A11 和 16.0 - 16.1.2 A11 设备，目前是可以利用硬件漏洞实现越狱，但需要macOS或Linux引导越狱才行。

大概这些内容了，话说！你们认为 iOS 16 A12 - A15 还会有越狱吗？请评论。

小米3为何没有获取系统最高权限

小米手机如何获取最高权限

工具/原料

小米手机

root权限

方法一：开发版获取root权限

1

小米手机系统分为稳定版和开发版，按官方说法，稳定版本为了维持良好的稳定性，没有开放root权限，而开发版本则附带root权限开启功能；

2

首先是开发版获取root权限的方法，开发版root功能很简单，直接系统设置中就可以打开root权限，

3

点开系统设置，就可以看到授权管理，点进去就可以看见应用列表，

4

当在手机界面看到应用列表后，选择菜单键，可以看到设置，

方法二：稳定版获取root权限

稳定版本为了追求系统的稳定性，是不允许随便root的，由于root可以访问和修改你手机几乎所有的文件；

虽然官方不允许随意root，不过我们还是有方法获取root权限，需要使用LBE授权管理，

简单介绍下LBE安全大师：

对于ROOT用户，安全大师采用了最先进的主动防御技术，能将任何恶意行为狙杀于现行。使用安全大师，您可以保护隐私，防止扣费，禁止程序联网，监控流量以及反电话短信骚扰。 对于没有获取ROOT权限的用户，您依旧可以使用我们的流量控制，电话短信防火墙，系统优化清理等功能。

4

LBE的主界面，我们可以在这里设置root权限，下面是获取了root权限的应用程序

小米手机怎样获得root权限呢

现在手机越做越智能，而有一些app呢对系统权限要求也开始要求越来越“离谱”，比如有一些应用就需要获取root权限才能运行生效，但是市面上的很多获取root权限的工具参差不齐，并且有很大的失败概率。

那么今天就给一些新手提供三种小米官方公布获取root的方法（实际上MIUI官方标注的是由稳定版升级到开发版，至于其他的在这里就不展开讲了）需要提醒的是手机获取root后系统可能稍微会有改变，因为开发版将体验到比较新的小米黑科技，不过不影响体验。

*另外手机获取root后安全系数会降低，建议如果不是特别需要的就安静的用手中的稳定版，也就是手机出厂装的系统。*

接下来开始你的root之旅。

方法1：系统内升级

MIUI完整包跨版本升级、降级均需手动进入Recovery 清除全部数据。

带BL锁机型：跨版本升级过程中会强制清除全部数据，无需手动清除。

下载 MIUI_ROM 最新安装包 （下载地址是小米官方网站）


如果已经在下载页面下载过最新安装包，无需重新下载。

将手机连接电脑（用手机下载也可以），将 zip 包拷贝至内置存储 /downloaded_rom 文件夹下，然后进入“系统更新”：


MIUI 6/7/8：点右上角“...”选择“手动选择安装包” ，然后选择 zip 包。

带BL锁机型：只能选择MIUI官方下载页中最新版本进行卡刷升级，非最新外发版本不支持卡刷。

选择正确完整包后，系统会自动开始升级，让 ROM 飞一会！完成之后，重启进入新系统。

方法2：通过 Recovery 升级

MIUI完整包跨版本升级、降级均需清除全部数据。

因Recovery界面不同，此教程暂不适用mtk平台的红米手机也不适用带有BL锁的机型。

1、下载 MIUI_ROM 最新安装包 （同上）

电脑上操作，重命名zip文件包为 update.zip 拷贝至内置存储 根目录。

2、开机状态下：进入“系统更新”，点右上角“...”选择“重启到恢复模式（Recovery）”，点击“立即重启” 进入Recovery模式。

3、关机状态下：同时按住音量上 电源键开机，屏幕亮起松开电源键保持长按音量键 进入Recovery模式。

4、选择“简体中文”并确认（音量键选择电源键确认），选择“将update.zip安装至系统一”并确认。选择确认后等待完成，选择重启至系统一即可。

方法3：通用线刷教程

注意：请确保手机电量充足，按照此教程操作会将您的手机升级至MIUI最新版本，全过程会清空所有用户数据，请谨慎操作。

线刷降级均需清除全部数据。此教程暂不适用部分红米手机

**需要工具 去小米官网下载“通用刷机”**

1、在手机上操作，关机状态下，同时按住 音量下 电源键 进入Fastboot模式将手机USB连接电脑。

2、刷机工具下载完成后安装（如遇到系统安全提示请选择允许安装），打开XiaoMiFlash.exe将复制的内容粘贴到蓝色区域位置。

3、点击黄色圈选部分加载设备，刷机程序会自动识别手机，点击红色圈选部分刷机开始刷机。

4、有BL锁机型默认会选择“全部删除并LOCK”，没有BL锁机型需要手动选择“全部删除”（如下图绿框显示）

若是以上方法不能满足你的要去，小编建议可以电脑下载小米助手，辅助刷机。

工作日报 2021.10.27 Android-SEAndroid权限问题指南

2021.10.27

问题澄清：

河北联创项目联调支撑，新增挑战认证token认证接口；

校招面试3人；

mcvideo赋能文档书写；

支持SDS服务器版本返回空时默认为4.0版本，OTA参数增加；

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_serveruser=system seinfo=platform domain=system_app type=system_app_data_fileuser=bluetooth seinfo=platform domain=bluetooth type=bluetooth_data_fileuser=nfc seinfo=platform domain=nfc type=nfc_data_fileuser=radio seinfo=platform domain=radio type=radio_data_fileuser=shared_relro domain=shared_relrouser=shell seinfo=platform domain=shell type=shell_data_fileuser=_isolated domain=isolated_app levelFrom=useruser=_app seinfo=platform domain=platform_app type=app_data_file levelFrom=useruser=_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.keychainu:r:platform_app:s0 u0_a6 2439 1172 com.android.managedprovisioningu:r:untrusted_app:s0 u0_a8 2460 1172 com.android.onetimeinitializeru:r:system_app:s0 system 2480 1172 com.android.tv.settingsu:r:untrusted_app:s0 u0_a27 2504 1172 com.android.emailu:r:untrusted_app:s0 u0_a28 2523 1172 com.android.exchangeu: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
packagesappsOneTimeInitializerAndroid.mk 没有定义LOCAL_CERTIFICATE，默认是shared
packagesappsManagedProvisioningAndroid.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)

补充说明：

有时候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，如果有定义的话)；

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

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

遇到问题不确定是否由于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 PaxApiServicePaxApiService u:object_r:PaxApiService_service:s0

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

#type for PaxApiServicetype PaxApiService_service, service_manager_type;

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

#add for PaxApiServiceallow system_server PaxApiService_service:service_manager { add find };

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

#add for PaxServiceallow 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 PaxSystemUtilPaxSystemUtil u:object_r:PaxSystemUtil_service:s0

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

#type for PaxSystemUtiltype PaxSystemUtil_service, service_manager_type;

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

#add for PaxSystemUtilallow system_server PaxSystemUtil_service:service_manager { add find };

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

#add for PaxSystemUtilallow platform_app PaxSystemUtil_service:service_manager { find };

四、新增加权限文件

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

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

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

在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进程访问。

由于我们的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;

编辑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

在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 -> 100801-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=001-02 10:01:37.599 217 217 E ServiceManager: add_service('PaxSystemUtil',91) uid=1000 - PERMISSION DENIEDlibsepol.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

image.png

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=001-01 11:11:39.435 E/ServiceManager( 218): add_service('PaxApiService',92) uid=0 - PERMISSION DENIED

调试技巧：

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

on post-fs-dataon property:pax.ctrl.paxservice=1 start paxserviceservice 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_fileneverallow {all_untrusted_apps} {file_type -paxdroid_share_file}:file link;#同上neverallow { all_untrusted_apps -mediaprovider } {fs_type-fuse # sdcard-sdcardfs # sdcard-vfatfile_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 filesuserdebug_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 paxpax.ctrl. u:object_r:pax_ctrl_prop:s0pax.soc. u:object_r:pax_ctrl_prop:s0com.pax. u:object_r:pax_ctrl_prop:s0 pax.sp. u:object_r:pax_ctrl_prop:s0persist.pax. u:object_r:pax_ctrl_prop:s0ro.epay.serial u:object_r:pax_ctrl_prop:s0ro.ums.manufacturer.info u:object_r:pax_ctrl_prop:s0pax.sys. u:object_r:pax_ctrl_prop:s0pax.sdk. u:object_r:pax_ctrl_prop:s0pax.persist. u:object_r:pax_ctrl_prop:s0pax.param. u:object_r:pax_ctrl_prop:s0ro.pax. u:object_r:pax_ctrl_prop:s0

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

#add for pax.ctrl propertytype pax_ctrl_prop, property_type;

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

image.png

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 fuseblksdcardfs: mounted on top of /mnt/media_rw/exsdcard0 type vfat

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

如何解除手机Root？

不用问小道也知道

Root权限很多人都听过

但是，对它的工作原理却知之甚少

操作的时候更是战战兢兢

小道经常看到各种吐槽↓↓

甚至有人说

有这么一个东西

在Android上，它叫Root

在生活里，它叫表白

名字和领域不同，但道理惊人的相似

之前为所欲为，之后举步维艰

现如今下载一些第三方软件

其中的部分高级功能需要高级权限

如果你没有获得Root

那你就不能用这部分功能

但是，它同时还提供了Root工具

还正儿八经的教你获取高级权限的功能

而你，不经意就获取了Root

话说回来，很多人在懵懂的状态

下应用的时候安装了Root权限

这样做的后果是：

你的手机可能会无故死机或重启

甚至手机无法升级

……

我@!#$%^&*(!@#$%^^&*...

那已经有了Root权限怎么办哩？

可以解除啊

“唯一的方法是：重新刷机或固件升级”

你可以去体验店或售后进行固件升级

当然，如果你对自己有信心

也可以自行下载固件升级手机噻

点击手机桌面上的系统更新

再点击在线升级

如果桌面没有

请您移驾设置-系统更新

固件升级，是必要的时候进行的

比如手机因Root

导致Root系统故障而无法升级

没必要的时候

请大家自己斟酌是否升级

具体升级方法如下↓↓

一、下载固件

登录OPPO官网（www.oppo.com）

进入服务-升级手机-找到相应机型的固件

下载至手机根目录（最好不是存储卡）

记住固件包名字

二、备份文件

下载好后

如果有重要文件需要保留

请先备份

备份好后，手机关机

三、恢复模式

同时按住开机键 音量下键3秒左右

手机进入OPPO恢复模式

四、清除数据

点击简体中文-清除数据和缓存

清除用户数据和缓存

五、升级手机

清除数据后，返回上一界面

点击安装升级文件

选择刚刚下载的固件

点击升级

六、服务中心

如果个人无法自助升级

或无固件包降级手机系统

请备份手机重要资料

带上手机、发票、保修卡

前往OPPO客户服务中心升级

如果觉得有用，

就分享给更多的小伙伴吧~