为什么 Linux sudo 越来越危险?这三个替代方案可以试试

在 Linux 系统管理中，sudo 几乎是每个管理员和开发者每天都会用到的工具。它让普通用户能够临时提升权限执行命令，极大地方便了日常运维。然而，随着攻击技术的演进，sudo 本身的安全问题也越来越受到关注。它的庞大代码量和对 setuid 机制的依赖，构成了潜在的风险点。

sudo 自 1980 年代诞生以来，已经服务了数十年的 Unix-like 系统。它功能强大、生态成熟，但也积累了显著的缺点。首先是代码规模。根据公开数据，sudo 的核心代码超过 10 万行，这意味着庞大的攻击面。复杂代码中隐藏的漏洞往往难以被彻底排查，历史上的多个 CVE 就证明了这一点。

其次是 setuid 机制。setuid 位允许可执行文件以文件所有者（通常是 root）的权限运行。当普通用户执行 sudo 时，程序以 root 身份运行，如果程序存在内存损坏、缓冲区溢出等漏洞，攻击者就能实现权限提升。这类本地权限提升攻击是许多系统入侵链条的重要一环。

面对这些问题，社区提出了不同思路：通过更安全的实现、更小的代码量、内存安全语言重写，或者彻底改变系统架构实现隔离。以下三个替代方案分别代表了这些方向。

run0

第一个值得关注的方案是 run0，它从 systemd 256 版本开始内置。作为 systemd 生态的一部分，run0 的设计理念与传统 sudo 完全不同。

传统 sudo 通过 setuid 直接让子进程继承特权上下文，而 run0 则借助 polkit（PolicyKit）策略守护进程来实现细粒度权限控制。polkit 允许管理员制定更精确的授权规则，例如根据用户、时间、命令等条件动态决策。

更重要的是，run0 在执行命令时会创建一个伪终端（PTY），将新进程隔离在独立的环境中。环境变量、cgroup、文件描述符、安全上下文等都不会直接继承，这显著降低了上下文泄露的风险。同时，它避免了 setuid 带来的固有问题。

实际使用中，run0 的命令形式与 sudo 类似：

run0 whoami  # 以 root 权限执行

对于交互式会话，可以使用：

run0 --pty bash

run0 的优势在于开箱即用——大多数采用较新 systemd 的发行版（如 Fedora、Arch、Ubuntu 新版本）都可以直接使用，无需额外安装。但它也有一些当前的小缺点，比如默认不缓存凭证，每次连续执行都会重新提示输入密码。这在某些自动化场景中可能稍显不便，不过通过配置 polkit 规则可以进一步优化。

总体来说，run0 代表了“从机制上革新”的方向。它不只是替换工具，更是在尝试用现代服务管理理念重构权限提升流程。

sudo-rs

第二个方案是 sudo-rs，这是一个由 Trifecta Tech Foundation 开发、现已被 Canonical 采用的 Rust 重写项目。Canonical 正在推进 Ubuntu 的“氧化”（Rustification）计划，sudo-rs 是其中的重要组成部分。

sudo-rs 的核心价值在于使用内存安全语言重写关键工具。C 语言虽然高效，但在处理字符串、内存分配等方面容易出现错误，而 Rust 的所有权模型和借用检查器能从编译期就杜绝大多数内存腐败问题。这些问题正是本地提权攻击的主要利用点。

作为近乎 drop-in 的替代品，sudo-rs 力求保持与传统 sudo 的兼容性，同时大幅提升安全性。用户可以逐步迁移现有脚本和配置，而无需大规模重构系统。

目前 sudo-rs 仍在积极开发中，但已经在 Ubuntu 的实验性仓库中可用。对于追求最新安全实践的团队来说，这是一个值得跟进的方向。它的出现也反映了 Linux 生态中 Rust 逐渐成为系统级关键组件的趋势——不仅仅是性能考虑，更是安全优先的必然选择。

opendoas

第三个方案是 opendoas，它是 OpenBSD doas 的一个 fork，核心理念是“越小越安全”。

opendoas 的代码量只有约 3000 行，与 sudo 的十万行形成鲜明对比。极小的代码库意味着审计难度大幅降低，开发者或安全研究人员可以相对轻松地通读全部代码，发现潜在问题。OpenBSD 项目以代码审计严格著称，doas 继承了这一传统。

配置 opendoas 也非常简洁，通常只需编辑 /etc/doas.conf 文件，语法清晰易懂：

permit keepenv user as root

相比 sudo 的复杂配置文件，opendoas 的简约设计减少了配置错误导致的安全风险。不过，需要注意的是 opendoas 的维护节奏相对较慢，上游 doas 仍有 2024 年的更新记录，但 fork 版本需要用户自行关注最新动态。

opendoas 特别适合追求轻量级、极致安全的服务器环境或嵌入式系统。在资源受限场景下，它的低开销也是显著优势。

Qubes OS

最后一个方案不是单个工具，而是整个操作系统——Qubes OS。它以一种更激进的方式解决了权限问题：让 sudo 几乎完全失去存在的必要。

Qubes OS 的核心设计是基于 Xen 虚拟化的强隔离。它将系统划分为多个安全域（Security Domains），例如工作域、个人域、银行域等。每个域运行在独立的虚拟机中，域之间通过严格的策略进行通信。

在 Qubes 中，即使攻击者攻破某个域的普通用户权限，也很难对其他域造成持久影响。系统模板（TemplateVM）负责提供基础环境，重启后会重置为干净状态。关键用户数据保存在独立的持久域中，而 root 权限操作主要影响的是可重置的系统部分。

正因为这种设计，传统的“获取 root 权限”在 Qubes 的威胁模型中意义不大。攻击者即便拿到 root，也难以跨越域边界窃取核心数据或实现持久化控制。因此，Qubes 团队选择禁用或极度限制 sudo 的使用，转而依赖域隔离来保障安全。

Qubes OS 适合对安全有极高要求的用户，比如记者、安全研究者或处理敏感数据的专业人士。当然，它的学习曲线较陡，对硬件资源也有一定要求，但提供的安全性是传统单机系统难以比拟的。

总结来看，run0 侧重机制创新和集成便利性，sudo-rs 强调代码层面的内存安全，opendoas 追求极致简约，而 Qubes OS 则从系统架构层面重新定义了权限安全边界。

对于普通桌面用户，run0 是最容易上手的起点；服务器管理员可以根据场景选择 opendoas 或逐步引入 sudo-rs；追求最高安全等级的用户，不妨尝试 Qubes OS。

未来，理想的权限提升工具可能是这些方案的融合：采用 Rust 编写、保持极小代码量、基于 polkit 等现代机制、并辅以容器/虚拟化隔离。sudo 凭借先发优势仍会长期存在，但越来越多的发行版和项目正在探索更安全的替代路径。

在实际部署时，建议结合最小权限原则（Principle of Least Privilege）、定期审计配置，并搭配 AppArmor、SELinux 等 MAC 机制使用。多层防御永远优于单一工具的完美。

技术在不断演进，sudo 的故事也提醒我们：安全从来不是一劳永逸，而是持续迭代的过程。希望本文能帮助你在日常运维中做出更明智的选择，提升系统的整体安全性。