AI 环境下服务器授权解决方案：限时账号与一次性容器的隔离设计

把一台服务器交给 AI 之前，真正决定安全边界的不是防火墙，而是授权粒度。

近一年，AI 编程助手、自动化 Agent、CI 机器人开始直接登服务器干活：跑构建、改配置、拉数据、部署服务。省事是真省事，但一个绕不开的问题摆在运维面前——你打算给它多大的权限？

给一个 root 账号，等于把整台机器交出去：它能读 /etc/shadow，能改 systemd 单元，能 rm -rf，能顺手装个后门。事后想收权，还得记得它当初开了几个会话、动了哪些文件、连过哪台机器。

所以「AI 环境下服务器授权」这件事，落到工程上其实是四个问题：

1. 能用多久——到期自动失效，不依赖人记得回收
2. 能动什么——权限白名单，而不是「反正它不会乱来」
3. 能碰哪里——目录与命名空间边界
4. 怎么收回——一键吊销，且不留残留

下面这套方案把这四件事收敛成一条命令，并用两套互不依赖的机制兜底。

一、两条技术路线

路线一：宿主机临时账号

在宿主机上开一个限时、限权、限目录的普通账号。核心是六个动作：

• useradd 建号，家目录权限收到 0700
• chage -E 设到期日，到点系统层面拒绝登录
• setfacl 给指定目录递归授权，并加默认 ACL 让新文件自动继承
• sudoers.d 写一份命令白名单，附带高危命令黑名单
• sshd_config 加一段 Match User，关掉转发、隧道、空密码
• 一个定时回收器每分钟扫一遍，到期就锁号、摘密钥、回收 ACL

路线二：一次性容器

不在宿主机上开账号，而是起一个用完即焚的容器：容器内是 root，随便折腾，但它能看到的只有你挂进去的那一个目录。

隔离靠的是内核命名空间和 cgroup，不是策略：

• 端口只绑 127.0.0.1，默认外网连不进来
• 削减 SYS_ADMIN、SYS_MODULE、SYS_PTRACE 等 capability
• --pids-limit 防 fork bomb，内存与 CPU 硬限制
• no-new-privileges，不挂 docker.sock，不用 --privileged / host 网络
• 到期直接停容器，事后删掉，宿主机零残留

两条路线的取舍

维度	宿主机账号	一次性容器
越界访问	ACL 只能授权，挡不住读系统目录	命名空间隔离，宿主路径根本不存在
进程可见性	能看到全部进程	只看到容器内自己的
提权	sudo 白名单可被解释器绕过	容器内本来就是 root，无需绕过
删错东西	靠删除护栏兜底	容器内随便删，炸的是容器
资源耗尽	ulimit 有限	cgroup 硬限制
操作宿主机	可以，授权目录即可	做不到（挂了 /etc 等于交出去）
多目录	可重复授权读写/只读	只挂一个目录
无 docker 的机器	可用	不可用

一句话：宿主机方案是「限制 AI 能做什么」，容器方案是「AI 做什么都碰不到外面」。后者是结构性的，不依赖策略是否正确。

二、工程落地：一条命令背后的六件事

理想状态下，运维不该记这么多步骤。把上面的动作封装成一个单文件脚本（下称 ailease），对外只暴露一条命令：

sudo ailease new ai /clicd 2h          # 容器：挂 /clicd，2 小时后自动停
sudo ailease new ai /clicd 2h --host   # 账号：ACL 限目录 + sudo 白名单

位置参数顺序随意，自动识别名字、目录、时长；时长支持 30m 2h 7d 2w 1h30m。密码自动生成并只打印一次。

安装分两个版本，参数完全一致，运行时自动判断：

sudo ailease install          # 主程序 + 账号版：护栏、回收器、SSH 收敛
sudo ailease install docker   # 再加 docker 引擎与基础镜像，启用容器版

new 时若 docker 可用就走容器，否则回退账号版并告警；也可以用 --host / --container 强制指定。

到期回收：两套机制叠加

精确控制在分钟级：创建时把到期 Unix 时间戳写进元数据，回收器每分钟扫一次，到点执行「踢会话 → 锁号 → 清空 authorized_keys → 移除 sudo/sshd/limits 配置 → 回收 ACL」。

粗粒度兜底在天级：chage -E 设为到期日的次日。之所以不设当天，是因为 chage 只有日期粒度——对 12 小时的账号，设成当天会提前最多 23 小时把人踢掉。这样即使回收器停摆，账号也会在一天内失效。

删除护栏：白名单模型

宿主机方案里最危险的是「删除」。与其给 rm 加一堆参数校验，不如换个模型——裸 rm 一律不给 sudo 权限，删除统一走一个独立的护栏程序，判定顺序是：

1. 目标路径规范化，解析 .. 与符号链接
2. 落在允许根内（自家 home、工作目录、授权目录、/tmp、/var/tmp）→ 放行
3. 命中系统保护根（/etc、/usr、/var 等）→ 拒绝
4. 其余一律拒绝

再加一条：护栏以 root 运行，内核的 sticky bit 不生效，所以对 /tmp 下的目标额外做属主校验，非调用者且非 root 的文件拒绝删除。每次调用都记日志，拒绝原因一并落盘。

三、安全模型的诚实边界

任何方案都有边界，写清楚比藏起来重要。

POSIX ACL 只有授予语义，没有拒绝语义。 /etc、/var/log 这类天生 world-readable 的目录，ACL 挡不住读取，只能挡住写入。要真正的读隔离，必须上命名空间。

sudo 白名单只约束命令名，约束不了命令内部的行为。 一旦放行 python3、node、bash 中的任何一个，AI 就等价于拿到 root shell。所以最保守的那一档刻意不给任何解释器。

但即使最保守的一档也不是只读沙箱。 它放行的 chmod、chown、cp、tee、find、tar 都以 root 运行且能触达任意路径——sudo chmod 777 /etc/shadow、sudo tee /etc/...、sudo find / -exec ... 都是不需要任何解释器的提权路径。所以这一档的实际语义是「root 级文件访问」，只有完全不给 sudo 才是真的只碰授权目录。

结论：要目录级隔离用容器，要对抗性沙箱请上独立 VM。 这套工具解决的是「省事 + 防手滑 + 到期回收」，不是对抗性隔离。

四、项目与一键使用

项目开源在 GitHub，单文件 bash，root 运行，除 acl 包外零外部依赖：

github.com/4kercc/ai-lease

一键安装（脚本会尝试自动装 docker，并拉取或本地构建基础镜像）：

wget -qO- https://raw.githubusercontent.com/4kercc/ai-lease/main/ailease | sudo bash -s install docker

装完直接起一个容器：挂载指定目录，2 小时后自动停，密码自动生成并打印一次：

sudo ailease new ai /clicd 2h

日常操作：

sudo ailease list             # 谁还在、还剩多久
sudo ailease exec ai          # 进容器
sudo ailease extend ai 1h     # 续期
sudo ailease del ai           # 手动删掉

要的是宿主机账号而不是容器，加 --host 即可，第 4 个位置参数是 sudo 档位：

sudo ailease new ai /clicd 2h --host dev

只想装账号版、不碰 docker，把安装命令末尾的 install docker 换成 install 即可。