Linux进程权限继承研究：从setuid()到exec()与system()的行为差异

1. 引言：权限凭证的四重身份

在Linux系统中，每个进程的身份远不止一个"用户ID"那么简单。为了支持临时提权、权限恢复以及最小特权原则，Linux内核为每个进程维护着一组复杂的凭证结构（struct cred）。理解这些凭证在各类系统调用中的传递与变换规则，是编写安全SUID程序、构建沙箱环境以及进行漏洞分析的基础。

1.1 进程的核心权限凭证

一个进程的权限身份由以下四个关键字段构成：

凭证类型	英文缩写	含义	典型作用
真实用户ID	RUID (Real UID)	标识"进程属于谁"	由登录用户决定，通常不可轻易改变
有效用户ID	EUID (Effective UID)	内核进行权限检查时使用的ID	最重要的权限凭证，决定能否访问文件、发送信号等
保存的set-user-ID	SUID (Saved Set-User-ID)	备份的有效用户ID	允许进程在EUID和RUID之间安全切换，是临时降权的关键
文件系统用户ID	FSUID (Filesystem UID)	专门用于文件系统访问检查	通常与EUID同步，主要用于NFS等场景

此外，现代Linux还引入了 能力集（Capabilities） 机制，将超级用户的全部特权分解为约40个独立的权限单元（如CAP_DAC_OVERRIDE用于绕过文件权限检查、CAP_NET_ADMIN用于网络配置等）。能力机制使得进程可以在不拥有完整root权限的情况下获得部分特权。

1.2 问题的提出

当一个普通用户（UID=1000）执行一个设置了SUID位且属主为root的程序时，进程的初始凭证状态为：

RUID = 1000（真实身份仍是普通用户）
EUID = 0（有效身份变为root）
SUID = 0（保存了root身份，便于后续恢复）

在这个初始状态下，程序可以通过各种系统调用执行其他程序。然而，不同的调用方式会导致完全不同的权限继承结果。本文将深入对比以下三种状态下的行为差异：

状态A ：不调用任何setuid()函数，保持初始SUID状态
状态B ：调用setuid(getuid())主动降权为普通用户（永久降权）
状态C ：调用setuid(0)将进程固化为完全的root身份

我们将逐一分析fork()、exec()家族、system()、popen()、posix_spawn()等系统调用和库函数在上述三种状态下的行为，揭示内核凭证管理的深层逻辑。

2. 核心机制：凭证变换与系统调用行为

2.1 三类进程状态的详细定义

假设一个SUID root程序（文件所有者root，且设置了chmod u+s权限位）由普通用户（UID=1000）启动。根据是否调用setuid()以及传递的参数，进程可能进入三种不同的状态：

状态编号	触发条件	RUID	EUID	SUID	可降权性	典型场景
状态A	不调用任何`setuid()`	1000	0	0	✅ 可通过`setuid(1000)`永久降权	程序需要临时提升权限执行特权操作
状态B	调用`setuid(getuid())` → `setuid(1000)`	1000	1000	1000	❌ 永久降权，无法恢复root	特权操作已完成，后续只需普通权限
状态C	调用`setuid(0)`	0	0	0	✅ 可以（因现在是真正root），但会"忘记"原始UID	程序需要永久保持root身份

2.2 核心权限变换流程图

