安卓 7.1 的系统，权限管理的最佳方案？？

xposed

权限

xprivacy

Boot

33 条回复 • 2017-03-26 23:58:23 +08:00

1

crs0910

2017-03-13 20:31:38 +08:00 via Android

冰箱绿色守护黑域系统自带权限管理

2

qceytzn

OP

2017-03-13 20:40:01 +08:00

@crs0910 冻结的那几个好解决，主要是权限管理， xprivacy 还能给流氓返回一个贾信息，系统自带的真的是弱爆了...

3

watermeter

2017-03-13 21:26:55 +08:00

app ops

4

Sharuru

2017-03-13 21:54:09 +08:00

黑域 with AppOps
前者自动休眠、后者管理权限。

5

28661

2017-03-13 21:58:49 +08:00

黑域+AppOps

6

AsherG

2017-03-13 21:59:33 +08:00

同楼上，黑域+app ops

7

qceytzn

OP

2017-03-13 22:01:53 +08:00

@watermeter play 里有好几个 app ops ，你们用的是哪个？

8

qceytzn

OP

2017-03-13 22:02:23 +08:00

@AsherG
@28661
@Sharuru play 里有好几个 app ops ，你们用的是哪个？

9

Jaspr

2017-03-13 22:10:48 +08:00

Qixingchen 的 App Ops

10

AsherG

2017-03-13 22:43:30 +08:00

@qceytzn #8 https://play.google.com/store/apps/details?id=rikka.appops

11

woyaojizhu8

2017-03-13 22:54:05 +08:00

@Jaspr
@AsherG
@28661
@Sharuru
@honeycomb
我看到 app ops 的权限管理和应用本身的权限列表还是不完全一致，这其中有什么规律呢？比如应用权限列表里有“检索正在运行的应用”这一项，而 appops 里没有，是不是就没有办法禁止该应用检索正在运行的应用了呢？

12

simple4wan

2017-03-14 09:32:17 +08:00

发现国产魅族机器自带的管理不错的有效杀掉全家桶

13

honeycomb

2017-03-14 09:40:20 +08:00

2

@qceytzn 自然是 7.x 能用的 appops
一共有两个：

Qixingchen 的是 rikka.appops ，是一个带内购的软件
还有一个是全部开源的 com.zzzmode.appopsx ，代码在 https://github.com/8enet/AppOpsX

都是很好的 appops wrapper ，而且两者在更新的过程中明显有互相借鉴

@woyaojizhu8
关于权限有三个不等同的概念：

一个是 Android.permission 命名空间的对象，它和 API 的关系更多是，如果需要运行某一命名空间的指定 API ，则必须要在应用的元文件里申明对应的 Android.permission.[]项目：

二个是 4.3 开始出现的 AppOps 里的各种 OP ，具体涉及的 API 里会加入 AppOps 的代码，在运行期间检查是否获得了这个 OP 的使用许可。如果是通过 Runtime Permission 设定的新版应用，则抛出违例，如果是旧版应用，或直接通过 AppOps 设定，则“ Silently fail ”------这是对付流氓软件的办法

三个是 6.0 开始出现的 Runtime Permission 里的权限

Runtime Permission 直接依赖于 AppOps ，所以单个 Runtime Permission 对应一个或多个 OP 项目。

14

qceytzn

OP

2017-03-14 16:38:10 +08:00

@honeycomb AppOpsX 这个软件要不是你推荐我还真不知道，在 play 上搜“ App Ops ”是找不到这个软件的，因为其名字里没有空格。这会试用下来，感觉不错，个人更喜欢这样的软件，比 App Ops 用的还顺手一点，推荐！

15

woyaojizhu8

2017-03-16 00:08:14 +08:00

@honeycomb
再请教一下：
1.如果是旧版应用，则“ Silently fail ”？那旧版应用都获得不了权限了？这与实际使用体验不符吧。
2.xprivacy 对.so 很无力，在很多情况下无法限制其行为，那 AppOps 有这个问题吗？
3.AppOps 能限制应用获取信息到何种程度呢？其程度与 xprivacy 相差大吗？比如本机 wifi 模块 mac 、、 android id 等能唯一确定设备的信息，连接的 wifi ssid 等能用于定位的信息， AppOps 能全部封堵住应用对这些信息的获取吗？还有已经安装的应用列表、正在运行的程序等信息， AppOps 能限制吗？
xprivacy 稳定版已经两年多没更新了，期间好像一直没出现如 xprivacy 那样强大的权限管理工具，感觉 android 上的权限管理不容乐观啊。

