相对于其他读取联系人 /短信 /电话权限,存储权限并不敏感。这些 app 不会把非常重要的资料放到公共存储区域。换个角度看,用户随便删除也不会造成太大麻烦。
的确是很多 sdk 要求存储权限,连 react-native 都不免俗。参加 https://github.com/facebook/react-native/issues/5886,根据里面的描述,即使 app 开发者在 manifest 中手动把权限去掉,gradle 也会自动加入。
限制难度更大。其他权限只要在 java 和 ipc 层就能拦截,文件系统权限需要内核 /命名空间等技术。纵观所有主流桌面系统,有哪个做到隔离每个运行进程的文件系统的? Windows/OSX 上面各种权限滥用的程度要比 mobile 严重得多,随便在文件系统乱拉屎更是司空见惯,也没见大家抱怨什么。( Linux 上非开源的二进制程序没人敢随便运行,只能放到 chroot/docker 里面)
只要可开关的权限,一定会有 app 耍流氓,但仅限部分有资格刷大牌的流氓。相反如果 android 像 ios 一样一刀切,用户连文件系统都看不到,用户也不见得喜欢。(这是我不喜欢 iphone 的最大原因)
普通用户能做的就是眼不见为净,如果空间实在不够用,推荐大家用这个: https://f-droid.org/en/packages/com.google.android.diskusage
@rikka 感觉如果要做到重定向,最佳入口是在 app_process fork 出进程之前,和 supersu 做 mount namespace isolation 类似。另一个入口是 fuse/sdcardfs
1
est 2018-01-07 13:14:31 +08:00 via iPhone
感觉应该可以 hook 这种乱写文件的行为。
保留 fd 但是删除 inode 引用。进程退出就清空间 |
3
iwtbauh 2018-01-07 13:27:52 +08:00 via Android 2
1。存储权限敏感
拥有存储权限的 app 能够窃取、泄漏你 sd 卡上的重要数据,比如密码数据库、私钥文件(尽管他们通常是加密的,但泄漏仍然是不好的)、图片和照片 2。存储权限除了文件管理器 app 外其他应用没有必要使用 app 不需要任何权限就可以读写 /sdcard/Android/data/包名 目录,根本没有必要要求访问完整的 sd 卡,而这些 app/sdk 偏偏这样做了,其动机令人怀疑 3。我们常用的类 Unix 系统上,应用程序大部分都是开源的,因此是可控的,而 Android 上我们常用的的 App 是闭源专有的 类 Unix 系统上,应用程序使用 ~/.config ~/.cache 存放数据,不会把用户的家目录搞得一团乱麻。而反观 Android,拥有 sd 卡权限的 App 将 /sdcard 搞得乱七八糟,连加个 . 隐藏都不做,使得用户找自己文件时相当痛苦 |
4
honeycomb 2018-01-07 13:31:38 +08:00 via Android
|
5
htfy96 2018-01-07 13:39:04 +08:00
|
6
s82kd92l OP @iwtbauh 密码数据库 /私钥文件还是别放 sd 卡上好,推荐你用 termux,默认不使用 sdcard,其他 app 没权限读取。图片照片是没办法控制,但哪怕是流氓如百度云,在上传照片前也会要用户允许的。 至于其他我自己的文件,我是直接用 Download,在文件管理器上加个迅速进入快捷方式(很少有 Download 下面未经允许拉屎的)。然后整个 /sdcard 你就把它当成~/.config 就好。
我不是站在开发者的角度洗地,而是站在用户角度理性分析如何做到伤害最小化,同时指出一些理念上的误区。我的主要论点是:存储权限 /乱拉屎行为,可见性非常高很容易引发用户不爽,但实际伤害小于其他流氓行为。 @honeycomb 不管是 android 还是 ios,想做到类 cookie 式的 fingerprint 方案多的是,iOS 给人的不是安全,而是“安全错觉”. @htfy96 非开源 root 程序,正常人不敢用 |
7
pq 2018-01-07 14:01:45 +08:00
@iwtbauh 所以,最好别在移动设备上存放任何敏感数据,比如身份证照片、密码文件之类的,怎么都防不住流氓 app 们窥视的欲望的。
我是比较困惑把手机当钱包的这种时尚潮流的,手机这东西,现在根本毫无安全性可言。 |
8
nicevar 2018-01-07 14:07:33 +08:00
跟 iOS 一样一刀切是不错的方案,不好的地方就是配置文件想保留的也一并删除了,所以留个特定区域给 app 写入配置文件是很好的方案
|
9
iwtbauh 2018-01-07 14:19:46 +08:00 via Android
@s82kd92l
@pq Android 专门给每个 App 开辟了一处“/sdcard/Android/data/包名”放文件到 sdcard,这个目录不用权限,而实际上我们进入这个目录看看,在 sdcard 乱拉屎的 App 也几乎都用了这个目录,既然 App 们都知道有这个不用申请权限就能用的目录,而且也都用上了,还嚷嚷着要 sdcard 权限,确实很过分。 有时候把一些数据放 sdcard 很方便,也方便和电脑直接复制。 把 /sdcard 看成 ~/.config 令人感到不爽,文件管理器加个书签只能缓解这个问题。 我的做法是 appops,将所有没有必要用 sdcard 的 App 的 sdcard 权限都 ban 掉,唯一的问题是一些 App 会以“找不到 sdcard ”为理由拒绝运行,对于这些 App 我选择不用。 |
10
s82kd92l OP @pq 想要防偷窥是能做到的,比如 signal/snapchat 之类自己给自己发照片密码,除了 root 程序或者设备制造商没法偷窥。目前的问题是各种流氓主动把自己数据暴露给另一个流氓偷窥。
当钱包安全性阿里腾讯比用户责任大得多,他们没把握的话是不敢推广的。 |
11
terence4444 2018-01-07 14:40:51 +08:00 via iPad
@s82kd92l 不明白你指的 “ iOS 是安全错觉” 具体指的是什么?
虽然 iOS 11 在隐私保护上还有点后退了,但我觉得仍然比默认的 Android 安全得多。 |
14
honeycomb 2018-01-07 17:40:01 +08:00 via Android
@s82kd92l
既然不能保证它们不会滥用共享储存空间,那么“解决了所有潜在可能制造问题的人”的方法也是一个务实的办法: Android 的不使用储存权限的办法是这样: 1,应用在 sdcard 有一个无需权限就能访问的半私有空间。 2,有一个 API,应用可以索取访问单个目录的许可 但是它们不肯用。 既然这样的话,就应该让它们什么都没有。 至于 fingerprint 方面,需要做到 1:应用怎么着都做不到能够获得可用于识别设备的,且能存活于重置系统的识别码。 只允许应用获得那些可被使用者重置的识别码。 2: 不同应用在同一个账户上能拿到的识别码是不同的。 同一应用在不同账户,安装-卸载-安装之间能拿到的识别码不同。 3:如果有可供获取的,全局相同的识别码,那么要参考 adid 的使用方式。 4,应用在任何时候都不能试图在设备上存储持久识别码。除非是 hce 等场景。 |
15
s82kd92l OP |
16
honeycomb 2018-01-07 18:49:07 +08:00 via Android
@s82kd92l 实际上你也注意到了,举个例子:
阿里巴巴的 utdid 库会见缝插针,会同时在 system.settings 与 sdcard 根目录储存 utdid 的值。 拿不到 IMEI/serial 的时候这个库也能生成有效的 utdid,所以这些途径都要封掉。最后的目的是,只要不是同一个应用,utdid 不同就可以了。 |
17
iwtbauh 2018-01-07 19:01:19 +08:00 via Android
@s82kd92l 高德地图没有用过,微信可以用 appops 禁用 sdcard 权限,代价是聊天记录没法保存,但我只用微信首付款不受影响,注:Play 商店中的微信,国内版不知
|
18
EchoChan 2018-01-07 19:34:09 +08:00 via iPhone
Google 都不想解决的事妄图开发者会规范操作。
|
19
0x23333333 2018-01-08 08:03:35 +08:00 via Android
1.更改 mount namespace 只能在 root 下 zygote 都没有这个权限
2.sdcardfs/fuse 过于依赖平台 个人感觉 注入 app_process hook IO 调用(open/mkdir) 还是可行的 |
20
pie 2018-01-08 08:33:35 +08:00
|
21
s82kd92l OP @pie @0x23333333 @est 这两天查了下源代码,发现 android 无论是 appops 还是本身的动态存储权限,都是通过 namespace 来实现的:
https://android.googlesource.com/platform/frameworks/base/+/master/core/jni/com_android_internal_os_Zygote.cpp#336 https://android.googlesource.com/platform/frameworks/base/+/master/services/core/java/com/android/server/AppOpsService.java#320 https://source.android.com/devices/storage/#runtime_permissions 要动手脚肯定是在 namespace 上容易些,hook 到 open 开销非常大,不仅仅是 sdcard 上的文件受影响,而且是打开其他包括 system/data 上的文件也会被这个 hook 降低速度. |
22
est 2018-01-09 15:51:11 +08:00
|
23
s82kd92l OP |