Enable sandbox by default

[nornagon]

In Electron 5, sandbox mode will no longer be experimental, and running with --enable-sandbox or --enable-mixed-sandbox will be the recommended way to use Electron. In Electron 6, --enable-mixed-sandbox will be on by default and the sandbox webPreferences option will be true by default.

This is still an early-stage proposal, so definitely keen to hear any feedback or concerns people might have!

[welcome]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[anaisbetts]

While I think that this tactic is appropriate for remote content, it pretty thoroughly nukes the entire Electron ecosystem. Developers will be faced with the choice of, "Use any electron- package by disabling security, or enable security and not be able to do anything". Nuking the ecosystem has been a pretty huge disaster for many OSS projects (Python 3, QT, .NET Core), and while security is one of the few Good Reasons to do so, I think that we should think Really Hard on what we can do in order to get a Secure and Usable Electron.

People do not get IPC. Full stop. Understanding IPC requires you to thoroughly understand the multiprocess model, the most confounding part of Electron, and people really don't understand how to use it effectively - even good developers will end up inadvertently making their app into an undebuggable spaghetti maze of message handoffs. Moving to a model where IPC is literally required to do anything will have a huge effect on developer productivity.

At the end of the day, the issues brought up by @bcrypt et al about Electron Security, are all around way that local-only apps can get tricked into running remote content ("Every XSS now becomes an exploit"). To that end, I think the solution here is to limit the executability of content not coming from the app bundle (i.e. file:// but restricted to the app i.e. app://). In Local-Only Mode even If you put up an img tag of an SVG from an HTTPS domain, we do not execute its attached JS.

This model might require more deviation from Chrome (and more work!), but I believe we're at a pretty significant juncture here - if we make Electron so difficult to use in the name of Security that only Experts can build something more than "a webpage in a frame", Electron ceases to be an interesting platform.

[emmkimme]

Hi,
Regarding IPC, I fully agree, we faced the same confusing situation : 3 IPCs (Electron: ipcRenderer, ipcMain + Node.js: process.send, ..,), inconsistent behaviors and apis, impacted by options like sandbox, nodeIntegration, and OS/s....
We built our own Electron IPC: electron-common-ipc.
This is not an advertisement ! (to be fair, I'm not comfortable in term of security and performance), Building and maintaining such lib cost a lot and having such feature part of Electron would be great.

[vladimiry]

I use electron-rpc-api (which is built on pubsub-to-stream-api) for communicating with the main process as well as with the webviews. The module was originally a part of the email-securely-app project, but then got moved to a standalone project. The module is opinionated and not well polished yet, but it solves my need in converting IPC / pub/sub communication to the observable RPC calls and making it in a fully type-safe way.

Would be great if Electron provides an official module with similar ideas.

[MarshallOfSound]

@vladimiry @emmkimme Sandbox being enabled and potential IPC wrappers / improvements are separate discussions, can we keep this thread on track for discussing @nornagon 's proposal

[emmkimme]

Yes, sure. Sorry for the digression.
From the beginning, for security purpose, we are using our own Electron with the sandbox mode activated by default. So I fully approve.

[Thomas101]

I would be in favour of this, although it would break backwards compatibility for apps, needing developers to either update their code or turn it off across a set of webPreferences.

Perhaps having a call that can be made before app.ready that would allow developers to toggle between the two behaviours in one line would be a good idea. For example...

app.setSecurityModel('classic') // enable-mixed-sandbox=false webPreferences.sandbox=false
app.setSecruityModel('sandboxed') // (default) enable-mixed-sandbox=true webPreferences.sandbox=true

It still gives fine grained control for specific webPreferences as developers need it, and ensures that new apps have sandboxing enabled by default. For existing apps, developers have the option of stucking with the current behaviour or mix-matching as needed

[nornagon]

A couple of thoughts I had in the last day or so:

• I think --enable-mixed-sandbox should be enabled by default, and we should remove the flag, replacing it with --force-sandbox to force all renderers to be sandboxed regardless of the sandbox webPreferences option and the existing --no-sandbox to disable sandboxing regardless of the sandbox webPreferences option.
  • Additionally, we should research the feasibility of supporting mixed-sandbox mode on Linux. I've created an issue here to discuss this: Support mixed-sandbox mode on Linux #15795
• Part of my thoughts on why we should make sandboxed mode the default is to create a forcing-function for making sandboxed mode "officially supported". Currently the API is still marked as experimental and not many developers are using it. Switching it to be the default would mean we'd be forced to pay more attention to it, but perhaps we can use some other technique to make sure it becomes and stays better-supported?

Perhaps we could somehow enable sandboxed mode by default for remote content only?

I like the idea of an app:// scheme restricted to running only local code.

[miniak]

I am working on a PR to allow apps opting into a more secure behavior. Please have a look #17902

[kewde]

I think this is a great change for people who want to run with the sandbox enabled.

Mainly because electron-builder re-uses the base electron executable and it therefore can not magically append the sandbox flags (the only options are to 1. write some kind of packer/wrapper or 2. a custom electron build with --enable-sandbox as default). There was no simple way to create a sandboxed electron app in a distributable form through the conventional packaging solutions.

[nornagon]

You can add the flag with app.enableSandbox(): https://electronjs.org/docs/api/app#appenablesandbox-experimental-macos-windows

[kewde]

Thanks, I wasn't aware of enableSandbox only of the (recently removed) enableMixedSandbox which messed up on Linux.

[adomyaty55foundry]

Very bad idea... on WSL electron 5.0 purely fails. Especially test frameworks like Cypress 3.5 is blocked on all WSL systems beacause of this sandbox proposal. Going back to older version of Electron ...

[lee-dohm]

@adomyaty55foundry Please confine your feedback to the most appropriate issue. By commenting different, but related, stuff on three different issues, it only makes it harder for us to understand the problem you're describing and makes it less likely we'll be able to help you.

And since it seems that the problem you're describing is only tangentially related to the three issues you commented on, we would appreciate it if you could open a new issue and completely fill out the template so that we can have as much information as possible to understand what is going on.

[vn971]

Note that electron-s sandbox conflicts with external sandboxing.

An external sandbox might be preferable to the user because it can be aware of local user-s preferences. For example, it might only give access to a white list of directories and forbid the rest. So for the user, two choices are

• give the main app full unconstrained access to everything, but leave the sandboxed subprocesses in a stricter jail.
• whitelist or blacklist (e.g. .ssh) the whole application, but because of the conflict, not be able to sandbox electron-s subprocesses. User-controlled sandbox might impose more restrictions than just filesystem mounting.

In the above situation, many people choose the second approach.

[reZach]

Can someone from the electron team please confirm if this feature, sandbox mode, is production ready? As noted by @nornagon, this feature will no longer be experimental in Electron 5, but yet the docs still have a header that reads reads this feature is experimental.

[nornagon]

@reZach sandbox is no longer experimental. I've made a PR to remove the wording in question: #23651

[nornagon]

Duplicate of #28466