A1 檢查結果：設備全鏈＋套件共用骨架（jedi-asset）

檢查日期 2026-09-16｜對應卡片 CM-1814｜檢查範圍 45 個檔案

掃描目標 /Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/jedi-asset，revision cdb0d0f4f4c2（branch main，工作區乾淨），mode scan，scope 45 個檔案（設備模組全鏈＋套件共用骨架，information_system 那半排除，屬第 2 棒範圍），effort low。找到 2 個候選，1 個通過驗證（MEDIUM，device.read 能力點只掛了前端選單，API 端點沒守），另 1 個被三位檢查員一致駁回（誤判「強制隔離」漏套用在設備表上）。

low 強度：一位研究員讀完 45 個檔案就提報候選，未做元件盤點、未做威脅建模、未跑額外密鑰專項掃描，coverage.collapsed／completenessCheckOutcome 均為 not-applicable（低強度本就不跑盤點）。驗證跑了 1 輪（coverage.verificationRun=1），沒有候選遺失（lostCandidates 空）、沒有嚴重度被降低（severityLowered 空）。

工具只咬到 2 個候選、覆蓋卡片列的六個重點裡的其中一個（①）。 ②③④⑤⑥ 五個重點工具完全沒有提出任何候選，全部由首腦回頭開檔／連 DEV DB 唯讀查證補上，詳見下方「卡片重點逐項人工查證」段。

F1 — 設備讀取端點只驗登入，未驗已宣告的 device.read 能力點 (MEDIUM, confidence medium)

現況：已修（M19-1，FR-114.1-6，套件 commit 0ecdd3a1；缺能力點的既有角色由 CM-2032 補齊，1.21.0 出貨）

Impact. 任何在租戶內已登入的使用者，即使他的角色被刻意拿掉「查看設備」的權限，仍可直接打 API 拿到該租戶完整的設備清冊（主機名稱、IP、作業系統版本、製造商），造成內部網路拓樸資訊外洩給租戶內未授權的人。

Where. jedi_asset/api/routes/device_route.py:37（DeviceListRoute.post，讀取動作在 :46）；同病的還有 :56（DeviceMenuRoute.get）、:68（DeviceDetailRoute.get）、:106（DeviceReferenceRoute.get）。

What. jedi_asset/plugin/contract.py:29-38 把 device.read／information-system.read 宣告為正式能力點（CAPABILITIES 元組），也確實透過 migrations/003-asset-ui-routes.sql 綁進 route_capabilities（前端選單認）。但 device_route.py 的四支讀取端點只掛 @auth_required（只驗有沒有登入），從未掛 @capability_required(...)——寫入端點（DeviceDetailRoute.put:78、.delete:90、DeviceCreateRoute.post:124）每一支都多掛了 @capability_required，形狀對照明顯。device.read 這個能力點因此只在前端隱藏選單項目生效，API 層完全不驗。

Exploit scenario. 租戶管理員指派一個限制角色（沒有 device.read 能力點）給約聘人員。前端選單看不到「設備管理」項目，但該帳號直接發 POST /api/1.0/devices（帶自己有效的登入憑證），一樣拿回完整設備清冊——繞過了本來要生效的讀取限制。

Preconditions.

• 攻擊者已持有目標租戶內的有效登入憑證
• 攻擊者的角色被指派時，刻意不給 device.read（也就是仰賴一個實際不存在的伺服器端限制）

Fix. 比照寫入端點的既有形狀，在 AssetPluginConfig（jedi_asset/plugin/contract.py）新增一個 device_read_capability 設定槽（預設值 device.read），然後在 DeviceListRoute.post、DeviceMenuRoute.get、DeviceDetailRoute.get、DeviceReferenceRoute.get 加上 @capability_required(lambda rt: rt.config.device_read_capability)——與現有 device_create_capability／device_update_capability／device_delete_capability 同一套機制。這是產品決策，不是純技術修法：目前 device.read／information-system.read 這兩個能力點是「宣告了、DB 也綁了、但刻意不在 API 層守」的設計（contract.py 檔頭原話：「read 兩項 BE route 不守（守門只在寫入類）」）——若維持這個決策，此發現應視為「已知取捨」而非漏洞；若要真正生效，才照上述方式補。

