gVisor 深度解析基于 Go 的應用內核、Sentry/Gofer 架構與 runsc OCI 運行時實戰【免費下載鏈接】gvisorApplication Kernel for Containers項目地址: https://gitcode.com/GitHub_Trending/gv/gvisor導讀gVisor 是運行在用戶態的應用內核Application Kernel它以內存安全的 Go 語言重實現了 Linux 系統調用接口為容器提供介于傳統容器與虛擬機之間的強隔離層。本文以 gVisor 官方架構文檔為主線系統講解其設計定位、與 seccomp/VM 的路線差異、Sentry 與 Gofer 雙進程架構、runscOCI 運行時的命令與使用方式并結合本倉庫源碼給出關鍵實現路徑幫助你從原理到實戰完整掌握 gVisor 的隔離機制。什么是 gVisor為容器而生的應用內核gVisor 在運行應用與宿主機操作系統之間提供了一層強隔離。它不是一個運行在虛擬機里的 Linux 內核而是一個實現 Linux 風格接口Linux-like interface的應用內核與 Linux 不同它使用內存安全的語言Go編寫并且運行在用戶態userspace——從宿主內核的視角看gVisor 本身只是一個普通的用戶進程。gVisor 附帶了一個符合 Open Container InitiativeOCI 規范的運行時名為runsc。runsc與 Docker、Kubernetes 等現有容器工具鏈無縫集成可以很方便地運行沙箱化容器。gVisor 支持三種使用路徑官方為每一種都提供了詳細指南Docker 快速開始上手最快的方式Kubernetes 快速開始在 K8s 集群中用 gVisor 隔離 PodOCI 快速開始專家模式直接使用runsc定制環境。gVisor 做什么把內核接口搬進獨立的沙箱gVisor 提供的是一個虛擬化環境用于對容器進行沙箱化。其核心思想是將通常由宿主內核實現的系統接口移入一個獨立于每個沙箱的應用內核中從而最小化容器逃逸container escape攻擊的成功面。gVisor 的關鍵權衡在于不引入大的固定開銷gVisor 不是為每個沙箱預分配固定的物理資源而是在運行時按需分配 CPU、內存等宿主機資源保留進程式的資源模型從資源利用的角度看gVisor 沙箱與普通進程類似資源可以靈活伸縮這與固定資源池的虛擬機模型有本質區別。第三條隔離路線與 seccomp 和 VM 的本質區別在 gVisor 出現之前業界對容器提供更強隔離通常走兩條路線而 gVisor 明確不屬于任何一條gVisor不是系統調用過濾器如seccomp-bpf也不是 Linux 隔離原語的包裝如firejail、AppArmor 等gVisor也不是日常意義上的虛擬機如 VirtualBox、QEMU。gVisor 走的是第三條路線在獲得虛擬機大量安全收益的同時保留普通用戶態應用的低資源占用、快速啟動和靈活性。下面逐一分析三條路線的權衡。路線一機器級虛擬化Machine-level virtualizationKVM、Xen 這類方案通過虛擬機監視器VMM向客戶機內核暴露虛擬化硬件。這種虛擬化硬件通常是啟蒙過的paravirtualized并可通過 balloon 驅動、半虛擬化自旋鎖等機制改善客戶機與宿主機之間的可見性。在獨立虛擬機中運行容器可以獲得優秀的隔離性、兼容性和性能盡管嵌套虛擬化可能帶來挑戰但通常需要額外的代理proxy和代理進程agent并可能需要更大的資源占用和更慢的啟動時間。路線二基于規則的執行Rule-based executionseccomp、SELinux、AppArmor 等方案允許為應用或容器指定細粒度的安全策略依賴宿主內核內的鉤子hooks執行規則。如果攻擊面可以收縮得足夠小這確實是在保持原生性能的同時沙箱化應用的好方法。但在實踐中為任意的、之前未知的應用可靠地定義策略極其困難甚至不可能這使得該方案難以普適應用。因此基于規則的執行通常需要與其他層次疊加形成縱深防御defense-in-depth。路線三gVisor——攔截系統調用并充當客戶機內核gVisor 提供了與上述兩者都不同的第三種隔離機制攔截應用的系統調用并扮演客戶機內核的角色無需通過虛擬化硬件做翻譯。可以這樣理解 gVisor 的定位把它看作合并的客戶機內核 VMM或者把它看作加強版的 seccompseccomp on steroids。這一架構帶來的收益與代價都非常明確收益資源占用靈活基于線程和內存映射而非固定的客戶機物理資源同時降低了虛擬化的固定成本代價應用兼容性有所降低且每次系統調用有更高的開銷per-system call overhead。在此基礎上gVisor 還會疊加基于規則的執行手段來實現縱深防御下文安全模型部分詳述。gVisor 的思路與User Mode LinuxUML類似但 UML 在內部虛擬化硬件因此資源占用是固定的而 gVisor 直接面向系統調用接口不虛擬化硬件從而保持了資源的靈活性。每種方案都有各自的適用場景例如機器級虛擬化在高密度部署上面臨挑戰而 gVisor 對系統調用密集的工作負載性能可能較差。為什么選擇 Go內存安全內核gVisor 使用 Go 編寫目的是避開長期困擾內核的安全陷阱強類型strong types內建的邊界檢查built-in bounds checks無未初始化變量無 use-after-free無棧溢出內建競態檢測器race detector。但使用 Go 也有挑戰Go 運行時常常引入性能開銷。這正是安全性與性能之間 trade-off 的直接體現也是 gVisor 文檔與 性能指南 反復強調的內容。沙箱組件全景Sentry、Gofer 與 Application一個 gVisor 沙箱由多個進程組成這些進程共同構成一個可以運行一個或多個容器的環境。每個沙箱擁有自己獨立的Sentry實例Sentry 是運行容器并攔截、響應應用系統調用的內核沙箱中的每個容器擁有自己獨立的Gofer實例Gofer 為容器提供文件系統訪問。Sentry最大的組件真正的應用內核Sentry 是 gVisor 中最大的組件可以被看作一個應用內核。它實現了應用所需的全部內核功能包括系統調用system calls信號投遞signal delivery內存管理與缺頁處理邏輯memory management and page faulting logic線程模型threading model以及其他內核功能。從本倉庫源碼結構看Sentry 的實現體量非?？捎^pkg/sentry/ 目錄下包含 800 余個 Go 源文件覆蓋了 系統調用、進程管理、文件系統、網絡棧gVisor 自研的 netstack等模塊。關鍵機制應用發起系統調用時Platform 會把調用重定向到 Sentry由 Sentry 完成必要的工作來服務該調用。需要特別強調的是Sentry不會把系統調用透傳給宿主內核作為用戶態應用Sentry 確實會發起一些宿主系統調用來支撐自身運行但絕不允許應用直接控制它發起的系統調用例如Sentry 不能直接打開文件超出沙箱范圍的文件系統操作非沙箱內部的/proc文件、pipe 等都會交給 Gofer 處理。在 pkg/sentry/platform/platform.go 中可以找到Platform接口的完整定義它提供NewAddressSpace()創建內存上下文與NewContext()創建執行上下文等抽象是所有攔截機制的公共底座。Gofer受限的文件系統代理Gofer 是一個標準的宿主進程隨每個容器啟動并通過9P 協議pkg/p9/p9.go經由 socket 或共享內存通道與 Sentry 通信。Gofer 的實現主體位于 pkg/sentry/fsimpl/gofer/其中 filesystem.go 定義了文件系統核心邏輯此外較新的 gVisor 還引入了性能更高的 lisafs 通信協議README 中有說明。安全模型的關鍵點在于Sentry 進程運行在一個受嚴格 seccomp 限制的容器中沒有文件系統資源訪問權Gofer 作為略多信任一點的伴生進程中介mediate所有對文件系統資源的訪問這為沙箱增加了一層額外的隔離即使 Sentry 被攻破也無法直接訪問宿主文件系統。Application無需修改的普通 Linux 二進制Application 就是通過 OCI runtime bundle 提供給 gVisor 的普通 Linux 二進制。gVisor 的目標是提供與 Linux 等價的環境因此應用應當可以不加修改地運行。不過 gVisor 目前并未實現每一個系統調用、每一個/proc文件或/sys文件因此可能出現部分不兼容。詳細情況見 兼容性指南倉庫中還有對應的 兼容性測試 作為佐證。runscOCI 運行時入口運行沙箱化容器的入口是runsc可執行文件。runsc實現了 OCI 運行時規范Docker 和 Kubernetes 都使用該規范。這意味著runsc可以直接運行 OCI 兼容的filesystem bundle——bundle 由兩部分組成config.json包含容器配置root filesystem容器的根文件系統。runsc實現了多個命令用于啟動、停止、列出和查詢容器狀態等操作start、stop、list、status 等。從本倉庫源碼看runsc/main.go 是二進制入口它調用maincli.Main()真正的命令分發邏輯在 runsc/cli/cli.go 中基于google/subcommands框架注冊所有子命令并統一完成日志、配置解析config.NewFromFlags、OCI spec 加載FetchSpec等初始化工作。所有子命令實現位于 runsc/cmd/ 目錄下。用 runsc 直接運行 OCI 容器按照 安裝指南 完成安裝后可以按 OCI 快速開始 的步驟操作# 1. 創建 bundle 根目錄 mkdir bundle cd bundle # 2. 用 Docker hello-world 鏡像導出 rootfs mkdir --mode0755 rootfs docker export $(docker create hello-world) | sudo tar -xf - -C rootfs --same-owner --same-permissions # 3. 生成 config.json指定運行 /hello 程序 runsc spec -- /hello # 4. 運行容器 sudo runsc run hello快速驗證runsc do 與 dmesgrunsc do是專為快速測試提供的便捷命令例如$ sudo runsc do echo Hello world Hello world注意命令前的sudo沙箱設置過程需要特權具體用于建立用戶態網絡棧一旦沙箱設置完成gVisor 會重新執行自身并丟棄所有特權之后才運行任何不可信代碼。對于不需要網絡的沙箱可以無 root 運行$ runsc --rootless --networknone do echo Hello world Hello world如何確認 gVisor 真的在工作試試會涉及宿主內核的操作例如讀取內核日志的dmesg(1)# 無 gVisor未沙箱化 $ dmesg dmesg: read kernel buffer failed: Operation not permitted # 有 gVisor沙箱化 $ runsc --rootless --networknone do dmesg [ 0.000000] Starting gVisor... [ 0.498943] Waiting for children... [ 0.972223] Committing treasure map to memory... [ 1.192981] Segmenting fault lines... [ 1.591823] Verifying that no non-zero bytes made their way into /dev/zero... [ 1.787191] Consulting tar man page... [ 2.083245] Searching for needles in stacks... [ 2.534575] Forking spaghetti code... [ 2.742140] Digging up root... [ 2.921313] Gathering forks... [ 3.342436] Creating cloned children... [ 3.511124] Setting up VFS... [ 3.812459] Setting up FUSE... [ 4.233037] Ready!這組幽默的輸出直接證明了dmesg(1)二進制在與gVisor 內核對話而非宿主 Linux 內核——這些日志是 gVisor 系統調用處理器按需生成的虛構內容因此每次運行結果都不同。需要提醒runsc do默認把宿主的整個文件系統以只讀方式暴露給沙箱這只是測試便利功能。在實際作為 OCI 容器運行時宿主文件系統映射嚴格由 OCI 配置決定gVisor 只會暴露配置指定的路徑并執行pivot_root(2)作為縱深防御禁止訪問其他宿主目錄。因此從安全角度測試時更推薦 安裝為 Docker 運行時 后使用$ sudo docker run --rm --runtimerunsc -it -v /tmp/vol:/vol ubuntu /bin/bash這條命令會在 gVisor 沙箱內啟動一個 Bash shell并把宿主目錄/tmp/vol映射到沙箱內的/vol可以嘗試探查沙箱邊界。平臺機制系統調用攔截的底層實現系統調用與缺頁的攔截依賴所謂的gVisor Platform。在 平臺指南 中Platform接口的核心可以簡化為type Platform interface { NewAddressSpace() (AddressSpace, error) NewContext() Context } type Context interface { Switch(as AddressSpace, ac arch.Context) (..., error) } type AddressSpace interface { MapFile(addr hostarch.Addr, f File, fr FileRange, at hostarch.AccessType, ...) error Unmap(addr hostarch.Addr, length uint64) }當前支持三種平臺實現各有不同的性能與硬件需求平臺攔截機制適用場景備注systrap默認基于 seccomp 的SECCOMP_RET_TRAP讓內核向觸發線程發送SIGSYS將控制權交給 gVisor虛擬機內部、無虛擬化支持的機器2023 年年中取代 ptrace 成為默認平臺KVM使用內核 KVM 功能Sentry 同時充當客戶機 OS 與 VMM裸機bare-metal場景性能最佳在嵌套 VM 中可行但因嵌套虛擬化開銷通常不如 systrapptrace使用PTRACE_SYSEMU執行用戶代碼不允許執行宿主系統調用任何 ptrace 可用的環境普適上下文切換開銷高已不再支持預計最終移除選擇建議裸機跑 KVM虛擬機內或無虛擬化支持時用 systrap。平臺對系統管理員是透明可互換的但從安全角度看它們依賴的 Linux 內核功能不同攔截行為也有差異。安全模型縱深防御與攻擊面控制gVisor 的安全設計圍繞限制系統 API 攻擊向量展開核心原則在 安全模型 中闡述不直接透傳任何系統調用給宿主每個受支持的調用都在 Sentry 中有獨立實現與宿主實現同時出現相同漏洞的可能性很低。這帶來一個推論應用使用的所有內核特性都需要在 Sentry 內實現只實現通用、普適的功能不實現也不透傳擴展屬性、raw socket、ioctl 等專用 API最小化暴露給 Sentry 的宿主面Sentry 不允許在宿主上打開新文件、創建新 socket 等。在工程實踐上倉庫還執行若干硬性約束以降低 Sentry 被利用的風險所有 unsafe 代碼隔離在文件名以unsafe.go結尾的文件中便于審計非 unsafe 文件不得導入 unsafe 包禁止使用 CGoSentry 必須是純 Go 二進制核心包內一般不允許外部導入Sentry 內部可用的代碼被嚴格管控。從 安全介紹 還可以看到更細的攻擊面分析沙箱與宿主的交互被限制為極少數高層操作與 Gofer 進程通過已連接 socket 通信、調用極少量宿主系統調用不含創建新 socket 或打開文件除非啟用了相應配置、讀寫虛擬以太網設備gVisor 不防御沙箱之前的棧高層攻擊如 containerd 被攻破后繞過 gVisor 啟動容器、Spectre 風格的 CPU 側信道攻擊、以及沙箱內部 workload 自身的漏洞例如 PHP 代碼被利用。破解 gVisor 沙箱需要同時攻破 Sentry 內核與宿主 Linux 內核而這兩者不共享任何代碼這正是雙內核架構的安全根基。安裝與版本選擇gVisor 支持 x86_64 與 ARM64要求 Linux 5.6。官方推薦通過apt倉庫安裝安裝指南sudo apt-get update \ sudo apt-get install -y apt-transport-https ca-certificates curl gnupg curl -fsSL https://gvisor.dev/archive.key | sudo gpg --dearmor -o /usr/share/keyrings/gvisor-archive-keyring.gpg echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/gvisor-archive-keyring.gpg] https://storage.googleapis.com/gvisor/releases release main | sudo tee /etc/apt/sources.list.d/gvisor.list /dev/null sudo apt-get update sudo apt-get install -y runsc如果系統已安裝 Dockerrunsc包會自動完成 Docker 運行時配置。版本渠道方面實驗用 nightly生產用 latest release也可按具體日期或 point release 選擇apt方式最面向未來是首選。從零到一把 gVisor 接入 Docker配置 Docker 運行時若使用 apt 或 automated 安裝可跳過此步sudo runsc install sudo systemctl restart docker運行沙箱化容器docker run --runtimerunsc --rm hello-world docker run --runtimerunsc --rm -it ubuntu /bin/bashDocker 的大多數選項都與 gVisor 兼容例如docker run --runtimerunsc --rm --link backend:database -v ~/bin:/tools:ro -p 8080:80 --cpus0.5 -it busybox telnet towel.blinkenlights.nl安裝帶自定義參數的運行時runsc install可以接受在 Docker 調用運行時時會傳入的 flags例如啟用調試sudo runsc install --runtime runsc-debug -- \ --debug \ --debug-log/tmp/runsc-debug.log \ --strace \ --log-packets注意啟用調試運行環境前請確保系統已禁用 SELinux?？偨Y與延伸閱讀一句話概括 gVisor 的定位它用內存安全的 Go 在用戶態重新實現了 Linux 內核接口用攔截系統調用 獨立實現內核邏輯 Gofer 中介文件訪問的方式在保持進程式資源模型的同時提供了接近虛擬機的隔離強度。runsc則把這一切封裝成標準的 OCI 運行時讓 Docker、Kubernetes 生態可以零改造接入。想要繼續深入可以閱讀倉庫中的以下文檔與源碼架構指南平臺——三種攔截機制的詳細權衡架構指南安全模型——威脅模型與縱深防御原則用戶指南兼容性——已支持/未支持系統調用清單用戶指南Docker 快速開始 與 OCI 快速開始——更多上手示例源碼入口runsc 命令分發、Platform 抽象、Gofer 文件系統、9P 協議、lisafs?！久赓M下載鏈接】gvisorApplication Kernel for Containers項目地址: https://gitcode.com/GitHub_Trending/gv/gvisor創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 gVisor 深度解析：基于 Go 的應用內核、Sentry/Gofer 架構與 runsc OCI 運行時實戰
gVisor 深度解析基于 Go 的應用內核、Sentry/Gofer 架構與 runsc OCI 運行時實戰【免費下載鏈接】gvisorApplication Kernel for Containers項目地址: https://gitcode.com/GitHub_Trending/gv/gvisor導讀gVisor 是運行在用戶態的應用內核Application Kernel它以內存安全的 Go 語言重實現了 Linux 系統調用接口為容器提供介于傳統容器與虛擬機之間的強隔離層。本文以 gVisor 官方架構文檔為主線系統講解其設計定位、與 seccomp/VM 的路線差異、Sentry 與 Gofer 雙進程架構、runscOCI 運行時的命令與使用方式并結合本倉庫源碼給出關鍵實現路徑幫助你從原理到實戰完整掌握 gVisor 的隔離機制。什么是 gVisor為容器而生的應用內核gVisor 在運行應用與宿主機操作系統之間提供了一層強隔離。它不是一個運行在虛擬機里的 Linux 內核而是一個實現 Linux 風格接口Linux-like interface的應用內核與 Linux 不同它使用內存安全的語言Go編寫并且運行在用戶態userspace——從宿主內核的視角看gVisor 本身只是一個普通的用戶進程。gVisor 附帶了一個符合 Open Container InitiativeOCI 規范的運行時名為runsc。runsc與 Docker、Kubernetes 等現有容器工具鏈無縫集成可以很方便地運行沙箱化容器。gVisor 支持三種使用路徑官方為每一種都提供了詳細指南Docker 快速開始上手最快的方式Kubernetes 快速開始在 K8s 集群中用 gVisor 隔離 PodOCI 快速開始專家模式直接使用runsc定制環境。gVisor 做什么把內核接口搬進獨立的沙箱gVisor 提供的是一個虛擬化環境用于對容器進行沙箱化。其核心思想是將通常由宿主內核實現的系統接口移入一個獨立于每個沙箱的應用內核中從而最小化容器逃逸container escape攻擊的成功面。gVisor 的關鍵權衡在于不引入大的固定開銷gVisor 不是為每個沙箱預分配固定的物理資源而是在運行時按需分配 CPU、內存等宿主機資源保留進程式的資源模型從資源利用的角度看gVisor 沙箱與普通進程類似資源可以靈活伸縮這與固定資源池的虛擬機模型有本質區別。第三條隔離路線與 seccomp 和 VM 的本質區別在 gVisor 出現之前業界對容器提供更強隔離通常走兩條路線而 gVisor 明確不屬于任何一條gVisor不是系統調用過濾器如seccomp-bpf也不是 Linux 隔離原語的包裝如firejail、AppArmor 等gVisor也不是日常意義上的虛擬機如 VirtualBox、QEMU。gVisor 走的是第三條路線在獲得虛擬機大量安全收益的同時保留普通用戶態應用的低資源占用、快速啟動和靈活性。下面逐一分析三條路線的權衡。路線一機器級虛擬化Machine-level virtualizationKVM、Xen 這類方案通過虛擬機監視器VMM向客戶機內核暴露虛擬化硬件。這種虛擬化硬件通常是啟蒙過的paravirtualized并可通過 balloon 驅動、半虛擬化自旋鎖等機制改善客戶機與宿主機之間的可見性。在獨立虛擬機中運行容器可以獲得優秀的隔離性、兼容性和性能盡管嵌套虛擬化可能帶來挑戰但通常需要額外的代理proxy和代理進程agent并可能需要更大的資源占用和更慢的啟動時間。路線二基于規則的執行Rule-based executionseccomp、SELinux、AppArmor 等方案允許為應用或容器指定細粒度的安全策略依賴宿主內核內的鉤子hooks執行規則。如果攻擊面可以收縮得足夠小這確實是在保持原生性能的同時沙箱化應用的好方法。但在實踐中為任意的、之前未知的應用可靠地定義策略極其困難甚至不可能這使得該方案難以普適應用。因此基于規則的執行通常需要與其他層次疊加形成縱深防御defense-in-depth。路線三gVisor——攔截系統調用并充當客戶機內核gVisor 提供了與上述兩者都不同的第三種隔離機制攔截應用的系統調用并扮演客戶機內核的角色無需通過虛擬化硬件做翻譯。可以這樣理解 gVisor 的定位把它看作合并的客戶機內核 VMM或者把它看作加強版的 seccompseccomp on steroids。這一架構帶來的收益與代價都非常明確收益資源占用靈活基于線程和內存映射而非固定的客戶機物理資源同時降低了虛擬化的固定成本代價應用兼容性有所降低且每次系統調用有更高的開銷per-system call overhead。在此基礎上gVisor 還會疊加基于規則的執行手段來實現縱深防御下文安全模型部分詳述。gVisor 的思路與User Mode LinuxUML類似但 UML 在內部虛擬化硬件因此資源占用是固定的而 gVisor 直接面向系統調用接口不虛擬化硬件從而保持了資源的靈活性。每種方案都有各自的適用場景例如機器級虛擬化在高密度部署上面臨挑戰而 gVisor 對系統調用密集的工作負載性能可能較差。為什么選擇 Go內存安全內核gVisor 使用 Go 編寫目的是避開長期困擾內核的安全陷阱強類型strong types內建的邊界檢查built-in bounds checks無未初始化變量無 use-after-free無棧溢出內建競態檢測器race detector。但使用 Go 也有挑戰Go 運行時常常引入性能開銷。這正是安全性與性能之間 trade-off 的直接體現也是 gVisor 文檔與 性能指南 反復強調的內容。沙箱組件全景Sentry、Gofer 與 Application一個 gVisor 沙箱由多個進程組成這些進程共同構成一個可以運行一個或多個容器的環境。每個沙箱擁有自己獨立的Sentry實例Sentry 是運行容器并攔截、響應應用系統調用的內核沙箱中的每個容器擁有自己獨立的Gofer實例Gofer 為容器提供文件系統訪問。Sentry最大的組件真正的應用內核Sentry 是 gVisor 中最大的組件可以被看作一個應用內核。它實現了應用所需的全部內核功能包括系統調用system calls信號投遞signal delivery內存管理與缺頁處理邏輯memory management and page faulting logic線程模型threading model以及其他內核功能。從本倉庫源碼結構看Sentry 的實現體量非?？捎^pkg/sentry/ 目錄下包含 800 余個 Go 源文件覆蓋了 系統調用、進程管理、文件系統、網絡棧gVisor 自研的 netstack等模塊。關鍵機制應用發起系統調用時Platform 會把調用重定向到 Sentry由 Sentry 完成必要的工作來服務該調用。需要特別強調的是Sentry不會把系統調用透傳給宿主內核作為用戶態應用Sentry 確實會發起一些宿主系統調用來支撐自身運行但絕不允許應用直接控制它發起的系統調用例如Sentry 不能直接打開文件超出沙箱范圍的文件系統操作非沙箱內部的/proc文件、pipe 等都會交給 Gofer 處理。在 pkg/sentry/platform/platform.go 中可以找到Platform接口的完整定義它提供NewAddressSpace()創建內存上下文與NewContext()創建執行上下文等抽象是所有攔截機制的公共底座。Gofer受限的文件系統代理Gofer 是一個標準的宿主進程隨每個容器啟動并通過9P 協議pkg/p9/p9.go經由 socket 或共享內存通道與 Sentry 通信。Gofer 的實現主體位于 pkg/sentry/fsimpl/gofer/其中 filesystem.go 定義了文件系統核心邏輯此外較新的 gVisor 還引入了性能更高的 lisafs 通信協議README 中有說明。安全模型的關鍵點在于Sentry 進程運行在一個受嚴格 seccomp 限制的容器中沒有文件系統資源訪問權Gofer 作為略多信任一點的伴生進程中介mediate所有對文件系統資源的訪問這為沙箱增加了一層額外的隔離即使 Sentry 被攻破也無法直接訪問宿主文件系統。Application無需修改的普通 Linux 二進制Application 就是通過 OCI runtime bundle 提供給 gVisor 的普通 Linux 二進制。gVisor 的目標是提供與 Linux 等價的環境因此應用應當可以不加修改地運行。不過 gVisor 目前并未實現每一個系統調用、每一個/proc文件或/sys文件因此可能出現部分不兼容。詳細情況見 兼容性指南倉庫中還有對應的 兼容性測試 作為佐證。runscOCI 運行時入口運行沙箱化容器的入口是runsc可執行文件。runsc實現了 OCI 運行時規范Docker 和 Kubernetes 都使用該規范。這意味著runsc可以直接運行 OCI 兼容的filesystem bundle——bundle 由兩部分組成config.json包含容器配置root filesystem容器的根文件系統。runsc實現了多個命令用于啟動、停止、列出和查詢容器狀態等操作start、stop、list、status 等。從本倉庫源碼看runsc/main.go 是二進制入口它調用maincli.Main()真正的命令分發邏輯在 runsc/cli/cli.go 中基于google/subcommands框架注冊所有子命令并統一完成日志、配置解析config.NewFromFlags、OCI spec 加載FetchSpec等初始化工作。所有子命令實現位于 runsc/cmd/ 目錄下。用 runsc 直接運行 OCI 容器按照 安裝指南 完成安裝后可以按 OCI 快速開始 的步驟操作# 1. 創建 bundle 根目錄 mkdir bundle cd bundle # 2. 用 Docker hello-world 鏡像導出 rootfs mkdir --mode0755 rootfs docker export $(docker create hello-world) | sudo tar -xf - -C rootfs --same-owner --same-permissions # 3. 生成 config.json指定運行 /hello 程序 runsc spec -- /hello # 4. 運行容器 sudo runsc run hello快速驗證runsc do 與 dmesgrunsc do是專為快速測試提供的便捷命令例如$ sudo runsc do echo Hello world Hello world注意命令前的sudo沙箱設置過程需要特權具體用于建立用戶態網絡棧一旦沙箱設置完成gVisor 會重新執行自身并丟棄所有特權之后才運行任何不可信代碼。對于不需要網絡的沙箱可以無 root 運行$ runsc --rootless --networknone do echo Hello world Hello world如何確認 gVisor 真的在工作試試會涉及宿主內核的操作例如讀取內核日志的dmesg(1)# 無 gVisor未沙箱化 $ dmesg dmesg: read kernel buffer failed: Operation not permitted # 有 gVisor沙箱化 $ runsc --rootless --networknone do dmesg [ 0.000000] Starting gVisor... [ 0.498943] Waiting for children... [ 0.972223] Committing treasure map to memory... [ 1.192981] Segmenting fault lines... [ 1.591823] Verifying that no non-zero bytes made their way into /dev/zero... [ 1.787191] Consulting tar man page... [ 2.083245] Searching for needles in stacks... [ 2.534575] Forking spaghetti code... [ 2.742140] Digging up root... [ 2.921313] Gathering forks... [ 3.342436] Creating cloned children... [ 3.511124] Setting up VFS... [ 3.812459] Setting up FUSE... [ 4.233037] Ready!這組幽默的輸出直接證明了dmesg(1)二進制在與gVisor 內核對話而非宿主 Linux 內核——這些日志是 gVisor 系統調用處理器按需生成的虛構內容因此每次運行結果都不同。需要提醒runsc do默認把宿主的整個文件系統以只讀方式暴露給沙箱這只是測試便利功能。在實際作為 OCI 容器運行時宿主文件系統映射嚴格由 OCI 配置決定gVisor 只會暴露配置指定的路徑并執行pivot_root(2)作為縱深防御禁止訪問其他宿主目錄。因此從安全角度測試時更推薦 安裝為 Docker 運行時 后使用$ sudo docker run --rm --runtimerunsc -it -v /tmp/vol:/vol ubuntu /bin/bash這條命令會在 gVisor 沙箱內啟動一個 Bash shell并把宿主目錄/tmp/vol映射到沙箱內的/vol可以嘗試探查沙箱邊界。平臺機制系統調用攔截的底層實現系統調用與缺頁的攔截依賴所謂的gVisor Platform。在 平臺指南 中Platform接口的核心可以簡化為type Platform interface { NewAddressSpace() (AddressSpace, error) NewContext() Context } type Context interface { Switch(as AddressSpace, ac arch.Context) (..., error) } type AddressSpace interface { MapFile(addr hostarch.Addr, f File, fr FileRange, at hostarch.AccessType, ...) error Unmap(addr hostarch.Addr, length uint64) }當前支持三種平臺實現各有不同的性能與硬件需求平臺攔截機制適用場景備注systrap默認基于 seccomp 的SECCOMP_RET_TRAP讓內核向觸發線程發送SIGSYS將控制權交給 gVisor虛擬機內部、無虛擬化支持的機器2023 年年中取代 ptrace 成為默認平臺KVM使用內核 KVM 功能Sentry 同時充當客戶機 OS 與 VMM裸機bare-metal場景性能最佳在嵌套 VM 中可行但因嵌套虛擬化開銷通常不如 systrapptrace使用PTRACE_SYSEMU執行用戶代碼不允許執行宿主系統調用任何 ptrace 可用的環境普適上下文切換開銷高已不再支持預計最終移除選擇建議裸機跑 KVM虛擬機內或無虛擬化支持時用 systrap。平臺對系統管理員是透明可互換的但從安全角度看它們依賴的 Linux 內核功能不同攔截行為也有差異。安全模型縱深防御與攻擊面控制gVisor 的安全設計圍繞限制系統 API 攻擊向量展開核心原則在 安全模型 中闡述不直接透傳任何系統調用給宿主每個受支持的調用都在 Sentry 中有獨立實現與宿主實現同時出現相同漏洞的可能性很低。這帶來一個推論應用使用的所有內核特性都需要在 Sentry 內實現只實現通用、普適的功能不實現也不透傳擴展屬性、raw socket、ioctl 等專用 API最小化暴露給 Sentry 的宿主面Sentry 不允許在宿主上打開新文件、創建新 socket 等。在工程實踐上倉庫還執行若干硬性約束以降低 Sentry 被利用的風險所有 unsafe 代碼隔離在文件名以unsafe.go結尾的文件中便于審計非 unsafe 文件不得導入 unsafe 包禁止使用 CGoSentry 必須是純 Go 二進制核心包內一般不允許外部導入Sentry 內部可用的代碼被嚴格管控。從 安全介紹 還可以看到更細的攻擊面分析沙箱與宿主的交互被限制為極少數高層操作與 Gofer 進程通過已連接 socket 通信、調用極少量宿主系統調用不含創建新 socket 或打開文件除非啟用了相應配置、讀寫虛擬以太網設備gVisor 不防御沙箱之前的棧高層攻擊如 containerd 被攻破后繞過 gVisor 啟動容器、Spectre 風格的 CPU 側信道攻擊、以及沙箱內部 workload 自身的漏洞例如 PHP 代碼被利用。破解 gVisor 沙箱需要同時攻破 Sentry 內核與宿主 Linux 內核而這兩者不共享任何代碼這正是雙內核架構的安全根基。安裝與版本選擇gVisor 支持 x86_64 與 ARM64要求 Linux 5.6。官方推薦通過apt倉庫安裝安裝指南sudo apt-get update \ sudo apt-get install -y apt-transport-https ca-certificates curl gnupg curl -fsSL https://gvisor.dev/archive.key | sudo gpg --dearmor -o /usr/share/keyrings/gvisor-archive-keyring.gpg echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/gvisor-archive-keyring.gpg] https://storage.googleapis.com/gvisor/releases release main | sudo tee /etc/apt/sources.list.d/gvisor.list /dev/null sudo apt-get update sudo apt-get install -y runsc如果系統已安裝 Dockerrunsc包會自動完成 Docker 運行時配置。版本渠道方面實驗用 nightly生產用 latest release也可按具體日期或 point release 選擇apt方式最面向未來是首選。從零到一把 gVisor 接入 Docker配置 Docker 運行時若使用 apt 或 automated 安裝可跳過此步sudo runsc install sudo systemctl restart docker運行沙箱化容器docker run --runtimerunsc --rm hello-world docker run --runtimerunsc --rm -it ubuntu /bin/bashDocker 的大多數選項都與 gVisor 兼容例如docker run --runtimerunsc --rm --link backend:database -v ~/bin:/tools:ro -p 8080:80 --cpus0.5 -it busybox telnet towel.blinkenlights.nl安裝帶自定義參數的運行時runsc install可以接受在 Docker 調用運行時時會傳入的 flags例如啟用調試sudo runsc install --runtime runsc-debug -- \ --debug \ --debug-log/tmp/runsc-debug.log \ --strace \ --log-packets注意啟用調試運行環境前請確保系統已禁用 SELinux?？偨Y與延伸閱讀一句話概括 gVisor 的定位它用內存安全的 Go 在用戶態重新實現了 Linux 內核接口用攔截系統調用 獨立實現內核邏輯 Gofer 中介文件訪問的方式在保持進程式資源模型的同時提供了接近虛擬機的隔離強度。runsc則把這一切封裝成標準的 OCI 運行時讓 Docker、Kubernetes 生態可以零改造接入。想要繼續深入可以閱讀倉庫中的以下文檔與源碼架構指南平臺——三種攔截機制的詳細權衡架構指南安全模型——威脅模型與縱深防御原則用戶指南兼容性——已支持/未支持系統調用清單用戶指南Docker 快速開始 與 OCI 快速開始——更多上手示例源碼入口runsc 命令分發、Platform 抽象、Gofer 文件系統、9P 協議、lisafs?！久赓M下載鏈接】gvisorApplication Kernel for Containers項目地址: https://gitcode.com/GitHub_Trending/gv/gvisor創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考