docs: unmark asar integrity as experimental and clean docs (#48526)
* docs: unmark asar integrity as experimental and clean docs Co-authored-by: Erick Zhao <ezhao@slack-corp.com> * zzz Co-authored-by: Erick Zhao <ezhao@slack-corp.com> * zzzz Co-authored-by: Erick Zhao <ezhao@slack-corp.com> * unlink blog post Co-authored-by: Erick Zhao <ezhao@slack-corp.com> --------- Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com> Co-authored-by: Erick Zhao <ezhao@slack-corp.com>
This commit is contained in:
trop[bot]
GitHub
parent
7d446abe91
commit
483870eff3
4 changed files with 100 additions and 32 deletions
|
|
@ -5,7 +5,7 @@ slug: asar-integrity
|
|||
hide_title: false
|
||||
---
|
||||
|
||||
ASAR integrity is an experimental feature that validates the contents of your app's
|
||||
ASAR integrity is a security feature that validates the contents of your app's
|
||||
[ASAR archives](./asar-archives.md) at runtime.
|
||||
|
||||
## Version support
|
||||
|
|
@ -77,7 +77,7 @@ on package time. The process of providing this packaged hash is different for ma
|
|||
### Using Electron tooling
|
||||
|
||||
Electron Forge and Electron Packager do this setup automatically for you with no additional
|
||||
configuration. The minimum required versions for ASAR integrity are:
|
||||
configuration whenever `asar` is enabled. The minimum required versions for ASAR integrity are:
|
||||
|
||||
* `@electron/packager@18.3.1`
|
||||
* `@electron/forge@7.4.0`
|
||||
|
|
|
|||
|
|
@ -4,11 +4,24 @@
|
|||
|
||||
## What are fuses?
|
||||
|
||||
For a subset of Electron functionality it makes sense to disable certain features for an entire application. For example, 99% of apps don't make use of `ELECTRON_RUN_AS_NODE`, these applications want to be able to ship a binary that is incapable of using that feature. We also don't want Electron consumers building Electron from source as that is both a massive technical challenge and has a high cost of both time and money.
|
||||
From a security perspective, it makes sense to disable certain unused Electron features
|
||||
that are powerful but may make your app's security posture weaker. For example, any app that doesn't
|
||||
use the `ELECTRON_RUN_AS_NODE` environment variable would want to disable the feature to prevent a
|
||||
subset of "living off the land" attacks.
|
||||
|
||||
Fuses are the solution to this problem, at a high level they are "magic bits" in the Electron binary that can be flipped when packaging your Electron app to enable / disable certain features / restrictions. Because they are flipped at package time before you code sign your app the OS becomes responsible for ensuring those bits aren't flipped back via OS level code signing validation (Gatekeeper / App Locker).
|
||||
We also don't want Electron consumers forking to achieve this goal, as building from source and
|
||||
maintaining a fork is a massive technical challenge and costs a lot of time and money.
|
||||
|
||||
## Current Fuses
|
||||
Fuses are the solution to this problem. At a high level, they are "magic bits" in the Electron binary
|
||||
that can be flipped when packaging your Electron app to enable or disable certain features/restrictions.
|
||||
|
||||
Because they are flipped at package time before you code sign your app, the OS becomes responsible
|
||||
for ensuring those bits aren't flipped back via OS-level code signing validation
|
||||
(e.g. [Gatekeeper](https://support.apple.com/en-ca/guide/security/sec5599b66df/web) on macOS or
|
||||
[AppLocker](https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/applocker/applocker-overview)
|
||||
on Windows).
|
||||
|
||||
## Current fuses
|
||||
|
||||
### `runAsNode`
|
||||
|
||||
|
|
@ -16,7 +29,11 @@ Fuses are the solution to this problem, at a high level they are "magic bits" in
|
|||
|
||||
**@electron/fuses:** `FuseV1Options.RunAsNode`
|
||||
|
||||
The runAsNode fuse toggles whether the `ELECTRON_RUN_AS_NODE` environment variable is respected or not. Please note that if this fuse is disabled then `process.fork` in the main process will not function as expected as it depends on this environment variable to function. Instead, we recommend that you use [Utility Processes](../api/utility-process.md), which work for many use cases where you need a standalone Node.js process (like a Sqlite server process or similar scenarios).
|
||||
The `runAsNode` fuse toggles whether the [`ELECTRON_RUN_AS_NODE`](../api/environment-variables.md)
|
||||
environment variable is respected or not. With this fuse disabled, [`child_process.fork`](https://nodejs.org/api/child_process.html#child_processforkmodulepath-args-options) in the main process will not function
|
||||
as expected, as it depends on this environment variable to function. Instead, we recommend that you
|
||||
use [Utility Processes](../api/utility-process.md), which work for many use cases where you need a
|
||||
standalone Node.js process (e.g. a SQLite server process).
|
||||
|
||||
### `cookieEncryption`
|
||||
|
||||
|
|
@ -24,7 +41,12 @@ The runAsNode fuse toggles whether the `ELECTRON_RUN_AS_NODE` environment variab
|
|||
|
||||
**@electron/fuses:** `FuseV1Options.EnableCookieEncryption`
|
||||
|
||||
The cookieEncryption fuse toggles whether the cookie store on disk is encrypted using OS level cryptography keys. By default the sqlite database that Chromium uses to store cookies stores the values in plaintext. If you wish to ensure your apps cookies are encrypted in the same way Chrome does then you should enable this fuse. Please note it is a one-way transition, if you enable this fuse existing unencrypted cookies will be encrypted-on-write but if you then disable the fuse again your cookie store will effectively be corrupt and useless. Most apps can safely enable this fuse.
|
||||
The `cookieEncryption` fuse toggles whether the cookie store on disk is encrypted using OS level
|
||||
cryptography keys. By default, the SQLite database that Chromium uses to store cookies stores the
|
||||
values in plaintext. If you wish to ensure your app's cookies are encrypted in the same way Chrome
|
||||
does, then you should enable this fuse. Please note it is a one-way transition—if you enable this
|
||||
fuse, existing unencrypted cookies will be encrypted-on-write, but subsequently disabling the fuse
|
||||
later will make your cookie store corrupt and useless. Most apps can safely enable this fuse.
|
||||
|
||||
### `nodeOptions`
|
||||
|
||||
|
|
@ -32,7 +54,11 @@ The cookieEncryption fuse toggles whether the cookie store on disk is encrypted
|
|||
|
||||
**@electron/fuses:** `FuseV1Options.EnableNodeOptionsEnvironmentVariable`
|
||||
|
||||
The nodeOptions fuse toggles whether the [`NODE_OPTIONS`](https://nodejs.org/api/cli.html#node_optionsoptions) and [`NODE_EXTRA_CA_CERTS`](https://github.com/nodejs/node/blob/main/doc/api/cli.md#node_extra_ca_certsfile) environment variables are respected. The `NODE_OPTIONS` environment variable can be used to pass all kinds of custom options to the Node.js runtime and isn't typically used by apps in production. Most apps can safely disable this fuse.
|
||||
The `nodeOptions` fuse toggles whether the [`NODE_OPTIONS`](https://nodejs.org/api/cli.html#node_optionsoptions)
|
||||
and [`NODE_EXTRA_CA_CERTS`](https://github.com/nodejs/node/blob/main/doc/api/cli.md#node_extra_ca_certsfile)
|
||||
environment variables are respected. The `NODE_OPTIONS` environment variable can be used to pass all
|
||||
kinds of custom options to the Node.js runtime and isn't typically used by apps in production.
|
||||
Most apps can safely disable this fuse.
|
||||
|
||||
### `nodeCliInspect`
|
||||
|
||||
|
|
@ -40,7 +66,9 @@ The nodeOptions fuse toggles whether the [`NODE_OPTIONS`](https://nodejs.org/api
|
|||
|
||||
**@electron/fuses:** `FuseV1Options.EnableNodeCliInspectArguments`
|
||||
|
||||
The nodeCliInspect fuse toggles whether the `--inspect`, `--inspect-brk`, etc. flags are respected or not. When disabled it also ensures that `SIGUSR1` signal does not initialize the main process inspector. Most apps can safely disable this fuse.
|
||||
The `nodeCliInspect` fuse toggles whether the `--inspect`, `--inspect-brk`, etc. flags are respected
|
||||
or not. When disabled, it also ensures that `SIGUSR1` signal does not initialize the main process
|
||||
inspector. Most apps can safely disable this fuse.
|
||||
|
||||
### `embeddedAsarIntegrityValidation`
|
||||
|
||||
|
|
@ -48,9 +76,12 @@ The nodeCliInspect fuse toggles whether the `--inspect`, `--inspect-brk`, etc. f
|
|||
|
||||
**@electron/fuses:** `FuseV1Options.EnableEmbeddedAsarIntegrityValidation`
|
||||
|
||||
The embeddedAsarIntegrityValidation fuse toggles an experimental feature on macOS and Windows that validates the content of the `app.asar` file when it is loaded. This feature is designed to have a minimal performance impact but may marginally slow down file reads from inside the `app.asar` archive.
|
||||
The `embeddedAsarIntegrityValidation` fuse toggles a feature on macOS and Windows that validates the
|
||||
content of the `app.asar` file when it is loaded. This feature is designed to have a minimal
|
||||
performance impact but may marginally slow down file reads from inside the `app.asar` archive.
|
||||
Most apps can safely enable this fuse.
|
||||
|
||||
For more information on how to use asar integrity validation please read the [Asar Integrity](asar-integrity.md) documentation.
|
||||
For more information on how to use ASAR integrity validation, please read the [Asar Integrity](asar-integrity.md) documentation.
|
||||
|
||||
### `onlyLoadAppFromAsar`
|
||||
|
||||
|
|
@ -58,7 +89,15 @@ For more information on how to use asar integrity validation please read the [As
|
|||
|
||||
**@electron/fuses:** `FuseV1Options.OnlyLoadAppFromAsar`
|
||||
|
||||
The onlyLoadAppFromAsar fuse changes the search system that Electron uses to locate your app code. By default Electron will search in the following order `app.asar` -> `app` -> `default_app.asar`. When this fuse is enabled the search order becomes a single entry `app.asar` thus ensuring that when combined with the `embeddedAsarIntegrityValidation` fuse it is impossible to load non-validated code.
|
||||
The `onlyLoadAppFromAsar` fuse changes the search system that Electron uses to locate your app code.
|
||||
By default, Electron will search for this code in the following order:
|
||||
|
||||
1. `app.asar`
|
||||
1. `app`
|
||||
1. `default_app.asar`
|
||||
|
||||
When this fuse is enabled, Electron will _only_ search for `app.asar`. When combined with the [`embeddedAsarIntegrityValidation`](#embeddedasarintegrityvalidation) fuse, this fuse ensures that
|
||||
it is impossible to load non-validated code.
|
||||
|
||||
### `loadBrowserProcessSpecificV8Snapshot`
|
||||
|
||||
|
|
@ -66,11 +105,17 @@ The onlyLoadAppFromAsar fuse changes the search system that Electron uses to loc
|
|||
|
||||
**@electron/fuses:** `FuseV1Options.LoadBrowserProcessSpecificV8Snapshot`
|
||||
|
||||
The loadBrowserProcessSpecificV8Snapshot fuse changes which V8 snapshot file is used for the browser process. By default Electron's processes will all use the same V8 snapshot file. When this fuse is enabled the browser process uses the file called `browser_v8_context_snapshot.bin` for its V8 snapshot. The other processes will use the V8 snapshot file that they normally do.
|
||||
V8 snapshots can be useful to improve app startup performance. V8 lets you take snapshots of
|
||||
initialized heaps and then load them back in to avoid the cost of initializing the heap.
|
||||
|
||||
V8 snapshots can be useful to improve app startup performance. V8 lets you take snapshots of initialized heaps and then load them back in to avoid the cost of initializing the heap.
|
||||
The `loadBrowserProcessSpecificV8Snapshot` fuse changes which V8 snapshot file is used for the browser
|
||||
process. By default, Electron's processes will all use the same V8 snapshot file. When this fuse is
|
||||
enabled, the main process uses the file called `browser_v8_context_snapshot.bin` for its V8 snapshot.
|
||||
Other processes will use the V8 snapshot file that they normally do.
|
||||
|
||||
Using separate snapshots for renderer processes and the main process can improve security, especially to make sure that the renderer doesn't use a snapshot with `nodeIntegration` enabled. See [#35170](https://github.com/electron/electron/issues/35170) for details.
|
||||
Using separate snapshots for renderer processes and the main process can improve security, especially
|
||||
to make sure that the renderer doesn't use a snapshot with `nodeIntegration` enabled.
|
||||
See [electron/electron#35170](https://github.com/electron/electron/issues/35170) for details.
|
||||
|
||||
### `grantFileProtocolExtraPrivileges`
|
||||
|
||||
|
|
@ -78,19 +123,25 @@ Using separate snapshots for renderer processes and the main process can improve
|
|||
|
||||
**@electron/fuses:** `FuseV1Options.GrantFileProtocolExtraPrivileges`
|
||||
|
||||
The grantFileProtocolExtraPrivileges fuse changes whether pages loaded from the `file://` protocol are given privileges beyond what they would receive in a traditional web browser. This behavior was core to Electron apps in original versions of Electron but is no longer required as apps should be [serving local files from custom protocols](./security.md#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) now instead. If you aren't serving pages from `file://` you should disable this fuse.
|
||||
The `grantFileProtocolExtraPrivileges` fuse changes whether pages loaded from the `file://` protocol
|
||||
are given privileges beyond what they would receive in a traditional web browser. This behavior was
|
||||
core to Electron apps in original versions of Electron, but is no longer required as apps should be
|
||||
[serving local files from custom protocols](./security.md#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) now instead.
|
||||
|
||||
If you aren't serving pages from `file://`, you should disable this fuse.
|
||||
|
||||
The extra privileges granted to the `file://` protocol by this fuse are incompletely documented below:
|
||||
|
||||
* `file://` protocol pages can use `fetch` to load other assets over `file://`
|
||||
* `file://` protocol pages can use service workers
|
||||
* `file://` protocol pages have universal access granted to child frames also running on `file://` protocols regardless of sandbox settings
|
||||
* `file://` protocol pages have universal access granted to child frames also running on `file://`
|
||||
protocols regardless of sandbox settings
|
||||
|
||||
## How do I flip the fuses?
|
||||
## How do I flip fuses?
|
||||
|
||||
### The easy way
|
||||
|
||||
We've made a handy module, [`@electron/fuses`](https://npmjs.com/package/@electron/fuses), to make flipping these fuses easy. Check out the README of that module for more details on usage and potential error cases.
|
||||
[`@electron/fuses`](https://npmjs.com/package/@electron/fuses) is a JavaScript utility designed to make flipping these fuses easy. Check out the README of that module for more details on usage and potential error cases.
|
||||
|
||||
```js @ts-nocheck
|
||||
const { flipFuses, FuseVersion, FuseV1Options } = require('@electron/fuses')
|
||||
|
|
@ -106,29 +157,37 @@ flipFuses(
|
|||
)
|
||||
```
|
||||
|
||||
You can validate the fuses have been flipped or check the fuse status of an arbitrary Electron app using the fuses CLI.
|
||||
You can validate the fuses that have been flipped or check the fuse status of an arbitrary Electron
|
||||
app using the `@electron/fuses` CLI.
|
||||
|
||||
```bash
|
||||
npx @electron/fuses read --app /Applications/Foo.app
|
||||
```
|
||||
|
||||
>[!NOTE]
|
||||
> If you are using Electron Forge to distribute your application, you can flip fuses using
|
||||
> [`@electron-forge/plugin-fuses`](https://www.electronforge.io/config/plugins/fuses),
|
||||
> which comes pre-installed with all templates.
|
||||
|
||||
### The hard way
|
||||
|
||||
#### Quick Glossary
|
||||
> [!IMPORTANT]
|
||||
> Glossary:
|
||||
>
|
||||
> * **Fuse Wire**: A sequence of bytes in the Electron binary used to control the fuses
|
||||
> * **Sentinel**: A static known sequence of bytes you can use to locate the fuse wire
|
||||
> * **Fuse Schema**: The format/allowed values for the fuse wire
|
||||
|
||||
* **Fuse Wire**: A sequence of bytes in the Electron binary used to control the fuses
|
||||
* **Sentinel**: A static known sequence of bytes you can use to locate the fuse wire
|
||||
* **Fuse Schema**: The format / allowed values for the fuse wire
|
||||
Manually flipping fuses requires editing the Electron binary and modifying the fuse wire to be the
|
||||
sequence of bytes that represent the state of the fuses you want.
|
||||
|
||||
Manually flipping fuses requires editing the Electron binary and modifying the fuse wire to be the sequence of bytes that represent the state of the fuses you want.
|
||||
|
||||
Somewhere in the Electron binary there will be a sequence of bytes that look like this:
|
||||
Somewhere in the Electron binary, there will be a sequence of bytes that look like this:
|
||||
|
||||
```text
|
||||
| ...binary | sentinel_bytes | fuse_version | fuse_wire_length | fuse_wire | ...binary |
|
||||
```
|
||||
|
||||
* `sentinel_bytes` is always this exact string `dL7pKGdnNz796PbbjQWNKmHXBZaB9tsX`
|
||||
* `sentinel_bytes` is always this exact string: `dL7pKGdnNz796PbbjQWNKmHXBZaB9tsX`
|
||||
* `fuse_version` is a single byte whose unsigned integer value represents the version of the fuse schema
|
||||
* `fuse_wire_length` is a single byte whose unsigned integer value represents the number of fuses in the following fuse wire
|
||||
* `fuse_wire` is a sequence of N bytes, each byte represents a single fuse and its state.
|
||||
|
|
@ -136,6 +195,6 @@ Somewhere in the Electron binary there will be a sequence of bytes that look lik
|
|||
* "1" (0x31) indicates the fuse is enabled
|
||||
* "r" (0x72) indicates the fuse has been removed and changing the byte to either 1 or 0 will have no effect.
|
||||
|
||||
To flip a fuse you find its position in the fuse wire and change it to "0" or "1" depending on the state you'd like.
|
||||
To flip a fuse, you find its position in the fuse wire and change it to "0" or "1" depending on the state you'd like.
|
||||
|
||||
You can view the current schema [here](https://github.com/electron/electron/blob/main/build/fuses/fuses.json5).
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ either `process.env` or the `window` object.
|
|||
You should at least follow these steps to improve the security of your application:
|
||||
|
||||
1. [Only load secure content](#1-only-load-secure-content)
|
||||
2. [Disable the Node.js integration in all renderers that display remote content](#2-do-not-enable-nodejs-integration-for-remote-content)
|
||||
2. [Do not enable Node.js integration for remote content](#2-do-not-enable-nodejs-integration-for-remote-content)
|
||||
3. [Enable context isolation in all renderers](#3-enable-context-isolation)
|
||||
4. [Enable process sandboxing](#4-enable-process-sandboxing)
|
||||
5. [Use `ses.setPermissionRequestHandler()` in all sessions that load remote content](#5-handle-session-permission-requests-from-remote-content)
|
||||
|
|
@ -804,10 +804,10 @@ that your application might have the rights for.
|
|||
|
||||
#### How?
|
||||
|
||||
We've made a module, [`@electron/fuses`](https://npmjs.com/package/@electron/fuses), to make
|
||||
[`@electron/fuses`](https://npmjs.com/package/@electron/fuses) is a module we made to make
|
||||
flipping these fuses easy. Check out the README of that module for more details on usage and
|
||||
potential error cases, and refer to
|
||||
[How do I flip the fuses?](./fuses.md#how-do-i-flip-the-fuses) in our documentation.
|
||||
[How do I flip fuses?](./fuses.md#how-do-i-flip-fuses) in our documentation.
|
||||
|
||||
### 20. Do not expose Electron APIs to untrusted web content
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue