8款“龍蝦”本地大模型安全實測：剪貼板泄露、沙箱失效，2款真安全

你剛在本地跑起一個“龍蝦”（LLaMA系開源模型），界面流暢、響應飛快，還順手把公司合同粘貼進去問了句“怎么改條款”。
——但那行文字可能正通過剪貼板悄悄上傳到某個未聲明的遠程服務端。

這不是猜測。我們用 AI Agent平臺 開源安全框架（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/ai-agent/ai-agent/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 協議切斷所有外鏈請求》，讓模型徹底“斷網思考”。

本地大模型的價值，不在跑得快，而在信得過。
別讓“零門檻”變成“零防線”。