下图展示了三种状态下，进程执行fork()、system()和exec()时的完整凭证变换路径：
#mermaid-svg-oM4b0daZwRjrgRtS{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-oM4b0daZwRjrgRtS .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-oM4b0daZwRjrgRtS .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-oM4b0daZwRjrgRtS .error-icon{fill:#552222;}#mermaid-svg-oM4b0daZwRjrgRtS .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-oM4b0daZwRjrgRtS .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-oM4b0daZwRjrgRtS .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-oM4b0daZwRjrgRtS .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-oM4b0daZwRjrgRtS .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-oM4b0daZwRjrgRtS .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-oM4b0daZwRjrgRtS .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-oM4b0daZwRjrgRtS .marker{fill:#333333;stroke:#333333;}#mermaid-svg-oM4b0daZwRjrgRtS .marker.cross{stroke:#333333;}#mermaid-svg-oM4b0daZwRjrgRtS svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-oM4b0daZwRjrgRtS p{margin:0;}#mermaid-svg-oM4b0daZwRjrgRtS .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-oM4b0daZwRjrgRtS .cluster-label text{fill:#333;}#mermaid-svg-oM4b0daZwRjrgRtS .cluster-label span{color:#333;}#mermaid-svg-oM4b0daZwRjrgRtS .cluster-label span p{background-color:transparent;}#mermaid-svg-oM4b0daZwRjrgRtS .label text,#mermaid-svg-oM4b0daZwRjrgRtS span{fill:#333;color:#333;}#mermaid-svg-oM4b0daZwRjrgRtS .node rect,#mermaid-svg-oM4b0daZwRjrgRtS .node circle,#mermaid-svg-oM4b0daZwRjrgRtS .node ellipse,#mermaid-svg-oM4b0daZwRjrgRtS .node polygon,#mermaid-svg-oM4b0daZwRjrgRtS .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-oM4b0daZwRjrgRtS .rough-node .label text,#mermaid-svg-oM4b0daZwRjrgRtS .node .label text,#mermaid-svg-oM4b0daZwRjrgRtS .image-shape .label,#mermaid-svg-oM4b0daZwRjrgRtS .icon-shape .label{text-anchor:middle;}#mermaid-svg-oM4b0daZwRjrgRtS .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-oM4b0daZwRjrgRtS .rough-node .label,#mermaid-svg-oM4b0daZwRjrgRtS .node .label,#mermaid-svg-oM4b0daZwRjrgRtS .image-shape .label,#mermaid-svg-oM4b0daZwRjrgRtS .icon-shape .label{text-align:center;}#mermaid-svg-oM4b0daZwRjrgRtS .node.clickable{cursor:pointer;}#mermaid-svg-oM4b0daZwRjrgRtS .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-oM4b0daZwRjrgRtS .arrowheadPath{fill:#333333;}#mermaid-svg-oM4b0daZwRjrgRtS .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-oM4b0daZwRjrgRtS .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-oM4b0daZwRjrgRtS .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-oM4b0daZwRjrgRtS .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-oM4b0daZwRjrgRtS .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-oM4b0daZwRjrgRtS .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-oM4b0daZwRjrgRtS .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-oM4b0daZwRjrgRtS .cluster text{fill:#333;}#mermaid-svg-oM4b0daZwRjrgRtS .cluster span{color:#333;}#mermaid-svg-oM4b0daZwRjrgRtS div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-oM4b0daZwRjrgRtS .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-oM4b0daZwRjrgRtS rect.text{fill:none;stroke-width:0;}#mermaid-svg-oM4b0daZwRjrgRtS .icon-shape,#mermaid-svg-oM4b0daZwRjrgRtS .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-oM4b0daZwRjrgRtS .icon-shape p,#mermaid-svg-oM4b0daZwRjrgRtS .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-oM4b0daZwRjrgRtS .icon-shape .label rect,#mermaid-svg-oM4b0daZwRjrgRtS .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-oM4b0daZwRjrgRtS .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-oM4b0daZwRjrgRtS .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-oM4b0daZwRjrgRtS :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 不调用 (状态A)
setuid(1000) (状态B)
setuid(0) (状态C)
SUID root 程序启动

RUID=1000, EUID=0, SUID=0
是否调用 setuid?
状态A

R=1000, E=0, S=0

进程拥有 root 有效权限
状态B

R=1000, E=1000, S=1000

进程降权为普通用户
状态C

R=0, E=0, S=0

进程固化为 root
fork() → 子进程继承相同凭证

(R=1000,E=0)
system() → 子进程 exec /bin/sh

shell检测 E!=R → 主动 setuid(R)
最终 EUID=1000

命令以普通用户运行
exec(普通程序)
新程序 EUID=0

继承父进程的 root 权限
exec(SUID root程序)
新程序 EUID=0

SUID触发，但已是root
fork() → 子进程继承相同凭证

(R=1000,E=1000)
system() → shell检测 E==R

不做任何降权
最终 EUID=1000

全程普通用户
exec(普通程序)
新程序 EUID=1000

保持普通用户权限
exec(SUID root程序)
⚠️ 新程序 EUID=0

SUID触发，重新提权！
fork() → 子进程继承相同凭证

(R=0,E=0)
system() → shell检测 E==R==0

不会降权
最终 EUID=0

命令以 root 运行
exec(任意程序)
新程序 EUID=0

始终以 root 运行

图例说明：

🟡 黄色节点：状态A的结果（依赖shell降权，有风险）
🟢 绿色节点：状态B的结果（安全，但需警惕exec(SUID root)的重新提权）
🔴 红色节点：状态C的结果（高危，所有操作都以root执行）
🔴🔴 深红色节点：最危险的行为模式

