跳转至

包管理器沙盒化演进：操作系统级隔离、代码移除与 AI 智能体供应链安全

Package Manager Sandboxing

文章背景与核心概要

长期以来，开发者在安装开源依赖包时默认赋予了其极高的系统执行权限，这使得安装脚本成为供应链投毒与恶意蠕虫攻击的重灾区。随着 AI 编码智能体 (AI Coding Agent) 的广泛普及，智能体自主拉取、安装未经人工审计的第三方包已成常态，进一步放大了这一安全风险。为此，以 Homebrew 为代表的主流包管理器正在发起一场深远的架构重塑：全面转向 Linux 内核级 Landlock 与 macOS Seatbelt 操作系统级沙盒，严格切分下载与安装阶段，甚至激进地彻底废弃任意可执行安装脚本，改由声明式签名数据驱动。这一技术演进标志着开发者生态正告别对“安装期任意代码”的盲目信任，构筑起抵御现代智能体时代软件供应链威胁的底层防御新标准。

概述

Summary

当前，主流包管理器正在经历一场重大的安全范式变革，其核心方向是转向 操作系统级沙盒 (OS-level sandboxing) 与 彻底移除可执行代码 (code removal)。在日益猖獗的供应链攻击 (如 Shai-Hulud 蠕虫病毒以及 nx 被黑事件) 威胁下，加之未经人工审查的大语言模型 (Large Language Model, LLM) 编码智能体日益普及并频繁自主安装外部依赖，开源项目维护者们正下定决心，彻底终结对软件包在安装期运行任意代码的盲目信任。

Package managers are undergoing a significant security shift toward os-level sandboxing and code removal. Driven by escalating supply chain attacks (such as the Shai-Hulud worm and the nx compromise) and the parallel rise of unreviewed LLM coding agents, maintainers are moving away from trusting arbitrary install-time code.

诸如 Homebrew 7.0、opam 以及现代 JavaScript 包管理器等工具，纷纷开始推行极其严格的“下载与安装阶段物理隔离”，依托操作系统内核级防护屏障 (例如 Linux 上的 Landlock 与 macOS 上的 Seatbelt)，并针对生命周期钩子脚本设立严格的白名单机制。与此同时，另一条技术路线也在快速兴起——用结构化的声明式签名数据替代随意执行的脚本，从而在源头上将攻击面彻底归零。

Tools like Homebrew 7.0, opam, and modern JavaScript package managers are implementing strict fetch/install phase splits, OS-level kernel boundaries (like Landlock on Linux and Seatbelt on macOS), and allowlists for lifecycle scripts. Meanwhile, a secondary strategy—replacing arbitrary executable scripts with declarative, signed data—is gaining traction to eliminate the attack surface entirely.

已发布的变革与架构演进

Shipped Changes & Evolution

Homebrew 7.0.0 推出了“更强沙盒机制” (stronger sandboxing)，将软件包安装过程严格拆分为两个阶段：支持网络访问的“下载抓取阶段” (fetch phase) 和完全离线、只读环境下的“编译安装阶段” (install phase)。在沙盒构建模式下，默认严禁读取用户的家目录；针对此前利用 LaunchServices 逃逸 cask 沙盒的漏洞，新版本通过显式禁止启动应用程序、拦截 Mach 服务调用以及限制 Unix Socket 连接进行了彻底修复。此外，以往在 Ruby formula 中允许随意编写的 post_install 代码块以及 cask 预运行脚本已被正式弃用；取而代之的是经过数字签名的声明式 *_steps 数据指令 (相关脚本执行能力的最终移除期限设定为 2027 年 12 月)。

Homebrew 7.0.0 shipped with "stronger sandboxing," splitting package installation into a network-enabled fetch phase and an offline, read-only install phase. Sandboxed builds are now blocked from reading the user's home directory by default, and a cask sandbox escape via LaunchServices was patched by denying app launching, Mach services, and Unix socket connections. Furthermore, arbitrary Ruby formula post_install blocks and cask flight blocks are deprecated in favor of declarative *_steps delivered as signed data (with a removal deadline of December 2027).

