【Linux】Linux中的特权 | SUID | Linux Capabilities

Jouzzy

已于 2023-02-16 23:24:03 修改

阅读量1.4k

点赞数

分类专栏： Linux 安卓安全文章标签： linux 运维服务器

于 2023-02-04 04:07:26 首次发布

本文链接：https://blog.csdn.net/qq_39441603/article/details/128843256

版权

安卓安全同时被 2 个专栏收录

84 篇文章 13 订阅

订阅专栏

Linux

16 篇文章 0 订阅

订阅专栏

1.获得特权的两种方式

Linux中，特权任务（privileged tasks）可以通过两种方式执行：

Using SUID
Using capabilities

2.关于SUID

通过SUID拿到root权限，参考
https://blog.csdn.net/qq_39441603/article/details/125010004
https://blog.csdn.net/qq_39441603/article/details/124996277

3.关于Capabilities（权能）

在检查进程的权限时，EUID标识为0的进程被Linux认为是 root用户进程（特权进程），EUID标识为0的进程被Linux认为非特权进程。

特权进程通过所有内核权限检查，
非特权进程依据进程的EUID、EGID 和Supplementary Group等标识进行权限检查

SUID标识位虽然可以解决普通用户执行特权任务的问题，却带来了安全隐患：

某个设置了SUID标识位的可执行文件对应的进程，通常只需要root用户权限的一部分，但 SUID 给了它 root 用户的全部权限。因此一旦某个设置了SUID标识位的可执行文件被非法利用，则所有root权限都被攻击者获得，提高了攻击者的能力。

Linux 引入了 capabilities 机制对 root 权限进行细分，实现按需授权。

3.1 Linux capabilities概念

将与 root用户关联的权限划分为不同的单元，称为 Capability 。
Capability 可以作为进程的属性存在。每个Capability 可以独立启用和禁用。

检查进程权限的过程变成了：

如果进程的EUID是AID_ROOT，则进程拥有全部root权限
如果进程的EUID不是AID_ROOT，则检查进程是否有该操作所对应的 Capability
比如要向其他进程发送kill()信号，就得具有 Capability CAP_KILL；比如要设置系统时间，就得具有 Capability CAP_SYS_TIME
如果有，则允许；否则拒绝操作（报错Operation not permitted）

capability列表参见：
https://man7.org/linux/man-pages/man7/capabilities.7.html
https://www.cnblogs.com/sparkdev/p/11417781.html

capability 名称	描述
CAP_AUDIT_CONTROL	启用和禁用内核审计；改变审计过滤规则；检索审计状态和过滤规则
CAP_AUDIT_READ	允许通过 multicast netlink 套接字读取审计日志
CAP_AUDIT_WRITE	将记录写入内核审计日志
CAP_BLOCK_SUSPEND	使用可以阻止系统挂起的特性
CAP_CHOWN	修改文件所有者的权限
CAP_DAC_OVERRIDE	忽略文件的 DAC 访问限制
CAP_DAC_READ_SEARCH	忽略文件读及目录搜索的 DAC 访问限制
CAP_FOWNER	忽略文件属主 ID 必须和进程用户 ID 相匹配的限制
CAP_FSETID	允许设置文件的 setuid 位
CAP_IPC_LOCK	允许锁定共享内存片段
CAP_IPC_OWNER	忽略 IPC 所有权检查
CAP_KILL	允许对不属于自己的进程发送信号
CAP_LEASE	允许修改文件锁的 FL_LEASE 标志
CAP_LINUX_IMMUTABLE	允许修改文件的 IMMUTABLE 和 APPEND 属性标志
CAP_MAC_ADMIN	允许 MAC 配置或状态更改
CAP_MAC_OVERRIDE	覆盖 MAC(Mandatory Access Control)
CAP_MKNOD	允许使用 mknod() 系统调用
CAP_NET_ADMIN	允许执行网络管理任务
CAP_NET_BIND_SERVICE	允许绑定到小于 1024 的端口
CAP_NET_BROADCAST	允许网络广播和多播访问
CAP_NET_RAW	允许使用原始套接字
CAP_SETGID	允许改变进程的 GID
CAP_SETFCAP	允许为文件设置任意的 capabilities
CAP_SETPCAP	参考 capabilities man page
CAP_SETUID	允许改变进程的 UID
CAP_SYS_ADMIN	允许执行系统管理任务，如加载或卸载文件系统、设置磁盘配额等
CAP_SYS_BOOT	允许重新启动系统
CAP_SYS_CHROOT	允许使用 chroot() 系统调用
CAP_SYS_MODULE	允许插入和删除内核模块
CAP_SYS_NICE	允许提升优先级及设置其他进程的优先级
CAP_SYS_PACCT	允许执行进程的 BSD 式审计
CAP_SYS_PTRACE	允许跟踪任何进程
CAP_SYS_RAWIO	允许直接访问 /devport、/dev/mem、/dev/kmem 及原始块设备
CAP_SYS_RESOURCE	忽略资源限制
CAP_SYS_TIME	允许改变系统时钟
CAP_SYS_TTY_CONFIG	允许配置 TTY 设备
CAP_SYSLOG	允许使用 syslog() 系统调用
CAP_WAKE_ALARM	允许触发一些能唤醒系统的东西(比如 CLOCK_BOOTTIME_ALARM 计时器)