2.3 `setuid()` 系统调用的语义规则

setuid(uid)的行为取决于调用前的有效用户ID（EUID），这是理解所有后续行为的基础：

调用前 EUID	调用前 RUID	`setuid(uid)` 行为	返回值
0 (root)	任意	无条件将 RUID、EUID、SUID 全部设置为 `uid`	0（成功）
非 0	`uid` == 调用前 RUID	仅将 EUID 设置为 `uid`（切换到saved UID）	0（成功）
非 0	`uid` != 调用前 RUID	无变化	-1（EPERM，操作不允许）

关键洞察：

当进程处于状态A（EUID=0，RUID=1000）时，调用setuid(1000)会使进程进入状态B，此时所有三个UID都变为1000，进程永久失去root权限。
同样从状态A调用setuid(0)会使进程进入状态C，此时所有三个UID都变为0，进程固化为真正的root，同时"忘记"了原始用户ID 1000。
从状态B（EUID=1000）调用setuid(0)会失败并返回EPERM，因为非root进程无权将自己的EUID提升为0。
从状态C（EUID=0，RUID=0）调用setuid(1000)会使进程进入类似状态B的状态（R=E=S=1000），此时进程永久降权。

3. 系统调用行为详细分析

3.1 `fork()`：凭证的完美克隆

fork()系统调用用于创建一个新的进程（子进程），它是父进程的副本。在权限继承方面，fork()的行为在所有三种状态下完全一致。

核心行为：

子进程获得父进程凭证的完整副本 ，包括RUID、EUID、SUID、能力集、no_new_privs标志、命名空间等所有属性。
没有任何权限检查或变换------子进程与父进程在凭证上完全等同。
这是fork()与exec()的重要区别：fork()只复制，不改变；而exec()可能改变凭证。

示例代码：

c 复制代码

// 假设当前进程处于状态A (R=1000, E=0)
pid_t pid = fork();
if (pid == 0) {
    // 子进程同样拥有 (R=1000, E=0)
    printf("Child: RUID=%d, EUID=%d\n", getuid(), geteuid());
    // 输出: Child: RUID=1000, EUID=0
}

三种状态下的表现：

父进程状态	fork() 后子进程的凭证	说明
状态A (R=1000, E=0)	完全相同 (R=1000, E=0)	子进程继承root有效权限
状态B (R=1000, E=1000)	完全相同 (R=1000, E=1000)	子进程为普通用户
状态C (R=0, E=0)	完全相同 (R=0, E=0)	子进程为root

3.2 `exec()` 家族：权限重新计算的唯一入口

exec()系列函数（包括execl、execlp、execle、execv、execvp、execvpe）用于在当前进程中加载并执行一个新的程序。它们是唯一能够改变进程权限的系统调用。

核心行为：

exec()会替换当前进程的代码段、数据段、堆栈等，但保留进程ID、父进程关系、文件描述符等。
在执行新程序之前，内核会根据目标文件的属性重新计算进程的凭证。

SUID位的处理规则：

复制代码

if (目标文件设置了SUID位) {
    新进程的EUID = 文件所有者的UID;
} else {
    新进程的EUID = 调用者当前的EUID;
}
// RUID 保持不变，除非通过其他机制改变
// SUID 被设置为新进程的 EUID（用于后续可能的降权恢复）

三种状态下的详细表现：

当前状态	执行普通程序（无SUID）后的EUID	执行SUID root程序后的EUID	风险等级
状态A (R=1000, E=0)	0（保持父进程的root权限）	0（SUID触发，但已经是0）	🟡 中等（非预期root权限传播）
状态B (R=1000, E=1000)	1000（保持普通用户）	0（SUID触发，重新提权！）	🔴 高危
状态C (R=0, E=0)	0（保持root）	0（保持root）	🔴 高危（永久root）

最危险的发现 ：

状态B中，虽然进程主动降权为普通用户（R=E=S=1000），但后续exec()一个SUID root程序时，权限会重新提升为root！这是最容易被开发者忽视的安全漏洞。例如：

c 复制代码

// 危险示例：看似安全的代码实际上存在提权风险
int main() {
    // 完成所有特权操作后主动降权
    setuid(getuid());  // 现在 R=E=S=1000
    
    // ... 一些普通操作 ...
    
    // 危险：如果 some_tool 是 SUID root 程序，这里会重新提权！
    execl("/usr/bin/some_tool", "some_tool", NULL);
}

3.3 `system()`：shell的主动降权机制

system()是C标准库函数，并非系统调用。其典型实现（glibc）为：

