Android沙箱机制

一说到沙箱，相信大家都有一个大概的认识：每个App会被分配一个uid，互相之间数据不能随意访问。
虽然做上层开发有这么个大概的认识基本也就够了，不过深入了解一下可能会给你的开发带来新的思路。今天我们就深挖一下所谓的沙箱机制。
大家都知道Android底层是Linux内核，而这一切也都源于Linux的权限机制。

Linux 权限机制

• 用户 uid gid gids
• 进程 uid gid gids，继承于所属用户，子进程继承父进程
• 文件系统，uid gid 以及相对应rwx权限

Android

先看adb shell，我们先记住下面这个结论，后面会给出解释：
adb shell 实际上是以“shell”这个uid启动shell进程
adb shell xx 则是fork一个shell进程的子进程xx
因此xx进程的uid、gid与shell的uid、gid一致：id=2000
"id" 命令可以查看user信息：

image.png

"cat /proc/xxx/status"查看进程信息，包括uid、gid、groups

image.png

---

以上是Android中user和进程的uid gid，那么在Android中文件系统的uid、gid又是怎样的呢？

• file 事实上是在文件系统创建时对目录和文件设置了相对应的uid、gid以及权限，这里涉及到一个重要文件 fs_config.c
  对目录的定义：
  

  image.png
  对文件定义：
  image.png

• device node 的uid、gid定义则在各个ueventd.*.rc文件中

ueventd.rc
/dev/alarm 0664 system radio
/dev/rtc0 0640 system system
/dev/tty0 0660 root system
/dev/graphics/* 0660 root graphics
/dev/input/* 0660 root input
/dev/eac 0660 root audio
/dev/cam 0660 root camera

---

由于都是基于Linux的权限机制，因此Android中进程要访问文件那势必也要获取到合理的uid或者gid。
怎么获取？

• System Process
  我们知道在init进程的最后阶段，核心系统服务servicemanager、vold、surfaceflinger等进程都会被启动，他们的uid、gid也都是通过相应的.rc文件指定的。就拿suerfaceflinger来说，surfaceflinger.rc.
  image.png
• App Process
  每个app安装之后被分配uid
  Users、Groups 在android中定义 android_filesystem_config.h
  image.png
  image.png
  我们可以看到熟悉的身影：
  AID_ROOT 0
  AID_SYSTEM 1000
  AID_SHELL 2000
  而对于正常的app will be assigned AID above 10000, and the GID、UID will be the same as AID.
  以微信为例，微信的data目录权限如下：
  image.png
  我们看到这些文件的uid、gid都是u0_a504，这个u0_a504前半部分u0是userID，后面a504是根据微信安装后系统分配id为10504。因为这个id是唯一不重复的，只要不卸载那么10504就只能是微信uid，因此也只有微信的进程uid/gid = u0_a504，也就是说只有微信的进程可以访问微信data目录下的文件，这就保证了app私有数据的独立性与安全性。
  那么除此之外，还有什么方式可以获取权限来访问文件呢？这就和上层的permisson扯上关系了。
  其实核心文件是：platform.xml
  image.png
  看到这个文件大家应该就明白了，我们可以看到每个permission都会对应一个group，里面的gid是不是很熟悉。没错，对于任何申请了这些权限的app来说，它的任何进程的gids都包含了对应的gid，因此才可以访问相应的文件。就拿我们最熟悉的android.permission.WRITE_MEDIA_STORAGE权限来说，我们看下sdcard目录的文件权限：
  image.png

我们看到sdcard目录下的文件其gid都是sdcard_rw，如果一个app在AndroidManifest中申请了这个权限，那么这个app所有进程的gids一定包含sdcard_rw这个gid，那么进程就有相应的rwx权限，就可以访问这些文件。（为保证主线清晰，这些牵线搭桥的逻辑就不一一贴代码溯源了）

到这里有人一定会说：我理解的permission不是这样的啊，我manifest里面声明的permission根本没有这么复杂，另外你上面那个platform.xml文件就只有很少的几个permission，我平时用到的大部分permission都不在里面呢？
这个问题我觉得还是有必要说一下，因为确实容易产生疑问。
我们要清晰的知道，Android的permisson分为两种：

• 底层统一控制（上面讲的）
  对于非Android特有的Service(底层平台已经提供，如File访问，TCPIP数据收发等)，可以多种形式来访问：Android API，Java API，NDK C API，shell都可以访问。这样权限控制就聚口在底层，所以在底层统一控制。这个底层统一控制其实就是基于传统的Linux文件读写执行权限(rwx)。例如android.permission.WRITE_MEDIA_STORAGE
• framework逻辑控制
  绝大部分的permission权限控制发生在framwork层，在ams pms wms 中你会遇到大量调用以下方法的地方：

private void checkPermission(String permission) {  
    if (mContext.checkCallingOrSelfPermission(permission)  
               != PackageManager.PERMISSION_GRANTED) {  
           throw new SecurityException("Access denied to process: " + Binder.getCallingPid()  
                  + ", must have permission " + permission);  
    }  
}  

关于这块的逻辑因为不是本文重点，大体说一句：哪些package在manifest中申请了哪些权限，以及动态权限是否授予，这些信息都会被事先扫描或者动态加入到缓存中，然后framwork会在需要判断这些权限的时候调用checkPermission读取缓存信息。如果申请并且被授予了则放行，否则抛异常。

adb shell

我们再回头来解释一开始说到的adb shell xxx进程uid的问题。通过ps命令我们可以追溯一下adb shell进程父子链：init -> adbd -> /system/bin/sh -> xxx
我说的shell进程即 /system/bin/sh
事实上init进程的uid是root，那么正常情况adbd后面进程也都应该是root啊，为什么从adbd开始uid就成了shell呢？这一度也是我疑惑的地方，看了adbd源码发现原来adbd对uid、gid另外进行了设置。
adbd流程节选：

/* then switch user and group to "shell" */
if (setgid(AID_SHELL) != 0) {
exit(1);
}
if (setuid(AID_SHELL) != 0) {//设置uid为shell
exit(1);
}

---

另外我们看看framwork中shell包的权限声明：shell权限

image.png
我们看到几乎所有的permission都在shell包里声明了，因此adb shell可以说是权限之王（个别权限也没有，否则你把root搁那>_<）。

我们举个例子：
example : adb shell pm grant package_name permission_name

cat /system/bin/am
#!/system/bin/sh
#
# Script to start "pm" on the device, which has a very rudimentary
# shell.
#
base=/system
export CLASSPATH=$base/framework/pm.jar
exec app_process $base/bin com.android.commands.pm.Pm "$@"

具体pm实现这里就不贴了，pm grant是需要验证调用者是否具有android.permission.GRANT_RUNTIME_PERMISSIONS权限，这个权限是@hide，普通app肯定没有这个能力，但是shell这个uid是有的。因此adb shell pm grant就可以给其他package授予某个权限，当然具体代码里还会根据protection_level来限制可以授予哪些权限。
清楚了这些我们可以会对adb shell了然于胸，在debug或者研究东西的时候充分利用adb shell，因为shell拥有海量权限。

当然我们也应该很清楚，在你的app中试图使用下面的代码来达到授权的目的其实是无效的：

Runtime.getRuntime().exec("pm grant package_name permission_name");

为啥就不用我说了吧，我们通篇可都是在强调uid。