-
Notifications
You must be signed in to change notification settings - Fork 16.2k
feat: Electron Fuses, package time feature toggles #24241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
602a28c
to
e7bc95c
Compare
|
||
dir_path = os.path.dirname(os.path.realpath(__file__)) | ||
|
||
SENTINEL = "dL7pKGdnNz796PbbjQWNKmHXBZaB9tsX" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
. o O ( instead of using this sentinel, could we export this as a symbol and then parse ELF/PE/mach-o to directly find the location? )
Co-authored-by: Jeremy Rose <jeremya@chromium.org>
Co-authored-by: Jeremy Rose <jeremya@chromium.org>
Release Notes Persisted
|
Hi Team, We tried to follow the instruction for installing the library "fuses" to our electron project? Thank you very much for feedback! Best regards, |
Problem Statement
Certain features or Electron are undesirable for specific deployments / environments and although they can be disabled / not-utilized at the app level certain security models take account for user-level code execution. E.g. Being able to run electron apps with
ELECTRON_RUN_AS_NODE
and just get a node binary is not-ideal. We want a way to toggle certain features in a way that both doesn't require app developers to build Electron in-house and ensures that OS level app integrity / code-signing protection (gatekeeper / app-locker) correctly prevent modification of these toggles.Solution: Electron Fuses
Utilizing a known address / section of the app binary we can create a series of "fuses" (toggles) that can be overwritten after Electron has been built into a
.app
/.exe
. These can be overwritten by writing raw data to the correct address in the binary. In order to locate this known address we use a fixed sentinel string that is guaranteed to directly prefix the fuses.The format of this string is
{sentinel}{fuse_version}{...fuses}
.This allows packaging tools to find the sentinel, and then know that the next byte is the fuse version and each sequential byte is a fuse. The
fuse_version
should be used to determine what each fuse is and how many there are. A handy tool@electron/fuses
will be built to abstract away most of this complexity for developers.Example use cases
This PR implements one use case (disabling
ELECTRON_RUN_AS_NODE
), other potential use cases which could be implemented in the future using this system.--disable-sandbox
,--remote-debugging-port
, etc.)app
,app.asar
,default_app.asar
load path search and enforce only one of those is ever searchedsandbox
,contextIsolation
, etc.)Implementation Details
Adding a new fuse is as easy as adding a new key to the
fuses.json
file, the fuse implementation is automatically generated as part of the build step so if you add a newfoo_thing_enabled
fuse a new methodelectron::fuses::IsFooThingEnabled()
will automatically exist.To Do
@electron/fuses
for controlling the fuses at the packaging phaseNotes: Implemented Electron Fuses for customizing certain Electron features at package time.