feat: security: add an option to disable the remote module

[miniak]

Description of Change

The webPreferences.sandbox option is not sufficient to prevent fully exploitation if the remote module still allows access to fs and other modules via the main process. This proposal adds a new option webPreferences.enableRemoteModule, which blocks access to the remote module on the main process side.

• On the renderer process side, it removes access to electron.remote, which allows code to check whether the app can use remote beforehand
• On the main process side, the rpc-server.js ignores all IPC messages implementing the remote module

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation is changed or added
• PR title follows semantic commit guidelines

Release Notes

Notes: Added webPreferences.enableRemoteModule option allowing to disable the remote module to increase sandbox security.

[miniak]

Other potentially dangerous IPC messages are ELECTRON_BROWSER_SEND_TO and ELECTRON_BROWSER_DESKTOP_CAPTURER_GET_SOURCES

[tarruda]

This is a good initiative, but if the end goal is to make it possible to securely run untrusted code in a sandboxed renderer, we need something more radical than simply disabling the remote module.

What I have considered for some time was the implementation of a secure webPreference which enhances sandbox and essentially blocks all IPC from the renderer with the exception of messages that are absolutely essential (such as ELECTRON_BROWSER_SANDBOX_LOAD, which can only be called once per webContents) or messages matching an user-specified filter (which could be a regexp). This makes it possible for Electron apps to have a set of opt-in IPC handlers which can be used by the sandboxed renderer to interact with the browser process in a secure way. Note that this essentially removes most electron APIs from the renderer, which is the ideal scenario for running untrusted code.

In addition, the preload script of secure renderers will run in a separate context (as in contextIsolation) and communicate with the main page using asynchronous messages, which is how chrome plugins communicate with code loaded from the web.

Keep in mind that this is just an idea which I had some time to think about, and introducing new APIs that say Electron apps can run untrusted code requires a lot more careful planning, as we may be pushing a false idea of security which can have bad consequences for users. What I mean is that a lot of people will see this option and immediately assume it is safe to load any web page into Electron (without trying to understand how it works), which is simply not true.

[miniak]

@tarruda are you coming to the Electron summit in Prague? It should be one of the topics to be discussed IMHO.

[tarruda]

@tarruda are you coming to the Electron summit in Prague? It should be one of the topics to be discussed IMHO.

Just booked my flight/airbnb

[MarshallOfSound]

@miniak What is the status of this?

[miniak]

@MarshallOfSound it still needs some love. Seems like remote is also used internally for some logic or something. I need to check how to handle that.

[MarshallOfSound]

@miniak This one has conflicts as well

[miniak]

@MarshallOfSound conflicts resolved + fixed internal usages of remote (either fails gracefully or re-implemented not to use remote)

[miniak]

@MarshallOfSound can you please unblock? all comments should be resolved now.

[miniak]

@MarshallOfSound can you please also merge? I cannot do that myself :(

[release-clerk]

Release Notes Persisted

Added webPreferences.enableRemoteModule option allowing to disable the remote module to increase sandbox security.

[alexeykuzmin]

I'm going to create a backport PR to the 4-0-x branch so it's ready to be merged.
But it should NOT be merged without an explicit approval since the change a new feature.
cc @ckerr

[alexeykuzmin]

/trop run backport

[trop]

The backport process for this PR has been manually initiated, here we go! :D

[trop]

We have automatically backported this PR to "4-0-x", please check out #15222