Native Client: A Sandbox for Portable, Untrusted x86 Native Code
原文：https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34913.pdf
注意！本文有刪節！

摘要

本文描述了設計、實現 Native Client(後文用 NC 替代)，一個不受信任的x86本機的沙箱。 NC旨在為基於瀏覽器的應用程式提供本機應用程式的計算效能，而不會影響安全性。 NC使用軟體故障隔離和安全執行時。 NC為二進位制程式碼提供作業系統可移植性，同時支援Web應用程式程式設計環境中通常不能滿足的面向效能的功能，例如執行緒支援，SSE等指令集擴充套件，以及編譯器內在函式和手動編碼彙編程式的使用。我們將這些屬性組合在一個集合第三方工具的開放式架構中。

1 簡介

此處有刪節 現代Web瀏覽器提供擴充套件機制，如ActiveX和 NPAPI，以允二進位制程式碼作為Web應用程式的一部分載入和執行。這樣的體系結構允許外掛繞過以其他方式應用於Web內容的安全機制、更好的利用機器的效能。

但是這些技術並沒有從技術上提出一套安全機制，而是依靠非技術的手段（例如，通過彈出對話方塊手動建立信任關係，或手動安裝控制檯應用程式。）這些非技術在阻止惡意二進位制程式碼的執行顯得無力，導致不便和經濟損失。

這篇論文的工作的主要貢獻是：

• 作業系統和瀏覽器可移植的沙盒x86二進位制模組的基礎結構
• 支援高階效能功能，如執行緒，SSE指令
  ，編譯器內在函式和手工編碼彙編程式
• 一個開放式系統，旨在輕鬆重新定位新的編譯器和語言
• 改進CISC軟體故障隔離，使用x86段以提高簡單性並減少開銷

1.1 威脅模型

NC應該能夠處理來自任何網站的不受信任的模組，其安全性與JavaScript等可接受的系統相當。
當呈現給系統時，不可信模組可以包含任意程式碼和資料。這樣做的結果是NaCl執行時必須能夠確認模組符合我們的有效性規則（詳見下文）。系統拒絕不符合這些規則的模組。此處有刪節
我們在下面討論我們的架構和程式碼有效性規則約束我們沙箱中的NaCl模組。

2 系統架構

NaCl應用程式由一組可信和不可信元件組成。

Figure 1 顯示了用於管理和分割照片的基於NaCl的假設應用程式的結構。它由兩個元件組成：

• 使用者介面，用JavaScript實現並在Web瀏覽器中執行;
• 以及影象處理庫（imglib.nexe），實現為NaCl模組。

在這個假設的場景中，使用者介面和影象處理庫是應用程式的一部分，因此不受信任。瀏覽器元件受瀏覽器執行環境約束，影象庫受NaCl容器約束。這兩個元件都可以跨作業系統和瀏覽器移植，並且NC支援本機程式碼可移植性。在執行照片應用程式之前，使用者已將NC安裝為瀏覽器外掛。請注意，NaCl瀏覽器外掛本身是作業系統和瀏覽器特定的。還要注意它是可信的，即它具有對OS系統呼叫介面的完全訪問許可權，並且使用者相信它不會被濫用。
當用戶導航到承載照片應用程式的網站時，瀏覽器會載入並執行應用程式JavaScript元件。 JavaScript依次呼叫NaCl瀏覽器外掛將影象處理庫載入到NaCl容器中。觀察到本機程式碼模組是靜默載入的 - 沒有彈出視窗要求許可權。 NC負責約束不可信模組的行為。每個元件都在自己的私有地址空間中執行。元件間通訊基於NC的可靠資料報服務IMC（什麼是IMC？模組間通訊？-> Native Client’s IMC sockets interface）。

（PS：圖片來自 BH_US_12_Rohlf_Google_Native_Client_Slides）

對於瀏覽器和NaCl模組之間的通訊，NC提供兩個選項：簡單RPC工具（SRPC）和 Netscape外掛應用程式程式設計介面（NPAPI），兩者都在IMC之上實現。 IMC還提供共享記憶體段和共享同步物件，旨在避免高容量或高頻率通訊的訊息傳遞開銷。
NaCl模組還可以訪問“服務執行時”介面，提供記憶體管理操作，執行緒建立和其他系統服務。該介面類似於傳統作業系統的系統呼叫介面。

在本文中，我們使用“NaCl模組”來指代不受信任的本機程式碼。但請注意，應用程式可以使用多個NaCl模組，並且可信和不受信任的元件都可以使用IMC。例如，照片應用程式的使用者可以選擇使用（假設的）可信NaCl服務進行影象的本地儲存，如 Figure 2 所示。因為它可以訪問本地磁碟，所以儲存服務必須作為本機安裝瀏覽器外掛;它不能作為NaCl模組實現。假設照片應用程式設計為可選地使用穩定的儲存服務;使用者介面將在初始化期間檢查穩定的儲存外掛。如果它檢測到儲存服務外掛，則使用者介面將為其建立IMC通訊通道，並將該通道的描述符傳遞給影象庫，使影象庫和儲存服務能夠通過基於IMC的服務直接通訊（SRPC、共享記憶體等）。在這種情況下，NaCl模組通常將靜態連結到庫，該庫提供用於訪問儲存服務的過程介面，隱藏IMC級通訊的細節，例如它是否使用SRPC或者它是否使用共享儲存器。

請注意，儲存服務必須假定影象庫不受信任。該服務負責確保它僅提供與使用者隱含合同一致的請求。例如，它可能會對照片應用程式使用的總磁碟強制執行限制，並可能進一步限制操作僅引用特定目錄。
NC非常適合需要純計算的應用程式元件。它不適用於需要建立流程，直接檔案系統訪問或不受限制地訪問網路的模組。諸如儲存之類的可靠設施通常應在NC之外實現，從而鼓勵單個元件的簡單性和健壯性，並對所有元件進行更嚴格的隔離和審查。這種設計選擇與微核心作業系統設計相呼應。

