RFC-0150:選擇不更新

RFC-0150:更新選擇不採用
狀態已接受
區域
  • 軟體推送
說明

產品擁有者可透過這項政策和功能,讓使用者選擇不接受軟體更新。

問題
Gerrit 變更
作者
審查人員
提交日期 (年-月-日)2022-01-14
審查日期 (年-月-日)2022-01-31

摘要

我們將說明產品擁有者的新功能,讓產品使用者可以選擇不接收軟體更新。我們將說明與此機制相關的政策、應如何使用,以及與儲存設定相關的安全性機制。最後,我們將說明系統中的其他元件如何觀察系統是否已選擇不採用更新。

提振精神

客戶要求我們允許 Fuchsia 裝置的使用者選擇不接收更新。無論使用者是否選擇停用,我們都必須以盡可能安全的方式滿足這項規定。

利害關係人

協助人員:

pascallouis@google.com

審查者:

  • kevinwells@google.com - 軟體推送 (SWD)
  • ampearce@google.com - 安全性
  • pascallouis@google.com - Fuchsia 工程委員會 (FEC)

諮詢:

  • borthakur@google.com
  • marvinpaul@google.com - 伺服器導入
  • gtsai@google.com - 伺服器實作
  • enoharemaien@google.com - Privacy
  • hjfreyer@google.com - 元件平台 / 聯邦選舉委員會申請人
  • 軟體推送團隊

社會化:

這項 RFC 已完成設計階段,並與軟體提交團隊、安全性和隱私權團隊,以及客戶進行討論。

需求條件

本文件中的關鍵字「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」和「OPTIONAL」應依 IETF RFC 2119 所述進行解讀。

  • 產品擁有者可以允許使用者選擇不採用更新,也就是說,除了產品擁有者指定的重大更新 (包括重大安全性更新) 以外,使用者裝置不會下載或安裝任何更新。
  • 如果裝置已停用更新功能,且已執行「恢復原廠設定」(FDR),則應重新啟用更新功能。
  • 設定必須在重新啟動時保留,不必在每次啟動時由產品層級元件重新設定 (這會導致產品層級元件和更新檢查之間發生競爭狀態)。
  • 啟用和儲存設定時,必須盡可能確保安全性,以免攻擊者發現權限提升漏洞,選擇不讓裝置更新,並無限期保留該漏洞。
  • 如果產品擁有者尚未決定在建構中加入這項功能 (必須有靜態編譯時間旗標才能完全停用這項功能),則使用者不得在執行階段啟用不採用選項。
  • 我們必須取得有關使用者 (但不是特定使用者) 選擇停用更新的相關指標,以確保攻擊者不會利用這個選項來持續存在漏洞。
  • 如果系統處於復原模式,則應一律允許更新。
  • 如果使用者手動要求更新,即使更新已停用,也應允許該更新。
  • 這項功能僅適用於具備防竄改儲存空間的裝置,例如 Replay Protected Memory Blocks (RPMB)。我們並未要求在沒有防竄改儲存空間的裝置上啟用這項功能,但如果日後有需要,我們可以重新審查這項 RFC。
    • 注意:所提設計並非只限於安全儲存空間實作,但如果將防竄改儲存空間從必要條件中移除,產品擁有者就必須在安全性和便利性之間做出取捨。

設計

omaha-client 是我們的正式版系統更新檢查器。它會與產品擁有者或委派者執行的 Omaha 伺服器進行通訊。Omaha 用戶端和伺服器會定期協商要安裝的系統或套件版本。

我們建議產品擁有者在軟體提交設定中靜態建構標記,以便在產品上啟用這項功能。

讀取及寫入選擇不接受選項值

名為 update-settings-storage 的新 SWD 元件會提供名為 fuchsia.update.config.OptOut 的 FIDL API,用於讀取這個選項,以及名為 fuchsia.update.config.OptOutAdmin 的 API,用於寫入這個選項。這個 API 必須在 SDK 中公開,才能讓產品層級元件切換選項的值。

fuchsia.update.config.OptOutAdmin API 必須透過能力轉送和 Scrutiny 驗證嚴格保護,確保未經授權的元件無法存取該 API。