c 复制代码

int system(const char *command) {
    pid_t pid = fork();
    if (pid == 0) {
        // 子进程
        execl("/bin/sh", "sh", "-c", command, NULL);
        _exit(127);
    }
    // 父进程等待子进程结束
}

关键点 ：system()不直接执行目标命令，而是启动一个POSIX兼容的shell（通常是/bin/sh，在现代Linux中指向bash或dash），然后由shell解析并执行命令字符串。

Shell的安全策略 ：

现代shell（bash 2.0+、dash）在启动时会执行以下检查：

c 复制代码

// shell 内部伪代码
if (geteuid() != getuid()) {
    // 检测到处于 SUID/SGID 状态
    setuid(getuid());   // 主动降权到真实用户
    setgid(getgid());
    // 同时会忽略环境变量中的潜在危险变量（LD_PRELOAD、LD_LIBRARY_PATH等）
}

这一安全机制是为了防止通过shell执行命令时意外继承过高权限，从而被攻击者利用。

三种状态下的表现：

当前状态	system()调用前的凭证	shell启动检测	命令执行时的EUID	说明
状态A	R=1000, E=0	E!=R → 触发降权	1000（普通用户）	依赖shell降权，存在微小时间窗口
状态B	R=1000, E=1000	E==R → 不降权	1000（普通用户）	进程本身已是普通用户
状态C	R=0, E=0	E==R → 不降权	0（root）	极其危险，所有命令以root执行

关键洞察：

状态A和状态B的system()最终都以普通用户 运行命令，但原因完全不同：
- 状态A：依赖shell主动降权（存在微小的安全窗口）
- 状态B：进程本身已经是普通用户
状态C的system()会以root身份执行任意shell命令，这是灾难性的安全隐患。
状态A虽然最终结果安全，但在fork()之后、shell执行setuid()之前，子进程短暂地以root权限运行shell代码。虽然这个窗口极窄（微秒级），但在极端情况下可能被利用（例如通过ptrace()或竞争条件）。

3.4 `exec*` 中的PATH搜索变体：`execlp()`与`execvp()`

execlp()和execvp()是exec()家族的变体，它们在exec()的基础上增加了PATH环境变量搜索 功能。对于SUID程序，这是一个重大安全陷阱。

行为差异：

execl() / execv()：需要提供完整的文件路径
execlp() / execvp()：如果文件路径不包含斜杠/，则在PATH环境变量指定的目录列表中搜索

安全风险示例：

c 复制代码

// 危险的SUID程序代码片段
int main() {
    // ... 假设程序处于状态A (EUID=0) ...
    
    // 危险：没有使用完整路径，依赖PATH搜索
    execvp("some_command", args);
}

攻击路径：

攻击者创建一个恶意程序，命名为some_command
攻击者设置PATH环境变量，将包含恶意程序的目录放在搜索路径前面：export PATH=/tmp/evil:$PATH
当SUID程序执行execvp("some_command", args)时，系统会先搜索/tmp/evil/some_command
由于SUID程序当前EUID=0，恶意程序将以root权限执行

防御措施：

c 复制代码

// 安全做法1：使用绝对路径
execv("/bin/some_command", args);

// 安全做法2：在执行前清理PATH环境变量
clearenv();  // 或 unsetenv("PATH");
setenv("PATH", "/bin:/usr/bin", 1);
execvp("some_command", args);

三种状态下的风险评估：

当前状态	`execlp()`/`execvp()` 的风险	说明
状态A (EUID=0)	🔴 极高	攻击者可控制PATH导致任意程序以root执行
状态B (EUID=1000)	🟢 较低	即使执行恶意程序，也只是普通用户权限
状态C (EUID=0,RUID=0)	🔴 极高	同状态A，且无法通过降权缓解

3.5 `popen()`：带管道的`system()`

popen()函数类似于system()，但它创建一个管道用于读取命令的输出或向命令发送输入。其实现通常也是fork() + exec() shell。

行为：与system()在权限处理上完全一致，因为底层都是通过shell执行命令。

c 复制代码

FILE *fp = popen("some_command", "r");
// 权限行为与 system() 相同：
// - 状态A：shell降权，命令以普通用户运行
// - 状态B：命令以普通用户运行
// - 状态C：命令以root运行

3.6 `posix_spawn()`：`fork()`+`exec()`的封装

posix_spawn()是POSIX标准中定义的函数，用于在不需要处理fork()复杂性的场景下创建新进程。它本质上是fork()+exec()的组合，但有一个关键差异。

