系统工具的权限模型：capabilities-based security 的 Rust 实现与设计

系统工具的权限模型：capabilities-based security 的 Rust 实现与设计

一、传统 ACL 和 RBAC 为什么不适用于系统工具？

传统权限模型主要有两种：

• ACL（访问控制列表）：为每个资源维护"谁能访问"的列表
• RBAC（基于角色的访问控制）：用户→角色→权限

这两种模型在 Web 应用里很好用，但在系统工具场景下有严重问题：

举个例子：你的系统监控工具需要读取/proc/stat来获取 CPU 信息，但你只给了它"读取文件"权限。结果它不小心（或被攻击者利用）也能读取/etc/shadow。这就是最小权限原则没有落地的典型后果。

二、什么是 Capabilities-based Security？

Capabilities 的核心思想很简单：不给模块"你是谁"的身份，只给"你能做什么"的令牌。

在 Capability 模型里：

• 没有全局的"我是 admin"状态
• 每个操作都要出示对应的令牌
• 令牌可以传递、可以撤销、可以设置过期时间
• 一个模块不能做它没拿到令牌的事，即使它想也不行

这天然实现了最小权限原则。

三、Rust 实现 Capability 模型

Rust 的类型系统和所有权模型非常适合实现 capability 模式。我们利用 Rust 的类型系统来做到编译期权限检查。

3.1 定义 Capability 类型

use std::marker::PhantomData; /// Capability 令牌是零大小的类型标记 /// 在编译后完全不存在，零运行时开销 pub struct Cap<T> { // 零大小类型作为"能力证明" token: std::marker::PhantomData<T>, } impl<T> Cap<T> { /// 创建新的 capability 令牌 /// 这个函数只能在信任边界内调用（模块内部） fn new() -> Self { Cap { token: PhantomData } } } /// 标记 trait：实现了这个 trait 的类型代表一种权限 pub trait Permission: sealed::Sealed {} mod sealed { pub trait Sealed {} impl Sealed for super::ReadProc {} impl Sealed for super::ReadShadow {} impl Sealed for super::WriteConfig {} } // 具体的权限类型 pub struct ReadProc; impl Permission for ReadProc {} pub struct ReadShadow; impl Permission for ReadShadow {} pub struct WriteConfig; impl Permission for WriteConfig {}

这是 Capability 模式的精髓：你没法凭空创建一个Cap<ReadShadow>——只有被授予了这个令牌的模块才能调用需要它的操作。

3.2 受保护的资源访问

/// 系统文件读取器：只有持有对应令牌的调用者才能读取 pub struct FileReader { _private: (), // 禁止外部直接构造 } impl FileReader { pub fn new() -> Self { FileReader { _private: () } } /// 读取 /proc/stat（CPU 信息） /// 需要 ReadProc 令牌 pub fn read_proc_stat(&self, _token: &Cap<ReadProc>) -> String { // 实际读取文件... // 编译器保证：调用者一定持有 ReadProc 令牌 std::fs::read_to_string("/proc/stat").unwrap_or_default() } /// 读取 /etc/shadow（密码哈希） /// 需要 ReadShadow 令牌 pub fn read_shadow(&self, _token: &Cap<ReadShadow>) -> String { // 只有系统管理模块才能调用这里 std::fs::read_to_string("/etc/shadow").unwrap_or_default() } /// 写入配置文件 /// 需要 WriteConfig 令牌 pub fn write_config(&self, _token: &Cap<WriteConfig>, content: &str) { std::fs::write("/etc/myapp/config.toml", content).expect("写入配置失败"); } }

关键：read_shadow要求传入&Cap<ReadShadow>引用。如果某个模块的代码里没有这个令牌，编译器直接报错——根本没有绕过权限检查的可能。

3.3 权限传递与委托

