Linux 提权方法与检查清单
Linux 提权不是机械地运行一份脚本，而是把“当前身份能够控制什么”与“高权限进程信任什么”连接起来。本页提供一套可重复的人工检查顺序，并把每类信号链接到 BeeHack 的专项分析和真实靶机案例。
以下命令用于自己的实验环境、靶场或明确授权的安全测试。生产系统应先确认变更窗口；验证时优先使用只读命令，不破坏账户、日志、任务和业务数据。
快速决策路径
1. 建立身份和系统基线
id
groups
uname -a
cat /etc/os-release
hostname
sudo -l
env
mount
ss -lntup
ps auxf
先回答四个问题：当前用户和组是什么、系统与内核版本是什么、哪些高权限服务在运行、当前身份能写入哪些被高权限进程使用的文件或目录。不要仅根据一个版本号直接判定存在漏洞。
2. sudo 规则与脚本逻辑
sudo -l 的价值不只在于寻找“可启动 Shell 的程序”。还要检查：
- 是否允许控制参数、输入文件、输出路径或环境变量；
- 允许执行的是二进制，还是可以被当前用户修改的脚本；
- 脚本是否依赖相对路径、通配符、临时文件或未引用变量；
- 是否通过用户可控数据拼接命令；
SETENV、NOPASSWD和命令参数限制是否符合预期。
专项方法可参考 sudo Shell 脚本逻辑缺陷 与 sudo GUI、X11 和辅助脚本。遇到归档任务时，还要检查 tar wildcard 注入。
3. SUID、SGID 与文件能力
find / -xdev -perm -4000 -type f 2>/dev/null
find / -xdev -perm -2000 -type f 2>/dev/null
getcap -r / 2>/dev/null
先把结果与发行版默认清单对比，重点关注自定义二进制、异常路径和近期变更。发现 SUID 程序后，不要只查程序名；还要分析它的参数、外部命令调用、文件访问和权限切换。详见 SUID 自定义二进制静态分析。
Capabilities 把传统 root 权限拆成更细粒度的能力。cap_setuid、cap_dac_read_search、cap_sys_admin 等出现在解释器或可扩展程序上时风险尤其高；判断与修复方法见 Linux Capabilities 提权。
4. 计划任务、服务和可写路径
cat /etc/crontab
find /etc/cron.* -maxdepth 1 -type f -ls 2>/dev/null
systemctl list-timers --all
systemctl list-units --type=service --state=running
find /usr/local /opt -writable -type f 2>/dev/null
检查高权限任务引用的脚本、工作目录、配置文件、日志目录和 PATH。风险通常来自“高权限进程执行了低权限用户可修改的内容”，而不是计划任务本身。还要注意符号链接、通配符、相对路径和不安全临时文件。
| 信号 | 需要验证的控制点 | 常见修复 |
|---|---|---|
| root cron 调用脚本 | 脚本及父目录是否可写 | root 所有、最小写权限、绝对路径 |
| 服务加载配置或插件 | 配置、插件目录是否可写 | 收紧所有权并固定加载路径 |
| 日志轮转/备份 | 通配符、符号链接、目标目录 | 安全参数、独立目录、拒绝跟随链接 |
| PATH 中可写目录 | 是否执行未写绝对路径的命令 | 固定 PATH 与命令绝对路径 |
5. 凭证与信任关系
在授权范围内检查应用配置、Shell 历史、部署脚本、备份、SSH 密钥、环境变量和本机监听服务。获得凭证后，应先确认其用途和权限，不要自动对范围外系统进行复用尝试。
find /var/www /opt /srv -type f \( -name '.env' -o -name '*.conf' -o -name '*.bak' \) 2>/dev/null
grep -RniE 'password|passwd|secret|token|api[_-]?key' /var/www /opt 2>/dev/null
命中结果可能是示例值、哈希或过期配置，需要结合进程参数、监听端口和文件时间线验证。Redis 等服务的配置泄露案例可参考 Redis 配置与凭据复用。
6. 自动化枚举用于补漏
LinPEAS 适合快速收集系统信息并突出异常项，但高亮不等于可利用。推荐顺序是：
- 先人工执行身份、
sudo -l、SUID、Capabilities 和进程检查； - 再运行 LinPEAS 补漏，并保存输出；
- 对每个候选项单独复核权限、版本和控制链；
- 只构造能够证明风险的最小化验证。
这样既能避免被大量低价值提示淹没，也便于解释“为什么这条路径成立”。
7. 内核、容器与挂载边界
内核漏洞应排在配置和权限问题之后，因为版本匹配可能受发行版回补影响，验证也更容易影响系统稳定性。先确认准确内核构建、发行版安全公告和实际修补状态。本站的 Copy Fail 内核提权分析 展示了从版本线索到可验证结论的过程。
容器环境还要检查当前 capabilities、挂载、Docker socket、宿主机设备和命名空间边界。发现 /var/run/docker.sock 或宿主机目录挂载时，首先判断是否为预期设计，并记录信任边界，不要直接对宿主机执行破坏性操作。
优先级检查表
| 优先级 | 检查项 | 判断依据 |
|---|---|---|
| P0 | sudo -l 与可写 sudo 脚本 | 权限链短、验证成本低 |
| P0 | 明文凭证、私钥、Token | 可能直接获得高权限身份 |
| P1 | 自定义 SUID/SGID、Capabilities | 系统默认项之外的异常能力 |
| P1 | root 计划任务和服务可写路径 | 低权限输入进入高权限执行 |
| P1 | 本机服务与信任关系 | 仅监听本机但权限较高的组件 |
| P2 | 内核或复杂竞态漏洞 | 需严格核对补丁并控制稳定性风险 |
常见误区
- 把 LinPEAS 的颜色当成漏洞结论，没有验证完整控制链。
- 只搜索 GTFOBins，忽略参数限制、自定义包装脚本和运行环境。
- 发现版本号就运行公开利用代码，未核对发行版补丁。
- 修改系统文件后不记录、不恢复，影响后续复盘。
- 获得 root 后只截图，不保存触发条件、证据和修复建议。
从真实靶机复盘学习
- Vault：哈希破解与 sudo 脚本逻辑
- Merge：sudo 逻辑与 Capabilities
- Phantom：LFI 到 SUID 二进制分析
- Longshao：服务枚举到 Linux 提权
- Calc：Web 利用链与内核提权
完整过程应记录：初始身份、关键命令、文件权限、触发前后差异、获得的权限、清理动作和防御建议。这样一条提权链才真正可复现、可审核、可修复。