Files
dsh_shenxian/dsh-server-docs/04-调整方案/02-安全加固-权限边界与DB.md
T
admin 5ad755116e chore(docs): 文档库并入代码仓(R4 选 a)+ 索引/台账跟进
1) dsh-server-docs/ 从工作区(原 E:\...\aliyun-dsh-server\dsh-server-docs)**整体并入本仓**,
   保留目录名 ⇒ 仓库内 dsh-server-docs/... 的相对引用天然继续有效;旧目录(含其 .git)已归档到
   工作区 _中间产物_待清理/,未随本提交带入。
2) .gitattributes:新增 `dsh-server-docs/** -text` —— 原文档库是 `* -text` + autocrlf=false,
   必须保持纯 LF,否则会被本仓的 CRLF 规则翻掉。
3) 活引用里的绝对路径已全部改到新位置(docs 的 INDEX / README / scripts / skills + 用户级 skills
   + ~/.workbuddy/settings.json 的 hooks);历史档案(04-调整方案/、archive/)按「只增不改」未动。
   ⚠️ hooks 路径改动需「完全重启会话」才生效(配置是会话启动快照)。
4) 交接单/T08:新增 §16「生产整体切换执行记录」(形态 / 落地动作 / **4 个只有真上线才暴露的真 bug** /
   验收证据 / 回滚命令 / 残留项);台账 T08 行 → 已完成并归档;03-路线图 §二 登记 T08 收尾项。
5) 统一称谓:**「本机」只指跑 WorkBuddy 的开发机**,47 / 106 一律写「远程服务器」。
2026-09-15 18:47:13 +08:00

38 lines
3.1 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
## 十七、权限边界实测 + DB 权限安全加固(2026-09-08)
**问题**:admin 登录后能否访问服务器所有目录?AI 对话窗口新建工作空间时能否输入系统根目录?
**两层防护模型(答案分两层)**:
| 层 | 机制 | 结论 |
|----|------|------|
| Web 桌面层 | fs-guard `resolveWithinRoot()`:所有文件浏览/上传/新建工作空间的路径解析被锁在用户自身 home/ws 内,拒绝 `../`、绝对路径、符号链接逃逸 | 输入 `/`、`/root` 等系统路径会被拉回/拒绝;admin 与普通用户同样受限,**不存在"admin 浏览全服务器"入口** |
| AI 进程层 | 每用户 DSH 实例以**降权 uid**(setpriv)运行,该进程可执行 shell/agent 工具,**不受 fs-guard 约束**,能读该 uid 有权限的一切文件 | admin 的实例同样是降权 uid,非 root。实测 uid 114801 边界:`/root`、`/etc/shadow`、`/opt/dsh/.env`、secret.key、dsh db 全部 Permission denied ✅;`/etc/passwd`、`/tmp` 世界可读可写 ✅ |
**结论**:即便 admin 也无法从 AI 对话触达 root-only 敏感文件;真正的服务器管理走 SSH/宝塔 root 通道,与 AI 会话隔离。这是 account 隔离模式的核心价值,无需额外改造。
**⚠️ 实测发现并修复的漏洞:DB 权限 644 → 600**
| 项 | 详情 |
|----|------|
| 漏洞 | `/var/lib/dshs/dshs.db` 权限 644 root——任意降权账号可 `cat` 拖库 |
| 风险 | 库内含全部用户 `pass_hash`(scrypt)+ `api_key_ref`(AES-GCM 密文)+ uid/sid → 离线爆破口令 + 窃取 key 密文 |
| 修复 | `chmod 600 /var/lib/dshs/dshs.db* /var/lib/dshs/dshs.db*` |
| 验证 | 降权账号读 db → Permission denied ✅;服务 600 下正常(portal 401 为未认证正常响应)✅ |
**目录级权限收紧(用户反馈"其他用户也能看就不行",2026-09-08 20:30)**:
普通用户实例同样是降权 uid,盘点发现除主 db 外还有更大泄露面:`/opt/dshs` 整棵树 755、`/opt/dsh/docs/` 内**主库备份**(含全部 pass_hash+key 密文)、`/opt/dsh/backups/` 备份包、`/opt/dsh/users/main` 旧数据残留均 644/755 可读 → AI 会话可拖取。收紧如下:
| 路径 | 改前 | 改后 | 说明 |
|------|------|------|------|
| `/opt/dsh` | 755 | **700** | 覆盖 docs(含 db 备份)、backups、users/main 残留 |
| `/opt/dshs` | 755 | **700** | root 服务运行不受影响(systemd 无 User= 默认 root) |
| `/var/lib/dshs` | 755 | **711** | 保留 o+x:降权进程需穿过根路径进入自己 home,去读防列表泄露 |
| `.../users` | 755 | **711** | 同上;用户目录本身 700 保持隔离 |
**验证(uid 114801 实测)**:读 `/opt/dsh/docs/*.md` → denied ✅;列 `/opt/dshs`、数据根 → denied ✅;**仍可进入自己 `ws/mcnworkspace` ✅**;systemd active、portal 200、admin 实例 `/plugins/events` 正常 ✅。
**⚠️ 经验固化(Linux 目录权限设计)**:数据根这类"root 服务 + 降权子进程都要访问"的目录,权限用 **711/700**(去 r 留 x),不能收 700——降权进程会因无法穿过根路径而崩溃(EACCES)。子目录各自 700 才是真正的隔离边界。