关键差异 ：

posix_spawn()允许通过posix_spawn_file_actions_t在fork()之后、exec()之前执行文件描述符操作（如重定向、关闭等），而这些操作发生在子进程凭证尚未变化的时候。

安全影响：

如果父进程处于状态A（EUID=0），posix_spawn()创建的子进程在文件操作阶段仍然拥有root权限
这可能导致意外的权限泄露（例如将一个root权限打开的文件描述符泄露给子进程，或通过重定向覆盖受保护的文件）

c 复制代码

// 危险示例
posix_spawn_file_actions_t actions;
posix_spawn_file_actions_addopen(&actions, 1, "/etc/shadow", O_WRONLY, 0);
// 如果处于状态A，文件操作以root身份执行，可以打开 /etc/shadow
posix_spawn(&pid, "/bin/echo", &actions, NULL, argv, environ);

4. 对比分析：所有组合的权限结果矩阵

4.1 系统调用权限继承总览表

下表汇总了所有系统调用/库函数在三种状态下的行为结果：

系统调用/函数	状态A (R=1000,E=0)	状态B (R=1000,E=1000)	状态C (R=0,E=0)
`fork()`	子进程继承 (R=1000,E=0)	子进程继承 (R=1000,E=1000)	子进程继承 (R=0,E=0)
`exec(普通程序)`	新程序 EUID=0	新程序 EUID=1000	新程序 EUID=0
`exec(SUID root)`	新程序 EUID=0	新程序 EUID=0 ⚠️	新程序 EUID=0
`system()` / `popen()`	命令以 EUID=1000 运行（shell主动降权）	命令以 EUID=1000 运行	命令以 EUID=0 运行（root）
`execlp()` / `execvp()`	🔴 高危（PATH劫持）	🟢 相对安全（已是普通用户）	🔴 高危（PATH劫持）
`posix_spawn()`	文件操作阶段仍为root	文件操作阶段为普通用户	文件操作阶段为root
`setuid(1000)`	变为状态B	已经是状态B	变为 (R=1000,E=1000,S=1000)
`setuid(0)`	变为状态C	失败（EPERM）	已经是状态C
`seteuid(1000)`	EUID变为1000 R=1000,S=0	EUID变为1000 （无变化）	EUID变为1000 R=0,S=0
`seteuid(0)`	EUID保持0（已是root）	失败（EPERM）	EUID保持0
`setreuid(1000,0)`	R=1000,E=0（恢复状态A）	无意义	R=1000,E=0

4.2 风险等级标记

标记	含义	典型场景
🔴 极高风险	可能导致以root权限执行任意代码	状态A + `execlp()`、状态C + `system()`
🔴 高风险	可能意外提权或权限泄露	状态B + `exec(SUID root)`
🟡 中等风险	存在理论上的安全窗口，但利用难度高	状态A + `system()`
🟢 低风险	攻击面有限，但仍需谨慎	状态B + `execlp()`
✅ 安全	预期行为，无意外提权	状态B + `exec(普通程序)`

4.3 安全漏洞模式总结

漏洞模式1：状态A + execlp()/execvp()

问题：PATH环境变量劫持
后果：攻击者可以以root权限执行任意程序
防御：使用绝对路径或提前清理PATH

漏洞模式2：状态B + exec(SUID root)

问题：降权后忘记SUID程序会重新提权
后果：攻击者可能控制SUID程序的参数或环境，导致意外提权
防御：降权后避免执行SUID程序，或使用exec()调用非SUID的包装程序

漏洞模式3：状态C + system()

问题：永久root权限下的shell执行
后果：任何命令都会以root身份执行，攻击面极大
防御：避免在root进程中调用system()，或先降权再调用

漏洞模式4：状态A + posix_spawn() 文件操作

问题：文件操作阶段持有root权限
后果：可能覆盖受保护文件或泄露敏感文件描述符
防御：在posix_spawn()前降权，或使用fork()+exec()手动控制

5. 高级话题：能力集、`no_new_privs`与命名空间

5.1 能力集（Capabilities）：细粒度的权限控制

现代Linux中，UID检查已经不是唯一的权限来源。能力集机制将root的全权分解为独立的能力单元，使得进程可以在不拥有完整root权限的情况下获得部分特权。

关键能力示例：

CAP_DAC_OVERRIDE：绕过文件读/写/执行权限检查
CAP_NET_ADMIN：执行网络管理操作
CAP_SYS_ADMIN：执行大量系统管理操作（通常被视为"全能"能力）
CAP_SETUID：允许任意操纵进程的UID（setuid()、seteuid()等）