Verification. 3/3 三位檢查員一致確認成立（reachability／impact／defenses），嚴重度維持 MEDIUM（面板未調整）。

低強度單研究員掃描提報 2 個候選，三位檢查員各自獨立對兩個候選投票：F1（3/3 一致通過，MEDIUM）、另一候選 C1（3/3 一致駁回，見下）。驗證章狀態 verified。

🔴 本棒吸取 FR-097 L1／L2 的教訓：低強度工具只跑一位研究員，卡片列的六個重點很可能大半沒被碰到。逐項回頭人工核對如下。

① 讀取端點沒有權限檢查（工具已報＝F1，額外補查跨端點一致性與被引用查詢）

• 四支讀取端點逐一核對：device_route.py 的 DeviceListRoute.post（:37/:46）、DeviceMenuRoute.get（:56/:59）、DeviceDetailRoute.get（:68/:71）、DeviceReferenceRoute.get（:106/:109）全部只有 @auth_required，一致無例外。寫入端點三支（put:78、delete:90、create post:124）全部有 @capability_required。與 F1 描述一致，工具已報。
• DeviceReferenceRoute（被引用查詢）會不會透露別家客戶的關聯資訊：get_device_reference_count()（device_service.py:126-138）先呼叫 get_device_by_uid(uid)，查不到該設備直接 404（NotFound），所以要拿到引用計數，攻擊者得先猜中一個存在的 uid（UUID 格式，不可枚舉）；而 uid 本身是否跨租戶可查，取決於底層 RLS（見③）是否擋掉別家租戶的列——實測 DEV 環境 RLS policy 對 cm_app 這個連線角色是有效的（見③），所以跨租戶查詢會直接查不到該設備、回 404，不會洩漏引用數字本身。這條沒有獨立問題，涵蓋在 F1 同一組讀取端點裡。（工具未報，人工查證）

② 送空條件會不會回整張表（工具未報，人工查證，命中已知共用線）

• DevicePageQueryRequest.filters（serializers/device.py:31-32）用 missing={}，DeviceQueryEntity 全部欄位預設 None（domain/entity/device_query_entity.py），to_dict() 只回有值的條件——送一個空的查詢請求確實會落到 jedi-common 共用底層 base_repository_impl.get_all_by_fields_and_pager()（:38-87 一路查下去）的無條件查詢，回傳全表（在分頁限制內）。
• 這與跨 arc 總表 §3.1 第 70 項是同一根因（源頭在 jedi-common 的 base_repository_impl.py，所有套件共用），不獨立升級成新發現，照卡片交代標記即可。
• 補充：get_devices_and_pager 有走分頁（PageSpec），所以「送空條件」在有分頁的清單端點不是一次把全表塞進一個 response，但仍是「未限定客戶只查自己那部分之外的任何東西」的預設放行行為——真正擋線的是 RLS（見③），底層本身沒有防護。

③ 設備表刻意只開一般隔離、沒開「強制」模式——取捨的代價（工具已駁回一個誤判候選，人工核對取捨是否安全）

• 工具第二個候選（被駁回的 C1）：三位檢查員（reachability／impact／defenses）一致判定 FALSE_POSITIVE。理由是候選假設「FORCE RLS 缺席會讓表擁有者繞過隔離」——但攻擊面是應用程式連線角色 cm_app，不是表擁有者 cmmgr，cmmgr 才是真正的表擁有者（rolsuper=t, rolbypassrls=t）。首腦 DEV 實查同一件事，結果一致：

  relname | owner  | rls_enabled | rls_forced
  devices | cmmgr  | t           | f

  cmmgr 是超級使用者，本來就永遠繞過 RLS（無論 FORCE 與否），這不是漏洞是 PostgreSQL 的既定行為；而應用程式實際查詢用的角色是 cm_app（rolsuper=f, rolbypassrls=f，.env 的 DB_USER=cm_app），對非擁有者、非超級使用者的角色，ENABLE ROW LEVEL SECURITY（不需要 FORCE）就已經足夠生效——FORCE 只在「擁有者自己執行查詢」時才有意義，而正常運行時擁有者從不會是應用程式連線角色。（工具已駁回，首腦覆核同意駁回是正確判斷）