3.2 getcap 命令和 setcap 命令

举例：
ping 命令在执行时需要访问网络，这就需要获得 root 权限。常规的做法是通过 SUID 实现，这里改用capability实现。

ping 文件所需的 capabilities 为 cap_net_admin 和 cap_net_raw，通过 setcap 命令可以添加它们：

sudo setcap cap_net_admin,cap_net_raw+ep /bin/ping

命令中的 ep 分别表示 Effective 和 Permitted 集合，+ 号表示把指定的 capabilities 添加到这些集合中(对于 Effective 来说是设置位)。

被赋予合适的 capabilities 后，ping 命令又可以正常工作了。

如果要移除刚才添加的 capabilities，可以使用：

sudo setcap cap_net_admin,cap_net_raw-ep /bin/ping

- 号表示从集合中移除(对于 Effective 来说是清除位)。

相比 SUID 方案，ping文件只具有必要的特权，在最大程度上减小了系统的安全攻击面。

使用sudo find / -perm /u=s命令可以查找所有设置了setuid位的可执行文件。

3.3 进程的 capabilities与可执行文件的 capabilities

3.3.1 进程的 capabilities

对于进程来说，capabilities 是细分到线程的，即每个线程可以有自己的capabilities。

进程（线程）有5类 capabilities：

Permitted（cap_permitted）
定义了进程能够拥有的 capabilities 的上限。
- 不含CAP_SETPCAP的进程，只能往cap_inheritable中添加cap_permitted中有的capability。
- 不含CAP_SETPCAP的进程，只能丢掉cap_permitted中的capability，但不能向其中添加capability。
- 含CAP_SETPCAP的进程（UID为0），可以向cap_permitted中添加capability，但仍受规则约束。

Effective（cap_effective）
当前进程实际拥有的权能。内核检查进程是否可以进行特权操作时，检查的便是 cap_effective数组。

Inheritable （cap_inheritable）
父进程使用execve()执行可执行文件产生子进程时，子进程继承父进程的capability。