能力继承的独立公式 ：

当进程执行exec()时，能力集的变换遵循独立于UID的规则：

复制代码

P_new = (P_file & P_proc_old) | (I_proc_old & I_file)
E_new = E_file ? P_new : (P_new & E_file)
I_new = I_proc_old & I_file

其中：

P：Permitted集合（进程能够拥有的最大能力集）
E：Effective集合（当前生效的能力集）
I：Inheritable集合（能够传递给子进程的能力集）

三种状态下的能力集特征：

状态	默认能力集	是否可主动限制	说明
状态A (EUID=0,RUID=1000)	完整能力集	✅ 是（通过`cap_set_proc()`）	传统root权限的等价物
状态B (EUID=1000)	空能力集	不适用	普通用户，无特权能力
状态C (EUID=0,RUID=0)	完整能力集	❌ 否（除非主动限制）	真正的root，不可剥夺

实践意义 ：

即使处于状态A（EUID=0），如果程序提前限制了自身的能力集（例如删除CAP_SYS_ADMIN），那么即使后续执行了危险的系统调用，也不会造成灾难性后果。这是实现"最小特权原则"的重要工具。

5.2 `no_new_privs`标志：所有权限继承的终结者

no_new_privs是Linux内核提供的一个进程标志位，通过prctl()系统调用设置：

c 复制代码

prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);

行为：

一旦设置no_new_privs标志，该进程及其所有子进程（通过fork()继承）将：

忽略SUID位和SGID位
忽略文件能力（File Capabilities）
禁止任何形式的权限提升
新进程的EUID始终等于调用者的RUID（无法变得更高）

对三种状态的影响：

设置前状态	设置后 `exec(SUID root)` 的行为	说明
状态A (EUID=0)	新程序 EUID=1000（降权！）	原本会保持root，现在被强制降权
状态B (EUID=1000)	新程序 EUID=1000（不变）	原本就是普通用户，无变化
状态C (EUID=0,RUID=0)	新程序 EUID=0（但能力受限）	RUID=0意味着没有"更低"的身份可降

应用场景：

容器和沙箱 ：Docker、runc、Firecracker等容器运行时在启动容器进程时会设置no_new_privs，防止容器内的SUID程序逃逸
Seccomp过滤：与Seccomp结合构建安全的沙箱环境
SUID程序内部：SUID程序可以在完成必要特权操作后设置此标志，防止后续意外提权

5.3 命名空间（Namespaces）：隔离的权限视图

Linux命名空间机制使得进程可以拥有与其他进程不同的系统视图，包括：

User namespace：允许非特权进程拥有该命名空间内的root权限
Mount namespace：独立的文件系统挂载视图
PID namespace：独立的进程ID空间

权限继承与命名空间的交互：

setuid()在用户命名空间内部的行为与全局不同------在用户命名空间内拥有root权限（ns_capable）并不等同于全局root权限。
exec()时的SUID检查在用户命名空间内仍然生效，但检查的是命名空间内的文件所有者。
no_new_privs标志对命名空间同样有效，是构建安全容器的关键组件。

6. 实战指南：安全编程检查清单

6.1 编写SUID程序前的决策树

在决定编写SUID程序之前，请考虑以下问题：

复制代码

是否确实需要SUID？
├── 是 → 能否用 Linux Capabilities 替代？
│   ├── 是 → 使用 setcap 为文件添加特定能力
│   └── 否 → 能否用 sudo + 精确授权替代？
│       ├── 是 → 配置 /etc/sudoers
│       └── 否 → 继续使用SUID，但必须遵循安全清单
└── 否 → 使用普通权限运行

6.2 SUID程序安全编程清单

在编写SUID程序时，请逐项检查以下要点：

6.2.1 启动阶段（进入main函数后立即执行）

清理环境变量

c 复制代码

// 删除危险环境变量
unsetenv("LD_PRELOAD");
unsetenv("LD_LIBRARY_PATH");
unsetenv("LD_DEBUG");
unsetenv("GCONV_PATH");
unsetenv("GETCONF_DIR");
unsetenv("HOSTALIASES");
unsetenv("RES_OPTIONS");
unsetenv("LOCALDOMAIN");

// 重置PATH和IFS
setenv("PATH", "/bin:/usr/bin", 1);
unsetenv("IFS");

切换到安全的工作目录
c 复制代码
```
chdir("/");
```