• 取捨代價的真正問題：檔頭寫的風險是「INSERT policy 沒有 super_admin 逃生門且要求 org 相符，FORCE 一旦生效會擋掉 org 為空的使用者新增」——這句話講的是 INSERT policy 本身的設計取捨（見④），跟 FORCE/ENABLE 的差異其實關係不大（因為擁有者永遠不會是應用程式連線角色，FORCE 在這個產品的部署模型下基本不會改變任何實際行為）。（工具未報，人工查證：檔頭的風險敘述本身有點誤導，真正該關注的是④的 INSERT policy 設計，不是 FORCE 開關本身）

④ 四條隔離規則的實際內容（工具未報，人工查證）

DEV 實查 pg_policies，四條規則逐字比對：

• 查／改／刪三條範圍一致（都是純租戶維度、都有 super_admin 逃生門），新增那條範圍明顯較窄（多加一個 org 維度、沒有 super_admin 逃生門）。這是刻意設計（檔頭已說明），但代價是：一個 is_super_admin=true 的帳號可以查看／修改／刪除任意租戶的設備，卻無法新增任意租戶的設備（除非同時符合 org 條件或 can_read_all_orgs）——這個不對稱本身不是安全漏洞（更嚴格不是問題），但會讓平台管理員操作某些跨租戶維運腳本時，新增設備會意外失敗、查改刪卻正常，是維運陷阱不是安全漏洞。（工具未報，人工查證）
• 「新增那條要求部門相符會不會讓某些使用者永遠新增不了」：org_unit_id 可為 NULL（infra/models/device.py 與 migrations/001-asset-tables.sql:65 都沒有 NOT NULL），app_org_allowed_for_session(NULL) 判定函式對 NULL 一律回 false（002 檔頭原話）。若某使用者自己的 org_unit_id context 是 NULL（帳號沒有部門歸屬），且他試圖新增一筆 org_unit_id 也是 NULL 的設備，app_org_allowed_for_session(NULL) 回 false 且沒有 can_read_all_orgs／super_admin 逃生門時會被擋——這是檔頭自己承認的已知風險，此次核對確認風險描述屬實、目前無額外逃生門。（工具未報，人工查證）

⑤ 共用骨架的守門殼——必填插槽沒填會怎樣（工具未報，人工查證，結果良好）

• plugin/assembly.py:_assert_api_wiring()（:72-89）在掛 route 之前先檢查三個守門欄位（auth_required／capability_required／current_user_login_name），任一個缺了直接 raise RuntimeError，拒絕掛載，錯誤訊息裡明白寫出後果（「掛上去會讓九條資產端點變成公開端點」）。這與跨 arc 總表 §6 第 13 項那種「零件沒組裝進去就直接放行」的形狀相反——這裡是正確的「吵鬧拒絕」設計，不是漏洞。
• 但三張選填的 port（identity／reference_counter／user_directory）缺了是安靜降級（assembly.py:build_services() 檔頭原話：「三者降級都是安靜回空值，症狀像資料掉了而不是漏接線」）——這是刻意的、已經在檔案內部文件化的行為，不是意外，已知取捨不算新發現。
• _assert_api_wiring 只檢查這三個必填欄位存不存在（is None），不檢查它們的「型別」或「行為是否正確」——例如若宿主傳了一個永遠回傳 True 的假 auth_required，這支檢查完全看不出來。這屬於介面契約本身的限制（Python 沒有強型別檢查器擋這個），不是套件的疏漏。（工具未報，人工查證）

⑥ 三支 SQL——授權範圍／選單覆蓋／外鍵行為（工具未報，人工查證）

