FR-084 · 需求索引 · 本頁由 build 掃資料夾生成

FR-084 防竄改機制(jedi-integrity)資安檢查

一棒掃完並經首腦驗收(2026-09-10)。6 條發現(首腦改判 2 HIGH/2 MEDIUM/2 LOW),依決策者裁定不開修正卡,登記跨 arc 總表 §3.1 第 13~18 項

狀態:✅ 已完成 文件 2 份

🔴 一頁看完

掃完了,找到 6 個問題。結論是:這套防竄改機制擋得住「隨手改個檔案」,但擋不住「已經拿到主機管理權限、而且知道它怎麼運作」的人——其中兩條只要一個指令就能讓被鎖住的機器重新開起來。

三條最嚴重的(runner 判三條 HIGH,首腦驗收後第 3 條降 MEDIUM):

  1. 刪掉一個標記檔,被鎖的機器就能重開——文件宣稱「檔案與資料庫兩道鎖,任一存在即拒啟」,但查資料庫那半的程式寫好了卻零呼叫者,實際只有一道鎖,而那道鎖就是一個普通檔案。(首腦起點②猜中)
  2. 開機檢查不涵蓋驗章用的 cryptography 函式庫——它確實落在第三方層。換掉它讓「任何簽章都通過」,整套保護永久失效,連四小時一次的抽查也一起失效(抽查用的是同一個被掉包的工具)。(首腦起點④猜中)
  3. 一個環境變數 GUIDANT_RESOURCE_ROOT 就能把「要檢查哪個目錄」指到別處——這是起點①的另一種形狀:is_packaged() 本身關不掉(該主張成立),但執法對象可以被整個換走。首腦驗收改判 MEDIUM:單獨指到空目錄會因 manifest 缺失拒啟,要先過第 2 條才有用,是放大器不是獨立路徑。

其餘:解鎖檔防重放紀錄毀損時預設放行(MEDIUM)、鎖定畫面對外公開機器指紋(LOW)、竄改回報夾帶 log 尾段未過濾(LOW)。

⚠️ 全部未實測——依卡片紀律不動任何環境的 /opt/guidant/pki、不觸發真實鎖定,六條都是讀程式碼與 build 腳本推論的結果。

📄 完整報告:scan-T1-package-core.md

§1

這在做什麼(白話)

落地版產品是編譯成一支程式、裝在客戶自己的機器上,客戶機器上的任何人都可以直接改檔案。jedi-integrity 是防這件事的機制:

  • 開機時逐檔核對「原廠簽過名的檔案清單」,被改就拒絕啟動、留下紀錄、把畫面換成「系統已鎖定」。
  • 跑起來後每四小時左右隨機抽查一次。
  • 被鎖的機器只有原廠簽發的一次性解鎖檔能解。

這個 arc 要回答的是:這套保護能不能被繞過、被關掉、或被拿來搗亂(讓正常客戶的機器被鎖、或鎖了解不開)。

§2

為什麼掃它

  • 風險形狀與前七個 arc 不同。 前面掃的是「誰能看到不該看的資料」,這支被攻破的後果是「保護失效」:產品被改了但沒人知道,或客戶機器被鎖但解不開。
  • 從沒專門掃過。 FR-076 掃 License 鏈時越界順手撞到它一條 HIGH(CM-1572 無界解壓縮,已修),那是唯一一次。
  • 掃完永久有效。 它不在 FR-080 整併名單裡(design 標「不動」)。
§3

為什麼是一棒不是兩棒

依 FR-079 換來的判準,開卡前先查了「這支有沒有宿主那一半」。有,但太小:

套件本體    jedi_integrity/ + harness/     21 檔  約 3,250 行(20 py + 1 SQL)
BE 宿主接線  common/integrity/               2 檔    390 行 + 5 個呼叫點

宿主那 390 行首腦全文讀完,連同 5 個呼叫點的行號寫進卡片「已知背景」,runner 不必重讀。這與 FR-082 的做法相同。

§4

首腦讀碼後的四個起點(未經驗證,寫在卡片「重點看什麼」①~④)

這支套件的威脅模型是「攻擊者已經能改機器上的檔案」。所以要問的不是「需不需要主機權限」,而是**「有了主機權限之後,關掉這套保護還要不要額外成本」**。首腦看到四個可能是零成本的點:

# 看到什麼 為什麼可疑
整套保護只有一個開關:打包判定 is_packaged() 回 False 就跳過全部檔案核對
啟動時只看檔案系統的鎖定標記,從不查資料庫 README 說「雙落點任一存在即拒啟」,但 DB 那一半零呼叫者;刪一個檔就能重啟
鎖定標記、解鎖檔、已用 nonce 帳放同一個可寫目錄 nonce 帳毀損時刻意當作空的
驗簽章的 cryptography 函式庫可能落在啟動時不核對的第三方層 若成立,換掉它就能讓任何簽章都通過

另外六項(鎖定殼對外開放、事件回報帶 API token、終止流程對 PID 的信任、解鎖檔效期與時鐘、埋點退化為空、開發殼自帶第二套驗章)也在卡裡。

§5

進度

面板 發現 報告
T1 套件本體 CM-1645 21 ✅ 6 票全投出(三個檢查員 × 2 條候選),驗證章 verified 6 條:3 HIGH/1 MEDIUM/2 LOW
(工具正式發現 0 條,5 條為 runner 人工查證)
scan-T1-package-core.md

工具這輪幾乎零產出:兩個研究員只提 2 條候選,投票後兩條都沒過門檻(1:2、0:3),工具正式報告是零發現。6 條裡 5 條是人工開檔查出來的——連續第四個 arc 出現同樣情形,卡片預告的「工具不會照重點清單走」再次成立。

§6

修正卡

依決策者裁定不開。 六條登記進 跨 arc 總表 §3.1 第 13~18 項,之後從那裡挑。首腦驗收記錄在母卡 CM-1644。

待決策者裁兩件:① T1-1 修法方向(補開機期 DB 查詢/補同步反向補回標記/只改文件);② T1-2 開卡前要不要先在本機實測掉包 .so

T1b 實測結果(2026-09-10,CM-1650):T1-2 確認成立——實測證實掉包驗章工具後,開機檢查與四小時抽查同時失效、放行被竄改的檔案且無任何警示。嚴重度建議維持 HIGH,不降級。詳見 scan-T1b-verifier-swap-poc.md

§7

座標

§8

文件

以下全部由 build 掃資料夾產生,新增檔案重 build 即自動出現。標題連結指向渲染後的 HTML,md 連向源檔。

其他文件

文件 類型 標題 最後更新
scan-T1-package-coremd 文件 FR-084.T1 掃描報告:防竄改機制「套件本體」(jedi-integrity) 2026-09-10
scan-T1b-verifier-swap-pocmd 文件 FR-084 T1b 本機實測——換掉驗章函式庫是否真能繞過整套防竄改 2026-09-10
§9

Notion 卡

卡片內容(決策紀錄、驗收條件)以 Notion 為準,本頁只記座標。

關係 卡號 標題 狀態
母案 CM-1644 FR-084 防竄改機制(jedi-integrity)資安掃描(一棒,只掃不修)
子卡 CM-1645 T1 套件本體(21 檔,jedi monorepo) 修正待驗證