重置信号处理

c 复制代码

// 忽略所有可能造成干扰的信号
signal(SIGPIPE, SIG_DFL);
// 或使用 sigaction 重置所有信号处理函数

6.2.2 权限管理

确定是否需要永久降权

c 复制代码

// 如果需要永久放弃特权
setuid(getuid());   // 进入状态B
// 此后无法恢复root权限

确定是否需要临时降权

c 复制代码

// 保存原始UID
uid_t original_euid = geteuid();

// 临时降权
seteuid(getuid());  // EUID变为普通用户

// 执行不需要特权的操作

// 恢复特权
seteuid(original_euid);

考虑使用能力集替代UID切换

c 复制代码

// 初始化能力集
cap_t caps = cap_init();
cap_set_flag(caps, CAP_EFFECTIVE, 1, &CAP_DAC_OVERRIDE, CAP_SET);
cap_set_proc(caps);
cap_free(caps);

6.2.3 执行外部程序

避免使用 system() 和 popen()
- 如果必须使用，请先永久降权到状态B
- 优先使用 fork() + exec() 直接调用

使用绝对路径调用 exec()

c 复制代码

// 正确：使用绝对路径
execl("/bin/cat", "cat", file, NULL);

// 错误：依赖PATH
execlp("cat", "cat", file, NULL);

如果必须使用 execlp()/execvp()，先清理PATH

c 复制代码

setenv("PATH", "/bin:/usr/bin", 1);
execvp("some_command", args);

在fork()子进程中主动降权

c 复制代码

pid_t pid = fork();
if (pid == 0) {
    // 子进程：立即降权
    setuid(getuid());
    // 现在可以安全执行外部程序
    execlp("some_command", "some_command", NULL);
    _exit(127);
}

6.2.4 文件操作

避免使用 access() 进行权限检查
- access()使用RUID，而实际open()使用EUID
- 直接尝试open()并根据错误码判断

打开文件后立即丢弃不必要的权限

c 复制代码

int fd = open("/etc/shadow", O_RDONLY);
if (fd != -1) {
    // 成功打开后立即降权
    setuid(getuid());
    // 现在可以安全地处理文件内容
    read(fd, buffer, size);
}

6.2.5 进阶防护

考虑设置 no_new_privs 标志

c 复制代码

#include <sys/prctl.h>

// 在所有特权操作完成后
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
// 此后任何 `exec()` 都不会提升权限

使用 Seccomp 过滤危险的系统调用

c 复制代码

// 禁止 execve、ptrace 等危险调用
// 具体实现较复杂，可参考 libseccomp 库

6.3 常见反模式与修正

反模式	问题描述	正确做法
`system("command")` 在SUID程序中	shell降权有窗口，且依赖外部shell	使用`fork()`+`exec()`直接调用
`execlp("command", ...)`	PATH劫持风险	使用绝对路径`/bin/command`
降权后调用`exec(SUID程序)`	重新提权，违背降权意图	降权后避免执行SUID程序
使用`access()`检查文件权限	TOCTOU漏洞，且检查的是RUID	直接`open()`，根据错误码处理
不清理环境变量	LD_PRELOAD等环境变量可劫持	在main开头清理所有危险环境变量
在chroot前未降权	chroot内部可能逃逸	先chroot，再chdir("/")，最后降权

7. 总结：理解凭证，掌控权限

7.1 核心结论

Linux进程权限继承的复杂性源于其设计目标：在兼容传统UNIX SUID模型 与支持现代最小特权原则之间寻求平衡。通过对本文的全面分析，我们可以提炼出以下核心结论：

铁律一：fork() 不做任何权限决策

fork()仅仅是凭证的完美复制，子进程与父进程在权限上完全等同。
权限变化的唯一入口是exec()。

铁律二：exec() 是唯一能改变权限的系统调用

exec()会根据目标文件的SUID位和文件能力重新计算EUID。
即使进程已经降权为普通用户（状态B），exec(SUID root程序)仍然会重新提权。

铁律三：system() 不是系统调用，不应依赖其行为

system()的权限行为由/bin/sh的安全策略决定，不同shell可能有差异。
状态A下的system()依赖shell主动降权，存在理论上的安全窗口。

铁律四：降权后不一定安全，提权后可能永久固化

setuid(getuid())使进程进入状态B：R=E=S=普通用户，永久失去特权。
setuid(0)使进程进入状态C：R=E=S=0，固化为真正的root。
状态B下执行SUID root程序会重新提权------这是最容易被忽视的漏洞。

