RFC-0150：選擇不更新

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

產品擁有者適用的政策和功能，可讓使用者選擇不接收軟體更新。
問題
更小鳥
作者
審查人員
提交日期 (年月分)2022-01-14
審查日期 (年-月-日)2022-01-31

編輯這個 RFC

編輯 RFC 中繼資料

摘要

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

提振精神

客戶必須允許 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 - 隱私權
  • hjfreyer@google.com - 元件平台 / FEC
  • 軟體推送團隊

社會化：

這個 RFC 經歷了軟體推送團隊、安全性與隱私權團隊和客戶的設計階段。

規定

本文件中的關鍵字「必須」、「不得」、「必要」、「應」、「不應」、「應該」、「不應該」、「建議」、「可能」和「選用」等關鍵字均以 IETF RFC 2119 中所述的方式解釋。

  • 產品擁有者可以允許使用者選擇不更新，也就是說，除了產品擁有者指定的重要更新 (包括重大安全性更新) 以外，使用者的裝置不會下載或安裝任何更新。
  • 如果裝置選擇不採用更新作業，並且執行「恢復原廠設定」(FDR) 機制，則應選擇重新啟用更新。
  • 每次重新啟動時，設定都必須保持不變，不必由產品層級元件在每次啟動時重新設定 (這會導致產品層級元件與更新檢查之間出現競爭狀況)。
  • 設定的啟用和儲存必須盡可能安全，以避免攻擊者找到權限提升、選擇退出裝置更新作業，並無限期保存該安全漏洞。
  • 如果產品擁有者未決定將選擇不採用選項納入建構作業，就無法在執行階段啟用該選項 (必須使用靜態的編譯時間標記才能完全停用這項功能)。
  • 我們必須記錄有多少使用者 (而非特定使用者) 選擇退出更新，以確保攻擊者不會利用這個選項持續存在安全漏洞。
  • 如果系統處於復原模式，系統應一律允許更新。
  • 如果使用者手動要求更新，即使在停用更新的情況下，仍應允許更新。
  • 建議您只在具備防竄改儲存空間的裝置 (例如重播保護記憶體區塊 (RPMB)) 啟用這項功能。我們並未規定裝置上可以啟用這項功能的裝置，但如果日後需要，我們可以重新審視這個 RFC。
    • 注意：先前提出的設計並不會限制我們只保護儲存空間實作，但依照需求移除防竄改儲存空間可能會導致產品擁有者做出安全取捨。

設計

omaha-client 是正式版系統更新檢查工具。這個程式碼會與產品擁有者或委派代表的 Omaha 伺服器通訊。Omaha 用戶端和伺服器也會定期協商要安裝的系統或套件版本。

我們提議產品擁有者可以在 Software Delivery 設定中，以靜態方式建構旗標，以便在產品上啟用此功能。

讀取及寫入選擇停用選項的值

名為 update-settings-storage 的新 SWD 元件將提供名為 fuchsia.update.config.OptOut 的 FIDL API 來讀取這個選項，並由名為 fuchsia.update.config.OptOutAdmin 的 API 編寫這個選項。您必須在 SDK 中公開這個 API，以允許產品層級元件開啟或關閉選項的值。

fuchsia.update.config.OptOutAdmin API 必須受到能力轉送和 Scrutiny 驗證的嚴格保護，確保不會有未經授權的元件存取該 API。

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

選擇停用的持續性和安全性

提供 OptOut API (update-settings-storage) 的元件必須在重新啟動後保留停用設定的值，且必須保留在受完整性保護的儲存空間中。舉例來說，如果儲存這項設定的 minfs 儲存空間內沒有隨附的雜湊和簽名，將不安全，而且是不允許的。

建議使用硬體防竄改儲存空間 (Fuchsia 裝置目前唯一可用的選項為 RPMB)，以便儲存這項停用設定。我們想要不受防竄改儲存空間的屬性是，除非有簽署的受信任應用程式，否則無法寫入資料，或者可以偵測惡意寫入行為。

更新檢查

在每個排程更新檢查上，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) 向 RPMB 公開 API，而且只會在支援的裝置上以靜態方式加入該 API
  • 修改 VX TA，以在恢復原廠設定 (已進行中介) 時清除選擇不採用標記

更新伺服器

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

效能

這麼做不會對系統或更新檢查效能造成顯著影響。 更新檢查不頻繁 (按小時順序)，而且不會特別容易受到延遲影響。