（PS:微核心作業系統設計資料:A new kernel foundation for UNIX development、The V distributed system、Unix as an Application Program）

我們現在將更詳細地描述關鍵NaCl系統元件的設計。

2.1 沙盒

NC是圍繞特定於x86的內部程序“內部沙箱”構建的。我們相信內部沙箱是健壯的;無論如何，為了提供深度防禦（PS:Defense-in-depth against computer viruses)我們還開發了第二個“外部沙箱”，它在過程邊界處調解系統呼叫。外沙箱基本上類似於現有結構（PS:Improving host security with system call policies和A secure enviroment for untrusted helper applications），我們在本文中不會詳細討論。
內部沙箱使用靜態分析來檢測不受信任的x86程式碼中的安全缺陷。以前，由於自修改程式碼和重疊指令等實踐，此類分析對任意x86程式碼提出了挑戰。在NC中，我們通過一組對齊和結構規則禁止此類實踐，這些規則在觀察時確保可以可靠地拆卸本機程式碼模組，以便在反彙編期間識別所有可到達的指令。通過可靠的反彙編作為工具，我們的驗證器可以確保可執行檔案僅包含法律指令的子集，禁止不安全的機器指令。
內部沙箱進一步使用x86分段記憶體來約束資料和指令記憶體引用。利用現有硬體實現這些範圍檢查極大地簡化了對記憶體引用進行限制所需的執行時檢查，從而降低了安全機制對效能的影響。

此內部沙箱用於在本機作業系統程序中建立安全子域。通過這種組織，我們可以將可信服務執行時子系統放置在與不受信任的應用程式模組相同的程序中，並使用安全的介面，以便將控制從受信任程式碼安全地轉移到不受信任的程式碼，反之亦然。雖然在某些情況下，程序邊界可以有效地包含記憶體和系統呼叫副作用，但我們相信內部沙箱可以提供更好的安全性。我們通常假設作業系統沒有缺陷，因此程序障礙可能存在缺陷，而且作業系統可能會故意將資源（如共享庫）對映到所有程序的地址空間，如Microsoft Windows中所發生的那樣。實際上，我們的內部沙箱不僅將系統與本機模組隔離開來，而且還有助於將本機模組與作業系統隔離開來。

2.2 執行時

沙箱可防止不必要的副作用，但通常需要一些副作用才能使本機模組變得有用。對於程序間通訊，NC提供可靠的資料報抽象，即“模組間通訊”服務或IMC。 IMC允許可信和不可信模組傳送/接收由無型別位元組陣列組成的資料報以及可選的“NaCl資源描述符”，以便跨過程邊界共享檔案，共享儲存物件，通訊通道等。 IMC可以由受信任或不受信任的模組使用，並且是兩個更高級別抽象的基礎。第一個是簡單遠端過程呼叫（SRPC）工具，它提供了方便的語法，用於在NaCl模組邊界定義和使用子程式，包括在瀏覽器中從JavaScript呼叫NaCl程式碼。第二個是NPAPI，它提供了一個熟悉的介面來與瀏覽器狀態進行互動，包括開啟URL和訪問DOM，這符合現有的內容安全約束。這些機制中的任何一種都可用於與傳統瀏覽器內容的一般互動，包括內容修改，處理滑鼠和鍵盤活動以及獲取其他網站內容;基本上所有可用於JavaScript的資源。

服務執行時負責提供容器，NaCl模組通過容器彼此互動並與瀏覽器互動。服務執行時提供通常與應用程式程式設計環境相關聯的一組系統服務。它提供 sysbrk() 和 mmap() 系統呼叫，原語以支援 malloc()/ free() 介面或其他記憶體分配抽象。它提供了POSIX執行緒介面的子集，帶有一些NaCl擴充套件，用於建立和銷燬執行緒，條件變數，互斥鎖，訊號量和執行緒區域性儲存。我們的執行緒支援足夠完整，允許英特爾的執行緒構建塊[51]的埠到NC。服務執行時還提供公共POSIX檔案I/O介面，用於通訊通道上的操作以及基於Web的只讀內容。由於這些介面無法訪問本地檔案系統的名稱空間，因此無法實現本地副作用。
為了防止意外的網路訪問，簡單地省略了諸如 connect() 和 accept() 之類的網路系統呼叫。 NaCl模組可以通過瀏覽器中的JavaScript訪問網路。此訪問受限於適用於其他JavaScript訪問的相同約束，對網路安全性沒有任何淨影響。
NaCl開發環境主要基於Linux開源系統(PS:Ubuntu 14.04)，大多數Linux和Unix開發人員都很熟悉。我們發現移植現有的Linux庫通常很簡單，大型庫通常不需要更改原始碼。

2.3 潛在威脅

總的來說，我們認為以下是潛在攻擊者可能試圖利用的系統元件：

• 內部沙箱：二進位制驗證
• 外部沙箱：OS系統呼叫攔截•服務執行時二進位制模組載入器
• 服務執行時介面
• IMC通訊介面
• NPAPI介面

除了內部和外部沙箱，系統設計還包含CPU和NaCl模組黑名單。這些機制將使我們能夠根據我們對各種元件的穩健性的信心以及我們對如何在效能，靈活性和安全性之間實現最佳平衡的理解來整合保護層。
在下一節中，我們希望證明這些設施的安全實現是可能的，並且在我們自己的實現工作中做出的具體選擇是合理的。

3 NC實現

書接下文：https://blog.csdn.net/yeshennet/article/details/83792533

玩～