每日一问 | run-as 背后做了什么？

如果我们直接以 adb shell 执行这些命令，会这样子：

generic_x86:/data/local/tmp $ cd /proc/$(pidof top.canyie.pine.examples)/fd
/system/bin/sh: cd: /proc/2982/fd: Permission denied
2|generic_x86:/data/local/tmp $ cd /data/data/top.canyie.pine.examples
/system/bin/sh: cd: /data/data/top.canyie.pine.examples: Permission denied

报错 Permission denied。使用 run-as top.canyie.pine.examples 则可以正常执行。为什么？

我们首先要搞清楚一个东西，报错是 permission denied ，这里的 permission 是什么？

Android 是基于 Linux 的操作系统，它底层的权限机制直接复用了 Linux 的权限机制，Linux 里通过 uid 标记一个用户，当它为 0 时，即代表这个用户是超级权限用户也就是所谓的 root。而 Android 里为了实现每个应用的权限不同，给每个应用都分配了一个 uid（这里忽略 sharedUserId、多个应用跑在同一个进程等情况）。

我们这里的 permission denied 会不会就是 uid 问题呢？

stat 一下看看权限：

1|generic_x86:/data/local/tmp $ stat /proc/$(pidof top.canyie.pine.examples)/fd
  File: `/proc/2982/fd'
  Size: 0        Blocks: 0       IO Blocks: 1024        directory
Device: 3h/3d    Inode: 16008    Links: 2
Access: (500/dr-x------)        Uid: (10063/  u0_a63)   Gid: (10063/  u0_a63)
Access: 2022-04-21 14:09:02.594000000
Modify: 2022-04-21 14:09:02.594000000
Change: 2022-04-21 14:09:02.594000000

这个目录的权限是 500，如果不是目录的 owner 则没有任何权限。那么我们已知我们要调试的应用的 uid 是10063，我们 su 10063 切换 uid 再试一下：

2|generic_x86:/data/local/tmp $ su 10063
generic_x86:/data/local/tmp $ id
uid=10063(u0_a63) gid=10063(u0_a63) groups=10063(u0_a63),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc) context=u:r:su:s0
generic_x86:/data/local/tmp $  cd /proc/$(pidof top.canyie.pine.examples)/fd
generic_x86:/proc/2982/fd $ ls
0 10 12 14 16 18 2  21 23 25 27 29 30 32 34 36 38 4  41 43 45 47 49 50 6 8
1 11 13 15 17 19 20 22 24 26 28 3  31 33 35 37 39 40 42 44 46 48 5  52 7

是的，成功了！不过等等，我们 su 之后 id 命令输出的 context 发生了变化，从 u:r🐚s0 变成了 u:r:su:s0。这个 context 是另一个安全机制 SELinux 的一部分，用于标识进程的“身份”。至于什么是 SELinux 这里就不展开说了，感兴趣的同学可以自行搜索。事实上，这个 context 的变化是 su 命令的副作用，如果保持原来的 shell context 去访问 /data/xxx 等 app 的私有目录，实际上还会失败，因为 /data/xxx 被标记为 app_data_file，shell 的 context 对这个 domain 没有访问权限。

我们可以看一下真正的 run-as 之后 id 有什么变化：

generic_x86:/data/local/tmp $ run-as top.canyie.pine.examples
generic_x86:/data/data/top.canyie.pine.examples $ id
uid=10063(u0_a63) gid=10063(u0_a63) groups=10063(u0_a63),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc) context=u:r:untrusted_app:s0:c512,c768

由此我们可以得出结论：run-as 命令通过改变进程的 uid/gid/context 等属性来获得对 app 敏感目录的访问权限。（这里省略了 namespace 等繁琐内容）

扩展知识：capabilities

run-as 命令通过 setresuid 等系统调用改变进程的 uid，那么我们自己写一个东西用这个系统调用能够成功改变 uid 吗？显然是不行的，那么为什么 run-as 命令就有这个魔力改变 uid？

首先我们想到了文件的 s 属性，这个属性允许 exec 后进程更改 setuid，我们熟悉的 su 命令也是通过它才被允许 setuid 的。但是，我们 stat $(which run-as) 发现 run-as 的权限并没有 s ，那么是怎么做到的呢？

我们 cat /proc/self/status 看看：

......
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000001fffffffff
CapAmb: 0000000000000000
......

这里就涉及到 Linux 的另一个权限机制，capabilities。这里简要介绍下最关键一点：我们 exec 一个文件时它拥有的 permitted capabilities 会和当前线程的 bounding capabilities 计算交集然后添加到执行进程的 permitted capabilities 中，它就拥有了特别的权限。run-as 也正是通过在文件上设置 CAP_SETUID 这些 capabilities 从而获得执行 setuid 的权限。更多细节可以查看 run-as.cpp 里的注释，写的很清楚了。