int execve(const char *pathname, char *const argv[],char*const envp[);
pathname :可执行文件的路径
argv :传递给程序的参数
envp∶传递给程序的新环境变量，无论是shell脚本，还是可执行文件都可以使用此环境变量

在这里插入图片描述

Bset（cap_bset）
用于限定进程从可执行文件中获取的capability。
Ambient
Linux 4.3 内核新增了一个 capabilities 集合叫 Ambient ，用来弥补 Inheritable 的不足。
- 非特权用户如果在 Permitted 集合中有一个 capability，那么可以添加到 Ambient 集合中，这样它的子进程便可以在 Ambient、Permitted 和 Effective 集合中获取这个 capability。

3.3.2 可执行文件的 capabilities

可执行文件有三类 capabilities：

Permitted：
在进程执行时，文件的Permitted Capabilites 自动被加入到进程的 Permitted Capabilites 中。
Inheritable：
Inheritable 集合中的 capabilites 会与进程的 Inheritable 集合执行与操作，以确定进程在执行 execve 函数后哪些 capabilites 被继承。
Effective：
Effective 只是一个 bit。如果设置为开启，那么在执行 execve 函数后，Permitted 集合中新增的 capabilities 会自动出现在进程的 Effective 集合中。

3.4 execve() 权能变化规则

execve()执行二进制文件，产生新进程。新进程的capability如下：
在这里插入图片描述

3.5 capability的实现

在进程的task_struct结构体中设置capability，capability取值需要计算。
在进程进行特权操作时，检查进程是否具有相应的capability，而不是判断是否为root用户

4. 安卓中的 capabilities

（1）在 Android 4.3 之前，app进程可以直接借助有SUID标志位的su二进制文件来获取root用户权限。
（2）Android 4.3之后，app进程基于SUID获取root权限的方案被禁用。主要措施是：

/system 和 /data 分区以 nosuid option被挂载，让文件的SUID标识失效。
app进程是由zygote 进程 fork产生的。zygote进程设置了NO_NEW_PRIVS标志，父进程的NO_NEW_PRIVS位会在父进程fork、clone和execve时，被子进程继承 ，并且不能被撤销。NO_NEW_PRIVS标志会让当前进程在执行可执行文件时，进程的EUID和EGID不受可执行文件的SUID和SGID位影响。

关于zygote进程fork出app进程的过程
参考：https://www.toutiao.com/article/6777894692462789124/

Android 4.3之后，/system 分区也被以 nosuid option被挂载；
那么，系统进程如何获取root权限呢？
app进程是否可以使用同样的方式呢？

（3）系统进程改用 Capability来获取root权限，但app进程不行。

系统daemon可通过可执行文件的capability来获取进程的cap_effective，
但app进程不能这样做，因为app进程是由zygote 进程fork出来的；而zygote进程设置了NO_NEW_PRIVS标志，使得app进程无法通过可执行文件的capability来获取cap_effective。

P’(ambient) = (file is privileged) ? 0 : P(ambient)
P’(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & P(bounding))) | P’(ambient)
P’(effective) = F(effective) ? P’(permitted) : P’(ambient)
也就是：
P’(effective) = F(effective) ? ( (P(inheritable) & F(inheritable)) | (F(permitted) & P(bounding))) | ( (file is privileged) ? 0 : P(ambient) ) ) : ( (file is privileged) ? 0 : P(ambient) )

NO_NEW_PRIVS标志会使SUID和SGID位无法改变进程的 uid 或 gid，file capability也不会被添加到进程的capability中。也就是NO_NEW_PRIVS标志会使获取root权限的 SUID方案和file capability方案失效。
参考：https://www.kernel.org/doc/html/latest/translations/zh_CN/userspace-api/no_new_privs.html

（4）对app进程切换EUID的其他限制：

仅当进程的cap_bset数组中有 SETUID/SETGID capability时，进程才能切换 UID。而从Android 4.4开始，zygote fork app进程时，会对所有fork出来的子进程进行CAPBSET_DROP动作，让子进程不具有任何capability。
从Android Oreo开始，OS通过SECCOMP过滤器阻止某些SYSCALL，app进程更改UID/GID的能力被进一步抑制。

（5）SELinux带来的约束
即使一个进程的euid变成了0，或者拥有了所有capability，它也必须受到SELinux策略的约束。
也就是，SELinux机制进一步约束了root权限进程的行为。

参考：https://forum.xda-developers.com/t/info-is-it-possible-to-install-windows-ios-or-linux-on-android-device.3763961/post-77437874
（#6）

《Linux Capabilities 简介》
https://www.cnblogs.com/sparkdev/p/11417781.html

《Linux Capabilities 入门教程：概念篇》
https://icloudnative.io/posts/linux-capabilities-why-they-exist-and-how-they-work/

很好的介绍capability的课件：
《Linux中的SetUid和capability权能机制》
https://zhuanlan.zhihu.com/p/484164795