进程沙盒

Chromium 中的一项关键安全功能是进程可以在沙盒中执行。沙盒通过限制对大多数系统资源的访问来限制恶意代码可能造成的危害——沙盒进程只能自由使用 CPU 周期和内存。为了执行需要额外特权的操作，沙盒进程使用专用的通信通道将任务委托给更高级别的进程。

在 Chromium 中，沙盒应用于除主进程之外的大多数进程。这包括渲染器进程，以及实用程序进程，如音频服务、GPU 服务和网络服务。

有关更多信息，请参阅 Chromium 的沙盒设计文档。

从 Electron 20 开始，沙盒已为渲染器进程启用，无需任何进一步配置。如果您想为一个进程禁用沙盒，请参阅为单个进程禁用沙盒部分。

Electron 中的沙盒行为

Electron 中的沙盒进程的行为与 Chromium 的行为大致相同，但 Electron 有一些额外的概念需要考虑，因为它与 Node.js 接口。

渲染器进程

当 Electron 中的渲染器进程被沙盒化时，它们的行为方式与常规 Chrome 渲染器相同。沙盒化的渲染器不会初始化 Node.js 环境。

因此，当沙盒启用时，渲染器进程只能通过将这些任务委托给主进程，经由进程间通信 (IPC) 来执行特权任务（例如与文件系统交互、更改系统或生成子进程）。

注意

有关进程间通信的更多信息，请查看我们的 IPC 指南。

预加载脚本

为了允许渲染器进程与主进程通信，附加到沙盒渲染器的预加载脚本仍将具有可用的 Node.js API 的 polyfill 子集。公开了一个类似于 Node 的 require 模块的 require 函数，但只能导入 Electron 和 Node 内置模块的子集

electron (以下渲染器进程模块：contextBridge, crashReporter, ipcRenderer, nativeImage, webFrame, webUtils)
events
timers
url

node: imports 也被支持

此外，预加载脚本还将某些 Node.js 原语作为全局变量进行 polyfill

由于 require 函数是一个功能有限的 polyfill，您将无法使用 CommonJS 模块将您的预加载脚本分成多个文件。如果您需要拆分预加载代码，请使用捆绑器，例如 webpack 或 Parcel。

请注意，由于呈现给 preload 脚本的环境比沙盒渲染器的环境特权高得多，因此除非启用 contextIsolation，否则仍有可能将特权 API 泄漏到在渲染器进程中运行的不受信任的代码。

配置沙盒

对于大多数应用程序来说，沙盒是最佳选择。在某些与沙盒不兼容的用例中（例如，在渲染器中使用原生 node 模块时），可以为特定进程禁用沙盒。这会带来安全风险，特别是当非沙盒进程中存在任何不受信任的代码或内容时。

为单个进程禁用沙盒

在 Electron 中，可以使用 BrowserWindow 构造函数中的 sandbox: false 首选项在每个进程的基础上禁用渲染器沙盒。

main.js
app.whenReady().then(() => {
  const win = new BrowserWindow({
    webPreferences: {
      sandbox: false
    }
  })
  win.loadURL('https://google.com')
})

当在渲染器中启用 Node.js 集成时，沙盒也会被禁用。这可以通过带有 nodeIntegration: true 标志的 BrowserWindow 构造函数来完成。

main.js
app.whenReady().then(() => {
  const win = new BrowserWindow({
    webPreferences: {
      nodeIntegration: true
    }
  })
  win.loadURL('https://google.com')
})

全局启用沙盒

如果您想为所有渲染器强制启用沙盒，您还可以使用 app.enableSandbox API。请注意，此 API 必须在应用程序的 ready 事件之前调用。

main.js
app.enableSandbox()
app.whenReady().then(() => {
  // any sandbox:false calls are overridden since `app.enableSandbox()` was called.
  const win = new BrowserWindow()
  win.loadURL('https://google.com')
})

禁用 Chromium 的沙盒（仅用于测试）

您还可以使用 --no-sandbox CLI 标志完全禁用 Chromium 的沙盒，这将禁用所有进程（包括实用程序进程）的沙盒。我们强烈建议您仅将此标志用于测试目的，绝不在生产环境中使用。

请注意，sandbox: true 选项仍将禁用渲染器的 Node.js 环境。

关于渲染不受信任的内容的注意事项

在 Electron 中渲染不受信任的内容仍然有些未知，尽管一些应用程序正在取得成功（例如 Beaker 浏览器）。我们的目标是在沙盒内容的安全性方面尽可能接近 Chrome，但最终我们将始终落后，因为存在一些根本问题

我们没有 Chromium 拥有的专门资源或专业知识来应用于其产品的安全性。我们尽最大努力利用我们拥有的资源，继承我们可以从 Chromium 继承的一切，并快速响应安全问题，但如果没有 Chromium 能够投入的资源，Electron 无法像 Chromium 那样安全。
Chrome 中的某些安全功能（例如安全浏览和证书透明度）需要中心化机构和专用服务器，这两者都与 Electron 项目的目标背道而驰。因此，我们在 Electron 中禁用了这些功能，代价是它们原本会带来的相关安全性。
只有一个 Chromium，而有数千个基于 Electron 构建的应用程序，所有这些应用程序的行为都略有不同。考虑到这些差异可能会产生巨大的可能性空间，并使确保平台在不寻常用例中的安全性具有挑战性。
我们无法直接向用户推送安全更新，因此我们依赖应用程序供应商升级其应用程序底层的 Electron 版本，以便安全更新能够到达用户手中。

虽然我们尽最大努力将 Chromium 安全修复程序向后移植到旧版本的 Electron，但我们不保证每个修复程序都会被向后移植。保持安全的最佳机会是使用最新稳定版本的 Electron。

Electron 中的沙盒行为​

渲染器进程​

预加载脚本​

配置沙盒​

为单个进程禁用沙盒​

全局启用沙盒​

禁用 Chromium 的沙盒（仅用于测试）​

关于渲染不受信任的内容的注意事项​