• 授權範圍：002-asset-rls-grants.sql:153-156 的 GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE public.devices TO cm_app 是標準範圍（不含 TRUNCATE／REFERENCES／TRIGGER 等更危險的權限），序列權限 GRANT ALL ON SEQUENCE 是常見寫法（nextval 需要）。範圍合理，沒有過寬問題。
• 選單那支重複執行會不會覆蓋客戶改過的值：003-asset-ui-routes.sql 兩段 INSERT INTO public.ui_routes 都帶 WHERE NOT EXISTS (SELECT 1 FROM public.ui_routes WHERE name = '...')（:12、:17），route_capabilities 兩段都帶 ON CONFLICT (route_id, capability_id) DO NOTHING（:24、:31）——都是冪等、已存在就跳過的寫法，不會覆蓋客戶改過的 enable／sort／icon 等值。這條沒有問題。
• 外鍵設定有沒有讓刪除行為出乎意料：002-asset-rls-grants.sql:18-27 補掛的 devices_tenant_fk／devices_org_fk 都是 ON DELETE RESTRICT——刪除一個租戶或部門若底下還有設備會被資料庫擋下（拋錯），不會發生「刪租戶連帶設備資料也悄悄消失」這種資料外洩風險反向情境（RESTRICT 是最保守的選項）。這條沒有問題。
• 補充：001-asset-tables.sql 的 DDL 全部走 CREATE TABLE IF NOT EXISTS / DO $$ ... EXCEPTION WHEN duplicate_object THEN NULL，重複執行冪等，符合套件的自我要求（檔頭「DDL 必須全部冪等」）。

「工具報的這條是真的嗎」→ ✅ 可信

F1 通過三位獨立檢查員一致投票（reachability／impact／defenses 全數判定成立），三位都各自從路由層讀到 contract.py 的能力點宣告，完整走過一遍程式碼路徑，沒有停在推測層次。工具駁回的第二個候選（表擁有者繞過 RLS）同樣是三位一致、且首腦以 DEV 實際唯讀查詢覆核同意，判斷正確。

「掃描結果是不是完整」→ ❌ 明顯不完整

這是最低強度快篩，一位研究員讀完 45 個檔案就提報候選，不做元件盤點、不做威脅建模、不跑額外密鑰專項掃描。 卡片交代的六個重點裡，工具只碰到其中一個半（①讀取端點沒守＝F1、③的其中一個角度＝駁回一個關於 FORCE RLS 的誤判候選）；②送空條件、④四條規則的具體內容、⑤守門殼行為、⑥三支 SQL 的授權/覆蓋/外鍵細節，全部由首腦回頭開檔並連 DEV DB 唯讀查證後補上。這與 FR-097 L1／L2 撞到的教訓一致：低強度工具很容易只咬住程式碼裡最顯眼的一到兩個攻擊模式，對其他同樣重要但不那麼「符合掃描器直覺」的問題（設計取捨的代價、選單覆蓋、外鍵行為）視而不見。

人工查證裡最值得留意的是③（首腦覆核駁回正確——這支套件的隔離設計沒有問題）與④（發現一個維運陷阱：super_admin 能查改刪任意租戶設備、卻新增不了，因為 INSERT policy 少了 super_admin 逃生門——不是安全漏洞，是操作不對稱，未另計新發現）。

卡片開卡前已經查證過兩件事，這一棒掃到的內容與這兩件一致，不重複計數：

1. 兩張表的資料庫隔離都有開、都有客戶歸屬欄位——本棒 DEV 實查同樣核對：devices 有 RLS（ENABLE，非 FORCE）、四條規則、tenant_id/org_unit_id 欄位齊備；information_systems 有 RLS（ENABLE + FORCE）。與卡片開卡前判定一致。
2. 八個權限點全部是客戶層級——DEV 實查 public.capabilities，device.*／information-system.* 各四個，is_platform 欄位全部 false。與卡片開卡前判定一致，屬正確設計。
3. 資訊系統那半（15 檔）不在本棒範圍——本棒未觸碰 information_system_route.py 等檔案，屬第 2 棒（另一張子卡）。

📄 本報告由 runner（本棒 session）依工具原始產物撰寫，六個卡片重點的人工查證亦由本棒完成，非首腦補寫。