尽管 Homebrew 早在 2015 年就开始利用 sandbox-exec 来隔离 macOS 下的 formula 构建过程，但直到最近数月，这一措施才被正式提升为系统性的安全防御工程：

Homebrew has run macOS formula builds under sandbox-exec since 2015, but recent months turned this into a formal security program:

  • 6 月：Homebrew 6.0.0 引入了基于 Bubblewrap 的 Linux 构建沙盒，并要求用户对第三方软件源 (taps) 进行显式信任授权；
  • 7 月：底层实现由 Bubblewrap 切换为内核原生内置的 Landlock，这使得沙盒能够在无特权的 Docker 容器环境中直接运转；
  • 8 月：彻底移除 Bubblewrap 代码，并明确规定任何沙盒规则的调整都必须通过严格的正规安全审查。
  • June: Homebrew 6.0.0 introduced a Linux build sandbox using Bubblewrap and required explicit trust for third-party taps.
  • July: Bubblewrap was replaced by Landlock, which is built into the kernel and operates inside unprivileged Docker.
  • August: Bubblewrap was entirely removed, and sandbox rule changes now require formal security review.

注：对第三方源 (taps) 的显式信任依然是防范恶意 cask 的首道防线；沙盒机制主要用于遏制意外破坏，并为安装流程增添安全护栏。

Note: Tap trust remains the primary protection against malicious third-party casks; sandboxing merely limits accidental damage and adds installation safeguards.

AI 智能体与通用安全技术栈

Agents and the Shared Security Stack

Homebrew 探索出的这套沙盒架构，与过去一年中各大主流大语言模型 (LLM) 编程智能体厂商所采纳的防护体系不谋而合。诸如 Claude Code、Codex CLI、Cursor 和 Gemini CLI 等工具，普遍依赖 macOS 的 Seatbelt 以及 Linux 的 Landlock/seccomp 来收容与限制未经人工审查的代码。之所以必须下沉到操作系统内核级隔离，是因为频繁弹窗请求用户授权已被证明形同虚设 (Anthropic 的公开数据显示，多达 93% 的授权弹窗都会被用户不假思索地直接点击批准)。

Homebrew's sandboxing mechanisms mirror those adopted by LLM coding agent vendors over the past year. Tools like Claude Code, Codex CLI, Cursor, and Gemini CLI rely on Seatbelt (macOS) and Landlock/seccomp (Linux) to contain unreviewed code because asking users for permission prompts every time proved ineffective (Anthropic reports users approve roughly 93% of prompts).

AI 智能体面临的安全困境与包管理器的威胁模型存在着深刻的重叠，原因显而易见：智能体会自主执行依赖包的安装。近年来多起震动业界的攻击事件已经清晰地展示了恶意依赖包是如何轻而易举攻破开发者环境的：

The agent problem and package manager problem deeply overlap because agents install packages. High-profile attacks have demonstrated how malicious packages can compromise developer environments:

  • Shai-Hulud 蠕虫病毒：通过 npm 的 postinstall 安装后钩子脚本大肆扩散，并通过向 Claude Code 的本地配置文件注入恶意钩子实现长期隐蔽潜伏；
  • nx 供应链入侵事件：攻击者在依赖包中夹带恶意载荷，试图调用本地 AI 工具刺探并窃取开发者的凭据与密钥；
  • 编程助手会话劫持：攻击者通过污染会话上下文，操纵 AI 编码助手向企业内部代码仓库主动推荐含有后门的恶意依赖包。
  • The Shai-Hulud worm spread via npm postinstall scripts and persisted by injecting hooks into Claude Code's settings file.
  • The nx compromise shipped payloads attempting to leverage local AI tools to harvest credentials.
  • Attackers have hijacked coding assistant sessions to propagate poisoned package recommendations across internal repositories.

这种安全技术的相互借鉴与跨界融合在多个开源项目中随处可见，例如 Homebrew (支持 brew sandbox-exec 以及嵌套沙盒的处理机制)、pnpm (社区中一份由 AI 智能体撰写的 Issue 提议使用 Bubblewrap、Landlock 和 Seatbelt 对脚本进行安全封装) 以及 Deno 等运行时环境。