使用 fuchsia.update.config.OptOut 讀取選擇不採用設定的值時,應允許系統上的許可清單元件使用比 OptOutAdmin 更寬鬆的控管機制。這樣一來,系統和產品層級的元件就能根據裝置是否選擇停用更新,做出決定,並提供此選項的設定和疑難排解檢視畫面。

停用持續性和安全性

提供 OptOut API 的元件 update-settings-storage 必須在重新啟動時保留選擇不採用設定的值,並且必須在完整性保護儲存空間中保留設定。舉例來說,如果沒有搭配儲存空間上的雜湊和簽章,minfs 就無法安全地儲存此設定,因此不允許這麼做。

我們建議您使用硬體防竄改儲存空間 (目前 Fuchsia 裝置唯一可用的選項是 RPMB) 來儲存這項選擇不採用設定。我們希望防竄改儲存空間的特性是,只有經過簽署的「可信任的應用程式」才能寫入,否則系統會偵測到惡意寫入行為。

這些儲存空間 API 會出現在所需的

更新檢查

在每次排定更新檢查時,omaha-client 應使用 OptOut FIDL API 從 update-settings-storage 讀取資料,並使用 Omaha 通訊協定中的現有 updatedisabled 欄位,將選擇不加入的值傳送至 Omaha。

如果系統是在復原分區上執行,updatedisabled 應一律為 false。同樣地,如果更新檢查是由使用者啟動,updatedisabled 一律應為 false

如果 Omaha 伺服器收到的更新檢查結果 updatedisabled 等於 true,則應針對該 Omaha 應用程式的回應傳回 NoUpdate,但產品擁有者指定的重大更新除外。

這裡有另一個替代做法,就是在裝置選擇不接收更新時,完全不傳送任何 Omaha 更新檢查。不過,這個替代方案會拒絕產品擁有者關於有多少使用者選擇停用更新的指標,也會拒絕產品擁有者推送重要更新的功能 (在伺服器上覆寫 updatedisabled 欄位,視需要而定)。

這項選擇不採用設定必須套用至 omaha-client 檢查更新的所有應用程式,包括系統更新和單一套件。

實作

實作工作會由 SWD、韌體、安全性和更新伺服器團隊負責。工作細目大致如下,並應對應要提交的 CL 鏈結。

軟體推送

  • 建立 fuchsia.update.config.OptOut FIDL API
  • 實作 update-settings-storage 元件
  • 在更新檢查時間從 omaha-client 讀取 fuchsia.update.config.OptOut,並以 updatedisabled 標記轉送至 Omaha 伺服器 (除非裝置處於復原狀態,或檢查是由使用者啟動)
  • 在 SDK 中公開 fuchsia.update.config,並將這兩種通訊協定加入許可清單。
  • omaha-client 中新增 Cobalt 指標,以便計算選擇不採用的裝置數
  • omaha-client 的「檢查資料」中公開選擇不採用設定

韌體 / 安全性

  • 透過已驗證執行可信任應用程式 (VX TA),將 API 公開給 RPMB,並在支援的裝置上靜態加入該 API
  • 修改 VX TA,以便在恢復原廠設定期間清除選擇不採用標記 (該標記已由中介服務處理)

更新伺服器

  • 修改 Omaha 規則的產生方式,如果應用程式 updatedisabled 為 true,則針對所有應用程式更新檢查要求傳回 NoUpdate

成效

對系統或更新檢查效能不會有明顯影響。更新檢查作業不頻繁 (以小時為單位),且對延遲不太敏感。

Ergonomics

我們針對此設定的讀取 API 可減少開發人員或使用者可能產生的困惑,Inspect 和 Cobalt 的停用狀態記錄也是如此。

回溯相容性

這個 RFC 沒有任何已知的回溯相容性問題。

安全性考量

更新是 Fuchsia 最重要的安全性功能。沒有更新,Fuchsia 團隊就無法修補平台中的漏洞。更重要的是,無論使用者是否選擇停用更新,裝置上存在這段程式碼都會對所有使用者造成風險:如果攻擊者取得足夠的權限,就能變更停用更新的設定,提高永久保留的機率。