16

honeycomb

2017-03-16 01:55:20 +08:00

@woyaojizhu8
1 ，这里 Silently fail 表示应用会拿到一个 null 或者空值之类的返回，这么做是尽可能为了不让应用崩溃
2 ， appops 是直接插到它所管辖的具体 API 的源代码里的，应该是有用的。但是如果某个 API 事实上涉及到了某个 OP ，但没有插桩的话，那就管不着。
3 ，自己试试看不就知道了， AppOps 只要有 adb 就能用。还可以看 AppOpsManager.java 的源代码。

本机 wifi 模块 mac ：在稍微新一些的 Android 就默认已经拿不到了， 7.0 的话连 /proc 的很多东西都不让看
android id 不行
已经安装的应用列表不行
正在运行的程序等信息(新版的)默认就阻止了

17

honeycomb

2017-03-16 01:56:31 +08:00

ssid 是这样，正连接着的热点的 ssid/bssid 不能阻止获取(iOS 也是一样)，但未连接的 ssid/bssid 受到位置权限保护。

18

qceytzn

OP

2017-03-16 05:31:22 +08:00

@honeycomb 上面帖子里说的“ android id 不行 ”是指“ AppOps 不能阻止程序拿到系统的 android id ”？下面的几句话的意思是“ AppOps 不能阻止程序拿到已经安装的应用列表”、“ AppOps 不能阻止程序拿到正在连接着的热点的 ssid/bssid ”这样的意思吗？

除了安卓 id 之外，还有个更重要的 IMEI 以及手机的品牌和型号， 7.1 的系统本身以及 AppOps 能阻止程序拿到吗？

19

woyaojizhu8

2017-03-16 23:16:03 +08:00

@honeycomb
我看了安卓关于 runtime permission 的文档，还有其他一些介绍文章，再进行了一些实践，这是我的理解：
runtime permission 需要请求的权限（也就是危险权限）包含于 Android.permission 的权限，而且是以权限组的形式请求的；
AppOps 的权限和 Android.permission 权限互相之间没有包含关系；
runtime permission 需要请求的权限是 AppOps 和 Android.permission 交集的子集；
这三种权限的设定值是相互独立的，在权限检查时是“与”的关系。也就是说，一个应用想获取 imei ，必须在 mainfest 里有读取手机身份的权限，而且获得了 runtime permission 的电话权限，并且 app ops 里的“读取手机状态和身份”权限也允许了。
你说“ Runtime Permission 直接依赖于 AppOps ，所以单个 Runtime Permission 对应一个或多个 OP 项目。”可能在代码实现上是这样，但从我的实践来看这两种权限系统的设定值还是相互独立的。

20

woyaojizhu8

2017-03-16 23:57:09 +08:00

@honeycomb “某个 API 事实上涉及到了某个 OP ，但没有插桩”是一种怎样的情况？什么是“事实上涉及到”？为什么这种情况下只能拦截 java 代码，无法拦截原生库？

21

honeycomb

2017-03-17 00:09:02 +08:00

@woyaojizhu8

是的， AppOps 的设定与 Runtime Permission 的设定是分离的，即应用进行某个操作，需要两者都允许。
而这就是一些流氓应用的滥用行为可以通过 AppOps 阻止的原因：
它只检查了 Runtime Permission ，但没有考虑 AppOps ，而 AppOps 层面恰好可以设置让 API 返回空值的(将某个 OP 设置为 ignore ，这个做法是针对 target API level 低于 Android 6.0 的旧版应用设计的)。

Runtime Permission 的具体实现是 AppOps 。
有一些不属于 Runtime Permission 的，但又是系统在默认情况下就允许用户修改的权限设置，如“修改系统设置”，“在其它应用前面显示”等实际上就是直接在修改 AppOps 设定。