This cross-pollination is visible in projects like Homebrew (brew sandbox-exec and nested-sandbox handling), pnpm (proposing script wrapping in bubblewrap/Landlock/Seatbelt via an agent-authored issue), and Deno.

生态现状全景盘点

State of the Ecosystem

已落地的沙盒实现方案

Shipped Sandbox Implementations

  • opam (OCaml)：自 2018 年发布的 2.0 版本起便默认开启沙盒，在 Linux 上使用 Bubblewrap，在 macOS 上使用 sandbox-exec；
  • Swift Package Manager：在 macOS 的 Seatbelt 沙盒内编译和运行 Package.swift 及相关插件 (但该机制在 Linux 平台上仍为空操作，暂未实装)；
  • Nix 与 Guix：在相互隔离的 Linux 命名空间 (namespaces) 和受控环境中执行构建，其核心设计初衷主要是为了实现环境的可复现性与纯净度，而非单纯的安全防护；
  • Bazel：在 Linux 上利用命名空间沙盒执行构建动作，在 macOS 上则交由 sandbox-exec 进行管控；
  • Gentoo Portage：采用 LD_PRELOAD 垫片技术 (包含 sandbox 机制)，并结合网络、PID 与 IPC 命名空间进行立体隔离；
  • apt / pacman / Alpine：将下载任务交由独立的低权限专用用户执行，或在特定的构建与下载流水线中引入 Landlock 和 Bubblewrap 提供安全保护。
  • opam (OCaml): Sandboxed by default since version 2.0 (2018) using bubblewrap on Linux and sandbox-exec on macOS.
  • Swift Package Manager: Compiles/runs Package.swift and plugins inside a Seatbelt sandbox (though it remains a no-op on Linux).
  • Nix & Guix: Run Linux builds in isolated namespaces/environments, primarily for reproducibility and purity rather than direct security.
  • Bazel: Runs build actions in a namespace sandbox on Linux and under sandbox-exec on macOS.
  • Gentoo Portage: Uses an LD_PRELOAD shim (sandbox) alongside network, PID, and IPC namespace isolation.
  • apt / pacman / Alpine: Split download processes to dedicated users or leverage Landlock and bubblewrap for specific build/download pipelines.

白名单机制与脚本执行管控

Allowlists and Script Control

各大 JavaScript 包管理器将重点放在了“严格管控哪些代码允许被执行”，而不仅仅是把代码关进笼子里。如今，主流客户端已默认将第三方依赖的生命周期脚本拦截在白名单之外：

JavaScript package managers have heavily invested in controlling which code runs rather than just confining it. By default, major clients now block dependency lifecycle scripts behind allowlists:

  • pnpm (2025 年 1 月)
  • Bun (2023 年)
  • Yarn (2026 年 4 月)
  • npm 12 (7 月)
  • pnpm (January 2025)
  • Bun (2023)
  • Yarn (April 2026)
  • npm 12 (July)

开源生态的演进提案

Ecosystem Proposals

跨多个编程语言的包管理器 (包括 RubyGems、Spack、Cargo、Pip、Gradle 和 NuGet) 正在起草的一系列开源提案中，普遍将 Landlock、Seatbelt 与进程级隔离列为关键规范。然而，部分工具在落地时遭遇了难以逾越的工程阻碍——例如 Python 生态中的 Poetry 和 uv，便出于跨平台兼容性难题或对信任边界定义的考量，明确回绝了内置沙盒的提议。

Open proposals across package managers (RubyGems, Spack, Cargo, Pip, Gradle, NuGet) heavily specify Landlock, Seatbelt, and process separation. However, some tools face rigid hurdles—such as Python's Poetry and uv rejecting sandboxing on portability or trust-boundary grounds.

彻底移除执行权：终极沙盒之道

Removal: The Ultimate Sandbox

从软件工程的历史经验来看，比费尽心思搭建沙盒更行之有效的策略，其实是彻底剥离代码执行能力：