人體工學

針對這項設定，我們的 Read API 將有助於減少開發人員或使用者可能產生混淆的情況，以及檢查退出狀態的檢查和 Cobalt 記錄。

回溯相容性

此 RFC 不具有任何回溯相容性問題，

安全性考量

更新是 Fuchsia 最重要的安全防護功能。如未進行更新，Fuchsia 團隊就無法修補平台中的安全漏洞。更重要的是，無論使用者是否已選擇停用更新，只要裝置上有這個程式碼，就會對所有使用者造成風險：如果攻擊者獲得足夠的權限，他們可以變更選擇不採用更新設定，並增加永久保留的機會。

這項設計嘗試以下列方式降低風險：

  • 將設定儲存在可防竄改的記憶體 (RPMB) 中
  • 僅允許特定已驗證執行信任應用程式 (TA) 修改設定
    • 只有當裝置處於鎖定模式，且已驗證使用者登入 (在 OOBE 後) 時，才能存取 TA
    • VX TA 比 (例如 minfs) 小許多，而且幾乎是由安全和韌體團隊修改
  • 稽核 TA 轉送並加入許可清單
  • 保有將重大更新 (依產品擁有者定義) 推送到裝置的能力
    • 定義絕對必要更新的條件不在這個 RFC 範圍內。
  • 我們會持續掌握有多少裝置已停用，並在數量出現可疑情況時發送快訊

仍有以下風險：

  • 我們沒有控制會呼叫選擇不採用 API 的產品層級程式碼，必須確保只有高特殊權限元件才能存取此 API
  • 即使攻擊者獲得足夠的核心權限，還是能控制 update-settings-storage 或 VX TA，並要求使用者修改設定

下列安全性改善功能目前不在範圍內，但可在日後的版本中考慮採用：

  • 新增實體狀態規定 (使用者必須以某種方式與裝置互動，而不只是透過產品層級元件)
  • 將設定只能從系統啟動載入程式寫入。這有助於防止設定在造成核心遭駭時，因為使用者體驗和跨平台一致性

隱私權注意事項

這項設計不會對使用者隱私造成重大影響，因為所有記錄或傳播退出狀態都會經過隱私保護的記錄服務，也就是透過「Inspections」或「Cobalt」。

測試

我們會整合測試 update-settings-storage 元件、其與 omaha-client 的互動，以及對 Omaha 伺服器發出的最終要求 (omaha-client產生不同的選擇不採用狀態)。

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

我們也會對每個元件的實作進行單元測試。

最後，我們會與測試團隊討論，確保啟用此功能的產品會對整個整合項目進行端對端測試，與其他更新功能類似。

說明文件

我們必須新增說明文件至新的 FIDL API，以及我們的 OTA 流程說明文件。

缺點、替代項目和未知

「Tombstone」版本

我們可以將「tombstone」版本推送到裝置上，這表示裝置將會停止更新，藉此實作退出更新。

其中有一個明顯的缺點：

  • 選擇停用設定會儲存在驗證開機程序中繼資料 (無法變更)。這意味著更好的安全屬性。

此舉也有明顯的缺點：

  • 我們希望為啟用此功能的每個產品，為每個推送的一般版本產生特定的「tombstone」版本。
  • 實際的選擇不採用應用程式需要透過 OTA 更新，這違反了我們的規定。

將選擇不接受的值儲存在可變動的儲存空間

我們可以將選擇不採用值以 minfs 儲存，以避免某些複雜性，這樣就能將這項功能部署至更多種產品。然而，對於具有權限提升的攻擊者來說，如果攻擊者可以取得 minfs 的寫入權限，便難以無限期地持續攻擊其攻擊。由於 VX TA 比表面區域的最小值 (5.15-15%)，因此取得 Minf 的寫入權限可能比修改「已驗證執行信任應用程式」的狀態更為簡單許多。

如果使用者已選擇退出，請完全略過更新檢查

如果使用者選擇退出，我們可以修改 omaha-client，完全不檢查更新。

優先藝術與參考資料

基本上，Omaha 通訊協定包含 updatedisabled 旗標。基本上，用戶端裝置會告知伺服器正在檢查更新，但不應執行該下載和安裝作業。

Chrome 瀏覽器可以透過企業政策停用更新功能。可能適用於 Fuchsia 裝置的情況，但我們目前沒有企業政策規定。