AppOps 的权限和 Android.permission 权限的区别应该是这样的：

如果应用没有声明 Android.permission 里的对象，那么它在试图使用这个对象制约的 API 时候会抛出 SecurityException 异常。

对于 target API 是 Android 6.0 及以上的应用，如果出现了在 Android.permission 声明但没有获得 Runtime Permission 时，直接调用对应的 API 也会抛出 SecurityException 。系统为应用提供了 API ，应用可以在任何时候检查自身是否获得了 Runtime Permission 的授权。不给权限就关闭的流氓做法就是靠这个机制实现的。

对于 target API 低于 Android 6.0 的应用，如果出现在 Android.permission 声明但没有获得 Runtime Permission 时，直接调用对应的 API 则会通过“ silent fail ”的形式达到阻止的目的：不会抛出 SecurityException ，但 API 返回的数据是空的(null ，或者是内容为空的对象)。

silent fail 对于用户来说是一件好事(特别是当我们没有一个迫使开发商不能作出“不给权限就关闭”行为的应用商店时)，这个时候应用难以知道自己是否获得了权限，如此可以增加其滥用权限机制的困难程度。

22

honeycomb

2017-03-17 00:20:23 +08:00

“为什么这种情况下只能拦截 java 代码，无法拦截原生库？”
我显然不是这个意思，我说得是 AppOps 无论通过 java 代码调用 API ，还是通过原生代码调用 API ，它都能拦截。因为 AppOps 自身就是某个 API 的一部分。

“某个 API 事实上涉及到了某个 OP ，但没有插桩”是一种怎样的情况？什么是“事实上涉及到”？
举例：
1 ，很多信息可以从 proc 文件系统读到，但是 AppOps 不负责 proc 。比如在 Android 7.0 以前，可以从 proc 读取到设备无线网卡 /蓝牙的 MAC(7.0 开始通过新增的 SELinux 规则予以阻止了)，而 MAC 受到的保护应当至少是和 IMEI(由电话权限保护)同级的。 AppOps 从来都不能保护 MAC 。类似地还有 android.os.Build.SERIAL 全局常量， CDD 直接规定这个值必须是可见的。

2 ， Android 提供了 API ，让应用可以读取到当前已经连接到的 Wifi 热点的 SSID 与 BSSID 。显然这个 API 可以用来获取粗略定位信息，但它不受到 AppOps 保护。
AppOps 确实保护了读取周围未连接的 wifi 热点 /蓝牙信标的信息。

以上两者都是“事实上涉及到且没有插桩”的情况，其中 1 是不属于 AppOps 这三个机制保护，其中 2 是应该受到它们的保护但 Android 有意地没有做

23

skylancer

2017-03-17 08:51:24 +08:00 via Android

1

看了上面一堆讨论，我额外提醒一下，作为账户管理员的应用无需获取账户权限即可获得所有使用 Account Manager 的账户信息，包括 Gmail

24

woyaojizhu8

2017-03-18 21:20:56 +08:00

@honeycomb
https://android.googlesource.com/platform/system/sepolicy/+/3286fca7db279b9e5d69da408301fc48b52b4c4b 这里有个禁止应用读取 Build.SERIAL 的 commit

25

woyaojizhu8

2017-03-19 13:59:18 +08:00

@honeycomb 这个安卓源码管理系统我不太看得懂啊。我想问下，这个 commit 有希望进 7.1 的正式版吗？
另外，它说“ The Build.SERIAL value is set to 'undefined' for apps targeting high enough SDK and for legacy app the value is still available ” , “ high enough SDK ” 是指 SDK 25 （ android 7.1 ）吗？有没有办法让 Build.SERIAL 对目标 SDK 较低的应用也失效呢？

26

honeycomb

2017-03-19 21:23:10 +08:00

@woyaojizhu8

谢谢，原来 AOSP 有这个改动，看样子它比较可能会出现在 Android O 。

对应的 code review
https://android-review.googlesource.com/#/c/276118/

7.1 的代码好几个月前(Pixel 发售以前)就已经固定了， 7.1.2 都快要正式了。所以这个改动肯定会用于新版本的 API level 。

