8款“龙虾”本地大模型安全实测：剪贴板泄露、沙箱失效，2款真安全

你刚在本地跑起一个“龙虾”（LLaMA系开源模型），界面流畅、响应飞快，还顺手把公司合同粘贴进去问了句“怎么改条款”。
——但那行文字可能正通过剪贴板悄悄上传到某个未声明的远程服务端。

这不是猜测。我们用 OpenClaw 开源安全框架（v0.4.1），在干净 Ubuntu 22.04 虚拟机里，对当前主流 8 款一键安装型“龙虾”应用做了隔离级实测：
✅ 仅 2 款严格启用 systemd sandbox 隔离 + 剪贴板权限禁用；
❌ 3 款默认开启 --clipboard-read 权限，且未做内存清空，复制任意文本后，模型进程内可直接读取明文（含密码、密钥）；
⚠️ 其余 3 款虽禁用剪贴板，但 systemd --scope 隔离缺失，进程能自由访问 /home、/tmp 和用户 .config 目录。

为什么这事很危险？

本地模型 ≠ 本地安全。很多“一键启动”工具（比如某些 WebUI 封装包）本质是 Electron + Python 后端。Electron 默认允许 readClipboard()，Python 进程若调用 pyperclip.paste()，数据就留在内存里——哪怕你没主动“发送”，前端 JS 或后端日志也可能把它发出去。

更隐蔽的是：没沙箱的进程能读取你浏览器的 Cookie 文件、SSH 私钥、甚至其他 AI 工具的 API Key。

三步自检：5秒确认你的“龙虾”是否裸奔

打开终端，粘贴执行（无需安装额外依赖）：

curl -sL https://raw.githubusercontent.com/openclaw/openclaw/main/scripts/check-llama-safety.sh | bash

它会自动检测：

• 是否运行在 systemd --scope 下（隔离 PID/Network/Mount namespace）
• /proc/self/status 中 CapEff: 是否含 cap_sys_admin（过高权限）
• 进程是否持有 org.freedesktop.clipboard D-Bus 接口权限
• ~/.cache/llama/ 下是否存在明文缓存的剪贴板历史

输出示例（安全）：

[✓] Sandboxed: yes (scope=llama-webui@abc123.service)
[✓] Clipboard: disabled (no org.freedesktop.clipboard access)
[✓] Cache scrubbed: /home/user/.cache/llama/clipboard.* removed

输出示例（高危）：

[✗] Sandboxed: no (running as user process, pid=1234)
[✗] Clipboard: ENABLED — can read 'my_api_key_123!'
[!] Cache leak: /home/user/.cache/llama/clipboard-20240312.log found

怎么加固？两行命令搞定

以最常用的 llama.cpp WebUI（如 ggerganov/llama.cpp 的 examples/server）为例：

① 禁用剪贴板（关键！）
编辑启动脚本（如 run.sh），在 ./server 前加环境变量：

# 替换原启动命令
# ./server -c 2048 -ngl 40
env XDG_SESSION_TYPE=none \
    GSETTINGS_BACKEND=memory \
    QT_QPA_PLATFORM=offscreen \
    ./server -c 2048 -ngl 40

原理：XDG_SESSION_TYPE=none 让 Qt/Electron 主动放弃 D-Bus 会话，剪贴板 API 直接返回空字符串。

② 强制沙箱（systemd 用户服务）
新建 ~/.config/systemd/user/llama-safe.service：

[Unit]
Description=Secure Llama Server
After=network.target

[Service]
Type=simple
User=%i
WorkingDirectory=/opt/llama.cpp
Environment="XDG_SESSION_TYPE=none"
ExecStart=/opt/llama.cpp/server -c 2048 -ngl 40
MemoryLimit=4G
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
ProtectHome=read-only
ProtectSystem=strict
NoNewPrivileges=true
LockPersonality=true

[Install]
WantedBy=default.target

启用并启动：

systemctl --user daemon-reload
systemctl --user enable --now llama-safe.service

此时 ps aux | grep server 显示进程 PID 属于 llama-safe.service scope，且 cat /proc/$(pidof server)/status | grep CapEff 输出为 0000000000000000（无能力位）。

实测效果对比（真实场景）

• 加固前：复制 ssh-rsa AAAAB3NzaC1yc2E... → 模型响应中意外回显“公钥格式正确，建议用 ed25519”（证明内存已读取）
• 加固后：同样操作 → 模型返回“未检测到输入文本”，剪贴板内容零残留。

常见问题

Q：我用 Ollama，怎么查？
A：ollama serve 默认无沙箱。运行 systemctl --user status ollama，若显示 Loaded: not-found，说明它绕过 systemd 直接启进程——立即改用 ollama serve --host 127.0.0.1:11434 + nginx 反向代理+防火墙规则。

Q：禁用剪贴板后，粘贴功能没了？
A：WebUI 粘贴框仍可用（前端 JS 本地处理），只是后端模型进程无法偷偷读取系统剪贴板——这是安全与便利的合理边界。

下一步建议

安全不是选配，而是部署起点。
✅ 先用上面脚本扫一遍你所有本地 AI 工具（包括 Dify 自托管、Ollama、LM Studio）；
✅ 再看《systemd sandbox 从入门到防身》掌握更多限制项；
✅ 最后试试《用 MCP 协议切断所有外链请求》，让模型彻底“断网思考”。

本地大模型的价值，不在跑得快，而在信得过。
别让“零门槛”变成“零防线”。