Mole 安全策略全解：漏洞报告通道、修复承诺与安全敏感边界解析

Mole 是一个执行清理、卸载、优化、产物移除等高危本地操作的 macOS 维护工具，因此它的 安全策略 把「安全边界、删除逻辑与发布完整性」明确列为安全敏感区域。本文以该安全策略文档为核心，逐条拆解其漏洞报告流程、响应 SLA、安全问题的判定边界，并结合仓库中的路径校验实现与模糊测试语料，说明这些承诺背后实际落地的防护机制。

一、漏洞报告通道：私有渠道优先，禁止公开 Issue

Mole 要求疑似安全问题必须通过私有渠道报告，而不是直接开公开的 GitHub Issue。官方给出的报告路径是：

• 邮箱：[e-mail]
• 邮件主题：Mole security report

文档同时说明：如果该仓库启用了 GitHub Security Advisories 的私有报告功能，也可以使用该渠道代替邮件。核心原则是：未修复的漏洞（unpatched vulnerability）不应出现在公开 Issue 区。

对于维护者而言，这条规则的意义在于：Mole 的很多安全问题直接关联「会删错文件」的删除边界，公开披露会在补丁合入前暴露可复现的利用路径，私有渠道能压缩这段窗口期。

报告应包含的信息清单

安全策略 给出了报告时的信息模板，建议尽可能提供以下五项：

1. Mole 版本与安装方式——区分 brew、install.sh、源码等安装路径，直接影响复现环境；
2. macOS 版本——SIP 状态、系统路径布局随版本变化，是判断删除边界问题的前提；
3. 涉及的准确命令或工作流——例如 mo clean、mo uninstall、mo analyze 等具体子命令；
4. 复现步骤或概念验证（PoC）；
5. 问题是否涉及以下五类高危域：删除边界（deletion boundaries）、符号链接（symlinks）、sudo、路径校验（path validation）、发布/安装完整性（release/install integrity）。

第 5 条值得注意：它实际上把维护者眼中的高危面浓缩成了关键词清单，报告者对号入座即可快速界定问题等级。

二、响应承诺：7 天确认，30 天进展，协调披露

安全策略 对响应时间做了量化承诺，但明确标注为开源个人维护项目的「尽力而为」（best-effort）：

承诺项	时限
确认收到新报告（acknowledge）	7 个日历天内
若尚无修复或缓解方案，提供状态更新	30 天内
对外披露	在修复、缓解措施或明确的用户指引就绪后协调进行

同时文档明确了优先级：安全报告优先于普通 bug 报告。披露策略采用标准的协调披露（coordinated disclosure）——不会在修复或缓解可用之前就公开问题细节，这避免了「漏洞曝光但补丁未发」的裸奔窗口。

支持的版本范围

安全修复只保证覆盖两个目标：

• 最新发布版（latest published release）
• 当前 main 分支

旧版本发布不保证获得安全修复，文档对运行高危命令的用户给出了直接建议：保持版本最新。对使用者而言，这意味着把「升级 Mole」纳入常规维护习惯，而不是等出安全公告再行动。

三、什么算安全问题：判定边界与反例清单

安全策略中最实用的一节是「什么算安全问题」。它把判定标准分成了正面清单和负面清单。

属于安全问题的示例

安全策略 列举了七类典型的安全相关问题：

• 路径校验绕过（path validation bypasses）——本应被拒绝的删除路径通过了校验器；
• 越界删除（deletion outside intended cleanup boundaries）——删除发生在预期清理范围之外；
• 符号链接或路径穿越的不安全处理（unsafe handling of symlinks or path traversal）；
• 意外的权限提升或不安全的 sudo 行为（unexpected privilege escalation or unsafe sudo behavior）；
• 绕过文档化保护机制的敏感数据删除（sensitive data removal that bypasses documented protections）；
• 发布、安装、更新或校验和完整性问题（release, installation, update, or checksum integrity issues）；
• 任何可能导致非预期破坏性行为（unintended destructive behavior）的逻辑漏洞。

这条清单的底层逻辑很清晰：Mole 没有远程攻击面，它的风险集中在「本地破坏性操作失控」上，所以七类问题全部指向删除路径、权限与供应链三条主线。

通常不算安全问题的情况

以下情况通常归为普通 bug、功能请求或文档问题，不属于安全问题：

• 清理不彻底、留下可恢复的垃圾文件（cleanup misses）；
• Mole 拒绝清理某物的误报（false negatives）——注意方向性：「少删」是普通 bug，「多删」才是安全问题；
• 纯外观的 UI 问题；
• 要求更激进、范围更大的清理行为的功能请求;
• 没有合理安全影响的兼容性问题。

文档给出的兜底建议是：拿不准时，先通过私有渠道报告。这个「宁严勿宽」的默认姿态与工具本身「不确定时就拒绝」的删除哲学一致。

四、安全重点关注域与仓库中的实现证据

安全策略 最后指出项目重点关注六个安全域，并在文末引用了 SECURITY_AUDIT.md 作为当前技术设计与已知限制的技术文档。对照仓库源码，这些承诺都能在代码中找到对应实现。

4.1 破坏性命令边界与路径校验

策略中「破坏性命令边界（destructive command boundaries）」对应仓库中所有删除操作的统一收口：所有删除都经由 lib/core/file_ops.sh 中的守护函数路由。该文件内的 validate_path_for_deletion（定义于 file_ops.sh）实现了一系列硬性检查，任何一条拒绝即终止操作：

