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

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

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 有意地没有做

skylancer

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

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

woyaojizhu8

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

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

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 较低的应用也失效呢？

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/空字符串的形式，但它是个常量就很难说了

woyaojizhu8

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

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

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 版本开始呢？还有“检索正在运行的应用”这个权限是不是已经没有用了？

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 也有关于它的描述)

Bown

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

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

honeycomb

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

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

Aquamarine

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

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

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 等通信的手段呢？