A historically more successful strategy than sandboxing is removing code execution entirely:

  • Go 与 Elm：从语言设计伊始就坚决不提供任何包安装钩子机制；
  • NuGet：早在 2017 年就彻底废除了对 install.ps1 脚本的支持；
  • Composer：将脚本执行权严格限制在根项目范围内，并对所有插件施加严格的准入门槛；
  • Julia：通过其引入的 Artifacts 产物机制，用基于内容寻址的声明式下载全面取代了过去的 build.jl 编译脚本；
  • Fedora 与 Arch：正在告别容易出错的软件包安装脚本小段 (scriptlets)，全面转向声明式元数据配置 (例如使用 sysusers.d 管理系统用户)。
  • Go and Elm omitted install hooks from the start.
  • NuGet deleted install.ps1 in 2017.
  • Composer restricts execution to root project scripts and gates plugins.
  • Julia replaced build.jl scripts with declarative content-addressed downloads via its Artifacts system.
  • Fedora and Arch are shifting from scriptlets to declarative metadata (e.g., sysusers.d).

核心底层原语与 CI 流水线的安全盲区

Core Primitives and the CI Blind Spot

现代包管理安全体系建立在几项关键的底层系统原语之上：

The modern security landscape relies on a few key primitives:

  1. Landlock (Linux)：无需 root 特权、内核原生支持、具备稳定应用程序二进制接口 (ABI) 版本控制，已被 pacman、mise、Homebrew 以及各大 AI 编程智能体广泛采纳；
  2. Seatbelt (macOS)：苹果公司尽管已宣布将其弃用、但至今在操作系统底层仍不可或缺的核心沙盒防护框架；
  3. Windows：系统层面缺乏直接等价的内核原生原语，不得不依赖定制受限令牌 (Restricted Tokens) 或通过 WSL2 虚拟机隔离等复杂繁琐的方案进行变通。
  1. Landlock (Linux): Unprivileged, kernel-native, ABI-versioned, and widely adopted by pacman, mise, Homebrew, and AI coding agents.
  2. Seatbelt (macOS): Apple's deprecated yet still essential sandboxing framework.
  3. Windows: Lacks a direct native equivalent, leading to complex workarounds like custom restricted tokens or WSL2 isolation.

持续集成 (CI) 环境中的盲区

The CI Blind Spot

在持续集成 (CI) 环境 (例如 GitHub Actions) 中，安全隔离往往止步于运行器 (runner) 虚拟机的物理边界。由于流水线中的每一个构建步骤与包管理器都完全共享运行器的文件系统、环境变量以及机密凭据 (Secrets)，恶意安装脚本一旦执行，便能获得当前工作流的全部权限。此外，受限于容器内非特权命名空间的权限约束，内核级沙盒在容器化 CI 任务中常常会失效崩溃——这迫使开发者只能转而依赖白名单控制，或借助 Harden-Runner 等出站网络流量监控工具进行被动防御。

In CI environments (like GitHub Actions), isolation typically ends at the runner's virtual machine boundary. Because every step and package manager shares the runner's filesystem, environment, and secrets, an install script executes with the full reach of the workflow. Kernel sandboxes can also break inside containerized CI jobs due to unprivileged namespace limitations—forcing developers to rely on allowlists or egress-monitoring tools like Harden-Runner.

待解的权责交接边界

The Remaining Open Boundary

包管理安全面临的终极挑战在于特权交接 (Hand-off)。一个运行在沙盒中的受限构建任务，若其生成的安装清单 (manifest) 或操作步骤列表随后被包管理器以完整高权限盲目执行，那么信任决策实际上只是被推迟到了“产物校验”阶段。无论是推行声明式数据模式规范、强制步骤列表数字签名，还是彻底取缔可执行脚本，如何安全有效地验证隔离阶段输出的数据内容，依然是现代包管理体系中最核心的安全分水岭。

The fundamental challenge remains the hand-off. A sandboxed build that writes an install manifest or step list which the package manager subsequently executes with full privileges simply shifts the trust decision to output validation. Whether through declarative data schemas, signed step lists, or complete script removal, securely validating the output of a confined phase remains the defining security hurdle for modern package management.