Proposal: Electron - Full Sandbox

[nkolba]

This is a placeholder for a proposal coming out of the mini-summit in Tokyo 9/17 and specifically from conversations with Chromium and Edge teams around security.

The Chromium (and others) security and sandbox models are based on a design that only allows content access to a low privileged render process that is forced to proxy through a high privileged browser process for most functionality. This means when developing a web app, the developer does not have direct access to File System, Network, etc. In Electron, this model is replaced with one where an App developer has full access to both renderer and browser processes (bowser and main in Electron terminology).

Initial Thoughts

To run with sandbox in Electron today, an application must build its own security model and extend its own API into the sandboxed process. This model is limited because:

• sandboxing eliminates the Electron APIs and access to Node
• there is no standard API for sandboxed Electron Apps
• sandboxed APIs are expensive to build and maintain
• The application developer is entirely responsible for securing their app container

The goal of restructuring the the security and sandboxing scheme in Electron should be to:

• Eliminate the need for developers to roll their own security - instead enable full security by default
• Allow developers to continue to have access to Node and standard Electron APIs - even with Sandbox
• Support a security framework where privileges can be granted securely

At a high level, the end state we are targeting would look like this:

• Renderer (Browser) process has access to a Sandboxed version of Node
  • all modules with a security handle (for example FS) are negotiated through a policy manager
  • if the application does not have permission to access the module, an error is thrown on require
• this policy management for modules (and all require calls) are handled in the Browser (Main) process
• the Browser/main process is locked down - application developers work in the main process only

Additional Impacts/Benefits of this Approach

• Works well with the concept of Electron as a framework or multi-tenant Electron - where multiple applications on the same desktop could run in a single instance of Electron (since they would not be running in the Main process)

[welcome[bot]]

👋 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.

[filipsebesta]

Has this discussion progressed in any sense?

[nkolba]

Discussion hasn't progressed. We are working towards some of these things on our side. Would be great to discuss with the wider community.

[nornagon]

We've worked towards this now with things like contextBridge, removing remote, and sandboxing by default. I don't think the idea of a "sandboxed version of node" with policy enforced by the main process is likely to be possible to implement in a safe way—rather, the app is better off exposing application-specific IPC handlers through ipcRenderer.invoke / ipcMain.handle and contextBridge. Higher-level policies on methods like these are easier to enforce correctly.

As such, I'm closing this issue.