• 非空且绝对路径：空路径与不以 / 开头的路径直接拒绝，排除相对路径与调用方 $PWD 交互产生的歧义；
• 路径穿越：只有当 .. 作为完整路径分量出现时（如 /foo/../bar、../bar）才拒绝——这比朴素的子串匹配更精确，能放行 Firefox 的 name..files 这类合法目录名，同时拦截 /Users/me/Library/../../etc；
• 控制字符：包含 \n、\t 等 [[:cntrl:]] 字节的路径被拒绝，防御日志注入与 shell 意外解释；
• 符号链接检查：若路径本身是符号链接，校验器会 readlink 读取目标、解析为绝对路径后重新对照受保护路径清单，防止「/tmp/foo 指向 /System 却蒙混过关」；
• 祖先符号链接检查：即使叶子节点无害，若父目录链中有符号链接（例如被重定向的 ~/Library/Caches），校验器也会规范化父目录并对解析后的路径重跑拒绝规则——这一检查是「仅拒绝（deny-only）」的，解析后的路径永远不会授予字面路径所没有的权限；
• 先允许后拒绝（allow-then-deny）：先对 /private 下已知安全的子树（/private/tmp、/private/var/log、/private/var/folders、/private/var/db/diagnostics 等可重建缓存）放行，再应用 /、/bin*、/usr*、/System*、/etc*、/var/db*、/private 等的拒绝清单，最后调用 should_protect_path 做细粒度的应用/数据保护判断。

这一允许/拒绝顺序的设计意图在源码注释中也有体现：可重建的系统缓存恰位于「否则会被拦截」的路径下，先列白名单意味着维护者新增安全路径时无需外科手术式地削弱 deny 规则（参见 file_ops.sh 中的允许清单与拒绝顺序）。

4.2 符号链接与路径穿越：从策略条款到机器可验证的不变量

策略中的「symlink and path traversal handling」在测试层有机器级保障，这正是「发布完整性之外，逻辑完整性也可被持续验证」的关键：

• tests/fuzz_corpus/dangerous_paths.txt 维护了一组对抗性路径语料（/、/etc/passwd、/var/db/SystemPolicy、各类 .. 穿越变体、含控制字符的路径、受保护的系统缓存与应用容器等），文件头明确要求「每一行路径都必须被拒绝」；
• tests/path_validation_fuzz.bats 对上述语料逐行断言校验器返回非零；
• Go 侧的 cmd/analyze/delete_fuzz_test.go 提供 FuzzValidatePath 模糊测试目标，其断言的不变量与策略条款逐字对应：任何被接受的路径必须是绝对路径、不含 null 字节、不含 .. 分量，并顺带捕获对抗性输入导致的 panic。

4.3 删除操作的审计留痕

与「协调披露、可审计」的披露文化相配套，Mole 的删除路径本身带审计语义：mole_delete（file_ops.sh）在执行前再次调用 validate_path_for_deletion，且校验被拒绝的操作也会被记入删除日志（状态标记为 rejected），使审计轨迹能区分「被策略拒绝」与「从未尝试」两类事件。策略文档中「sensitive data exclusions」所承诺的「保护绕过可见、可查」，在实现上就体现为这类留痕。

4.4 其余关注域的定位

策略列出的其余关注域，其详细技术描述与已知限制均在 SECURITY_AUDIT.md 中展开，可按需深入：

• Sudo 与权限边界：SECURITY_AUDIT.md 的 "Privilege Escalation and Sudo Boundaries" 一节说明 sudo 需显式申请、受保护根在提权后依然拦截、sudo 删除走与非 sudo 相同的校验门禁、认证失败时宁可跳过也不放宽范围；
• 敏感数据排除：同文档 "Sensitive Data Exclusions" 一节列出了钥匙串、密码管理器、VPN 代理工具、浏览器历史与 Cookie、iCloud Mobile Documents 等受保护类别；
• 打包、发布产物、校验和与更新/安装流程：同文档 "Release Integrity" 部分描述了发布资产附带的 SHA-256 校验和、GitHub artifact 证明，以及 install.sh 在安装侧验证构建溯源证明的机制——这正是策略「What We Consider a Security Issue」中 "Release, installation, update, or checksum integrity issues" 一类的落地防线。

五、把安全策略用起来：读者行动清单

结合策略文档与仓库证据，普通用户与贡献者可以据此形成一套可操作的判断框架：

1. 报告前：对照第三节的正反清单判断问题性质；涉及删除越界、符号链接、sudo、路径校验、发布完整性的，走 Mole security report 邮件主题私有报告，附上版本、macOS 版本、命令、PoC 与高危域归类；
2. 使用中：只运行最新 release 或 main 分支（安全修复承诺范围）；遇到「Mole 拒绝清理某物」先视为正常保护行为而非 bug；
3. 评估/审计时：以 SECURITY_AUDIT.md 为技术事实基线，用 tests/path_validation_fuzz.bats 与 tests/fuzz_corpus/dangerous_paths.txt 作为可执行的验证手段，用 cmd/analyze/delete_fuzz_test.go 作为 Go 侧校验器的不变量定义。

这套策略文档与源码、测试之间的对应关系，展示了本地高危工具「以边界换自由」的典型设计：不为激进清理放宽任何一条删除校验，把「拒绝」作为默认答案，再用持续运行的语料与模糊测试把每条拒绝承诺变成可回归验证的事实。