/// 运行时 Capability 管理器 /// 支持动态授予和撤销权限 pub struct CapManager { read_proc: Vec<Cap<ReadProc>>, write_config: Vec<Cap<WriteConfig>>, } impl CapManager { pub fn new() -> Self { CapManager { read_proc: Vec::new(), write_config: Vec::new(), } } /// 授予 ReadProc 权限并锁入凭据管理器 pub fn grant_read_proc(&mut self) -> Cap<ReadProc> { let cap = Cap::new(); self.read_proc.push(cap); Cap::new() // 实际项目应返回引用，这里简化 } /// 授予 WriteConfig 权限，返回可传递的令牌 pub fn grant_write_config(&mut self) -> Cap<WriteConfig> { // 日志记录：谁在什么时间获取了权限 println!("[AUDIT] WriteConfig 权限被授予"); Cap::new() } /// 撤销所有 WriteConfig 权限 pub fn revoke_write_config(&mut self) { self.write_config.clear(); println!("[AUDIT] WriteConfig 权限已全部撤销"); } }

四、真实场景：系统监控工具中的权限隔离

完整的系统组装代码：

fn main() { let mut cap_mgr = CapManager::new(); let file_reader = FileReader::new(); // === 初始化各模块，只授予最小权限 === // CPU 监控只需要读 CPU 信息 let cpu_token = cap_mgr.grant_read_proc(); let cpu_monitor = CpuMonitor::new(file_reader.clone(), cpu_token); // 配置管理器需要写权限 let config_token = cap_mgr.grant_write_config(); let config_mgr = ConfigManager::new(config_token); // 定期采集 loop { cpu_monitor.collect(); // ✓ 有 ReadProc 令牌 // cpu_monitor 无法调用 config_mgr 的方法，因为没有 WriteConfig 令牌 std::thread::sleep(std::time::Duration::from_secs(5)); } } /// CPU 监控模块：只能读取 CPU 相关数据 struct CpuMonitor { reader: FileReader, cap: Cap<ReadProc>, // 持有 ReadProc 权限 } impl CpuMonitor { fn collect(&self) { let stat = self.reader.read_proc_stat(&self.cap); println!("CPU 状态: {}", &stat[..100]); // 这里想调 self.reader.read_shadow() ？编译器直接报错！ } }

Rust 类型系统在编译期就完成了权限检查。如果一个模块没有Cap<ReadShadow>，它连调用read_shadow的代码都编译不过去。这是真正的"最小权限"，不是在运行时祈祷代码别出错。

我们线上出过一次事故：新同事写了一个fn debug_dump(cap: &Cap<ReadProc>)的函数，但在 unsafe 块里直接调了read_shadow。代码 review 时谁都没注意到——因为 unsafe 绕过了编译期检查。后来我们在 CI 里加了一条规则：每个 unsafe 块旁边必须有// SAFETY:注释说明不变量，否则 clippy 直接挂。Rust 的类型系统能挡 90% 的错，但 unsafe 这扇后门一打开，所有编译期保证都归零。

五、总结

Capabilities-based Security 在 Rust 中的实现有几个核心优势：

1. 编译期权限检查：Rust 的类型系统可以在编译时验证权限约束，不符合的代码根本编译不过
2. 零运行时开销：Cap<T>是零大小类型，编译后被完全优化掉
3. 显式传递，拒绝隐式继承：权限必须显式授予和传递，不会"不小心"拿到
4. 天然支持撤销：通过 Drop 或显式清理，随时可以收回令牌
5. 易于审计：每处权限授予都是一行代码，代码 review 时一眼就能看穿权限流向

这个模式不仅在系统工具有用，在微服务间调用、插件系统、沙箱隔离等场景都能用上。核心就一句话：别问"你是谁"，只看"你拿着什么令牌"。

保持学习，保持输出！今天的 Capability 权限模型就聊到这里。你在项目中用过类似的模式吗？评论区见！

参考资料

• Object-Capability Model (Wikipedia)
• Rust 类型状态模式 (Typestate Pattern)
• sealed trait pattern in Rust