7.2 安全设计原则

基于本文的分析，提出以下安全设计原则：

最小特权原则
- 只在必要时才持有特权，特权操作完成后立即降权。
- 优先使用Linux Capabilities而非完整的SUID root。
深度防御原则
- 不要依赖单一的防御机制。即使降权后，也要清理环境变量。
- 使用no_new_privs作为安全后备。
显式优于隐式
- 避免依赖system()的隐式降权行为。
- 使用fork()+exec() + 显式的子进程降权。
可审计性原则
- SUID程序应该尽可能短小精悍，便于安全审计。
- 避免在SUID程序中处理复杂的用户输入。

7.3 现代替代方案

最佳实践：不要编写新的SUID程序

以下现代替代方案应优先考虑：

替代方案	适用场景	优点	缺点
Linux Capabilities + 文件能力	程序只需要特定权限（如`CAP_NET_RAW`）	最小特权，审计简单	某些老旧系统不支持
sudo + 精确授权	用户需要以root执行特定命令	细粒度控制，有审计日志	需要配置/etc/sudoers
特权守护进程 + UNIX域套接字	需要复杂的权限切换	完全可控，可加认证	实现复杂度高
User Namespace + 能力限制	容器或沙箱环境	隔离性好，无需全局root	对内核版本有要求

7.4 最终寄语

SUID机制是Linux权限模型中最锋利的工具------它诞生于一个信任边界清晰的时代，却在现代复杂的安全环境中显得力不从心。正如内核开发者Andy Lutomirski所言：

"SUID是遗留的伤疤，能力集是绷带，而no_new_privs是真正的治愈。"

理解进程权限的继承规则，不仅仅是为了避免漏洞，更是为了超越SUID本身。当我们能够清晰地回答以下问题时，才算真正掌握了这个主题：

为什么system()在SUID程序中的行为与直接exec()不同？
为什么setuid(getuid())后执行SUID root程序仍然可能提权？
为什么execlp()在SUID程序中使用是危险的？
如何在不依赖shell的情况下安全地执行外部程序？

本文通过系统化的对比分析，为这些问题提供了完整的答案。希望这份研究能够帮助开发者编写更安全的系统程序，也帮助安全研究人员更好地理解Linux权限模型的内在逻辑。

权限继承的本质，是信任的传递与限制。理解它，是为了更好地限制它。

Linux进程权限继承研究：从setuid()到exec()与system()的行为差异

1. 引言：权限凭证的四重身份

1.1 进程的核心权限凭证

1.2 问题的提出

2. 核心机制：凭证变换与系统调用行为

2.1 三类进程状态的详细定义

2.2 核心权限变换流程图

2.3 setuid() 系统调用的语义规则

3. 系统调用行为详细分析

3.1 fork()：凭证的完美克隆

3.2 exec() 家族：权限重新计算的唯一入口

3.3 system()：shell的主动降权机制

3.4 exec* 中的PATH搜索变体：execlp()与execvp()

3.5 popen()：带管道的system()

3.6 posix_spawn()：fork()+exec()的封装

4. 对比分析：所有组合的权限结果矩阵

4.1 系统调用权限继承总览表

4.2 风险等级标记

4.3 安全漏洞模式总结

5. 高级话题：能力集、no_new_privs与命名空间

5.1 能力集（Capabilities）：细粒度的权限控制

5.2 no_new_privs标志：所有权限继承的终结者

5.3 命名空间（Namespaces）：隔离的权限视图

6. 实战指南：安全编程检查清单

6.1 编写SUID程序前的决策树

6.2 SUID程序安全编程清单

6.2.1 启动阶段（进入main函数后立即执行）

6.2.2 权限管理

6.2.3 执行外部程序

6.2.4 文件操作

6.2.5 进阶防护

6.3 常见反模式与修正

7. 总结：理解凭证，掌控权限

7.1 核心结论

7.2 安全设计原则

7.3 现代替代方案

7.4 最终寄语

2.3 `setuid()` 系统调用的语义规则

3.1 `fork()`：凭证的完美克隆

3.2 `exec()` 家族：权限重新计算的唯一入口

3.3 `system()`：shell的主动降权机制

3.4 `exec*` 中的PATH搜索变体：`execlp()`与`execvp()`

3.5 `popen()`：带管道的`system()`

3.6 `posix_spawn()`：`fork()`+`exec()`的封装

5. 高级话题：能力集、`no_new_privs`与命名空间

5.2 `no_new_privs`标志：所有权限继承的终结者