這項設計會透過以下方式降低風險:

  • 將設定儲存在防竄改記憶體 (RPMB) 中
  • 只允許特定的已驗證執行可信任應用程式 (TA) 修改設定
    • 只有在裝置處於鎖定模式,且已驗證的使用者登入 (在 OOBE 後) 時,才能存取 TA
    • VX TA 比 minfs 更小、更簡單,且幾乎只有安全性和韌體團隊會修改
  • 稽核及核准技術支援人員的路由
  • 保留將重要更新 (由產品擁有者定義) 推送至裝置的功能
    • 定義絕對必要更新的條件超出本 RFC 的範圍
  • 我們會持續瞭解有多少裝置選擇停用,並可在該數量出現可疑情況時發出警報

仍存在下列風險:

  • 我們無法控制會呼叫選擇不採用 API 的產品層級程式碼,因此必須確保只有具備高權限的元件才能存取
  • 攻擊者取得足夠的核心權限後,仍可控制 update-settings-storage 或 VX TA,並要求對方修改設定

下列安全性改善項目目前尚未納入範圍,但可考慮在日後的版本中實施:

  • 新增實體存在需求 (使用者必須以某種方式與裝置互動,而非僅透過產品層級元件)
  • 讓設定只能透過開機載入器寫入。這麼做可防範設定遭到核心妥協,但會犧牲 UX 和跨平台一致性

隱私權注意事項

這項設計不會對使用者隱私造成太大影響,因為所有選擇不採用狀態的記錄或傳播作業都會經過隱私權保護的記錄服務:透過檢查的異常終止資料庫,或 Cobalt。

測試

我們會整合測試 update-settings-storage 元件、與 omaha-client 的互動,以及 omaha-client 在各種選擇不採用狀態下產生的對 Omaha 伺服器的最終要求。

我們會透過已驗證執行的受信任應用程式,整合測試 RPMB API。

我們也會個別對各個元件中的實作項目進行單元測試。

最後,我們會與測試團隊合作,確保啟用這項功能的產品已完成整個整合作業的端對端測試,就像其他更新功能一樣。

說明文件

我們需要為新的 FIDL API 和OTA 流程說明文件新增說明文件。

缺點、替代方案和未知因素

「Tombstone」版本

我們可以將「墓碑」版本推送至裝置,藉此實作更新選擇退出功能,表示裝置將不再更新。

這有一個顯著的優點:

  • 停用設定會儲存在驗證開機中繼資料中,而這項資料是不可變動的。這表示安全性屬性更佳。

這也有幾個明顯的缺點:

  • 我們需要針對每個推送的一般版本,為每項啟用此功能的產品產生特定「墓碑」版本。
  • 實際應用選擇不採用功能需要 OTA 更新,這違反我們的規定。

將選擇不採用值儲存在可變動儲存空間中

我們可以在 minfs 中儲存選擇不採用值,藉此避免一些複雜性,讓這項功能可部署至更多產品。不過,如果攻擊者能夠取得 minfs 的寫入存取權,他們就能輕易地提升權限,並持續發動攻擊。取得 minfs 的寫入存取權,可能比修改經過驗證執行的可信任應用程式狀態還要容易,因為 VX TA 的表面積遠小於 minfs,且更容易進行稽核。

如果使用者選擇停用,則完全略過更新檢查

如果使用者選擇停用,我們可以修改 omaha-client,讓系統完全不檢查更新。這有幾個缺點:我們無法取得以 Omaha 為基礎的指標,瞭解有多少使用者選擇退出,而且即使使用者擁有足夠的授權,也無法要求裝置安裝重要更新。

既有技術與參考資料

Omaha 通訊協定包含 updatedisabled 旗標,主要原因如下:用戶端裝置告知伺服器,它正在檢查更新,但不應執行下載和安裝作業。

Chrome 瀏覽器支援透過企業政策停用更新。這可能是潛在 Fuchsia 裝置的用途,但我們目前沒有企業政策規定。