即:
The Build.SERIAL value is set to 'undefined' for apps targeting high enough SDK
对于编译时指定足够高的 API Level(或许是 Android O 可能会使用的 26)的应用， Build.SERIAL 常量返回 undefined

然后使用受到电话权限保护的 Build.getSerial()接口替代它。

“有没有办法让 Build.SERIAL 对目标 SDK 较低的应用也失效呢”
看上去它是在 SELinux 动了手脚， AppOps 不像是能保护到它。如果 Build.SERIAL 是一个接口的话就会做成返回 null/空字符串的形式，但它是个常量就很难说了

27

woyaojizhu8

2017-03-20 00:38:24 +08:00

@honeycomb
并不是想用 AppOps 保护，而是看着这个 commit 做出的改动挺简单的，就是在 selinux 里加两条，所以想着能否移植到 6.0 和 7.0 的系统去。
但是如果真是用 Build.getSerial()代替了 Build.SERIAL 的话，好像并不是这么简单的修改可以实现的，可能这个接口改动在以前就实现了，现在只不过添加了 selinux 规则使得它生效而已。但是我也不会用这个安卓源码管理系统，不知道怎么去找这之前实现了这个接口改动的 commit ，也就没法进一步探究了。。。

28

woyaojizhu8

2017-03-20 02:01:50 +08:00

@honeycomb 还有一些问题：
1.这个 Build.SERIAL 是跟硬件有关的值吗？它具体是什么元件的什么值呢？存于何处呢？
2.也就是说目前 Android id ， Build.SERIAL ，连接着的 wifi 的 ssid 还有已经安装的应用列表都不受到 Android.permission 和 AppOps 两者的保护了？还有 /proc, 在 7.0 之前都不需要任何权限即可读取，那么从这泄漏的信息也不止是 mac 地址吧？我所知道的还有一些进程信息，可能还有别的。
3."正在运行的程序等信息(新版的)默认就阻止了" 这是从哪个 android 版本开始呢？还有“检索正在运行的应用”这个权限是不是已经没有用了？

29

honeycomb

2017-03-20 09:11:15 +08:00

@woyaojizhu8

“能否移植到 6.0 和 7.0 的系统去”
肯定能，但这个 commit 看上去只是隐藏 Build.SERIAL 这个改动的其中一小部分

“目前 Android id ， Build.SERIAL ，连接着的 wifi 的 ssid 还有已经安装的应用列表都不受到 Android.permission 和 AppOps 两者的保护了”

1 ：
读 Android id 的 API 不需要权限
Build.SERIAL 是全局常量
连接着的 wifi 的 ssid/bssid 在 iOS 上似乎也不受到保护
读取已经安装的应用在 Android 里不受保护，在 iOS 里受到极大限制(因为跨应用分享机制，总会知道一小部分)

“还有 /proc, 在 7.0 之前都不需要任何权限即可读取”
/proc “关于本地几个 MAC 的访问”(而不是整个 /proc)在 7.0 以前没有被 SELiunx 保护，但 SElinux 机制很早就加入到 Android 中，且一直在添加规则。 AOSP 里肯定有一个上游的基础规则(CDD 也有关于它的描述)

30

Bown

2017-03-20 09:58:58 +08:00

最近开始用黑域，一直有个疑问，黑域是怎么定义运行中状态的，因为每次看黑域的 Running 和绿色守护的待休眠都完全不一样 - -

31

honeycomb

2017-03-20 13:21:43 +08:00

@Bown 问作者或者直接看源代码

32

Aquamarine

2017-03-20 20:59:49 +08:00

正是因为安卓 7 框架还不支持，所以用了 CM13 。

33

woyaojizhu8

2017-03-26 23:58:23 +08:00

@honeycomb
https://forum.xda-developers.com/xposed/modules/xprivacy-ultimate-android-privacy-app-t2320783/post50352683#post50352683
照这里说法，通过 ipc 直接与 ActivityManager 通信而不使用 documented java functions 可以绕过 xprivacy 的通常限制，而 xprivacy 的 ipc 限制功能就是为了阻止这种绕过手段。那么 appops 既然自身就是某个 API 的一部分，是不是也无法拦截这种直接使用 ipc 与 ActivityManager 或者 PackageManager 等通信的手段呢？