kewde / electron-sandbox-boilerplate Goto Github PK

electron/electron#13028

Currently the output (in the alerts) is a bit of garbage that I created to quickly test this.
Someone should look into organizing that.

Muon is an electron fork with additional security features.

I'd have to with it more but it sounds promising to say the least.
There are two ways to go about it:

preload

• Check if it exposes chrome.ipcRenderer in the preload context, see what kind of evil we can do there.
  Perhaps has a blacklist on it already?
• If not exposed, in preload, check if we can do funky stuff with it in the unpriviliged renderer.

https://github.com/brave/muon-quick/blob/2af3358a50a5b6bf70ccb3f46997d4e75f4fc47e/main.js#L24-L26

extentensions

I've never written a chrome extension, but muon has support for it and I've been told it's the way to go.

• build one from the ground up.

Odd muon stuff is odd..

user@host:~/projects/electron/electron-sandbox/muon-preload-extended$ ps aux | grep "brave"
user     10703  5.6  6.0 1084168 90148 pts/1   Sl+  20:19   0:00 /home/user/projects/electron/brave --enable-sandbox ./electron/main.js
user     10705  0.3  2.0 309504 30368 pts/1    S+   20:19   0:00 //home/user/projects/electron/brave --type zygote --no-sandbox
user     10731  2.7  4.5 960544 67444 pts/1    Sl+  20:20   0:00 /home/user/projects/electron/brave --type zygote --no-sandbox

Currently electron-builder does not support building with sandbox mode.
This tutorial would be a bit of a shame if people ended up packing their electron apps and not enabling the sandbox support.

• electron-forge: electron/forge#411
• electron-builder: TODO
• electron-packager: Check if needs changes.

This is on linux x64. npm install into fresh clone brought electron v.1.8.2.
Clicking on a button produces error in dev-tools:

Uncaught TypeError: Cannot read property 'sendSync' of undefined
    at sendValidIpcMessage (index.html:7)
    at HTMLInputElement.onclick (index.html:22)

those lines 3-7 are

	var s = window.ipc;

	// start the rpc
	var firstTest  = s.sendSync('rpc-start', 'oneleftundefined');

s is undefined, and ipc is not seen in dev tools.

Sandbox-preload-extended uses a preload script to attach functions to window. This no longer works in the latest Electron versions (at least >= 1.8) when you have either sandbox: true or contextIsolation: true in webPreferences, which is the case here.

I saw @kewde post here about it from a few weeks ago, so it seems like this is a known issue, but I didn't see anything about it in the issue tracker here.

Besides just pointing out that the example is broken, though, I was wondering if anyone knows how we are supposed to call Electron or Node APIs at all from a renderer process when either of these options (sandbox and contextIsolation) are turned on? If the preload script does not share the same window object as the page that's loaded, it seems like there is no way to do it...

What I am trying to achieve is an Electron app that 1) loads a remotely-hosted web app, and 2) is totally locked down security-wise except for a tiny hole punched between the renderer and the Node/Electron APIs where I can have my front-end call some native functionality.

I was going through the electron issues that involve the sandbox, in an attempt to learn to more about how to properly deploy it. I came across an interesting discussion about the usage of the sandbox & webviews. electron/electron#9611

@bpasero made the following remark:

I find it very confusing that you need to run electron --enable-sandbox to enable true sandboxing but if you forget to pass this argument you can still create windows with sandbox: true and the behaviour is almost the same (though probably fundamentally different in terms of security).

This got me thinking however, is the --enable-sandbox command line argument required even when you call the BrowserWindow like this?

 win = new BrowserWindow({
    webPreferences: {
    ....
    sandbox: true,
    .....
  }
});

If it it is the case, then I'd be interested in finding out if we have to pass specific arguments to electron-builder to have electron run with the sandbox enabled in packaged applications.

Maybe @tarruda can shine some light on this?

just wanted to say thanks for putting this together. it's very useful information and immediately actionable :-)

First of all, thanks for this repo, it helped me wrap my head around preload.js scripts and such.

Now, my question. In preload-simple.js, it is written that you should always use hardcoded channels. I was wondering, are there any security issues to prefix channels instead of hardcoding (or filtering) them? For example:

function sendIPCMessage (channel, arg) {
  return ipcRenderer.sendSync(`secured-${channel}`, args);
}

With that, a malicious message cannot be sent (I suppose), since window.sendMessage('ELECTRON_BROWSER_GET_BUILTIN', 'app') will send the message on the "secured-ELECTRON_BROWSER_GET_BUILTIN channel instead.

Am I missing something? Because if that's not the case, then it would be way more flexible not to use hardcoded channels.

Thanks!

I've added an experimental feature to the preload script that will set require() = null after it's done importing.
Feedback?

What I hope it will achieve:
disallow the loading of other modules after this line..

One of the things I'd like to be able to do is test whether or not the renderer process is sandboxed.
The linux version uses two sandboxing technique, namely seccomp-bpf & user namespaces.

I will be pouring anything I can figure out about it in this issue.

Get a list syscalls of 'whoami'.

strace -c -f -S name whoami 2>&1 1>/dev/null | tail -n +3 | head -n -2 | awk '{print $(NF)}'

Can be used to build the seccomp-bpf profile (source)

Not very useful in figuring out if it's enabled, but interesting nonetheless.

This issue is to help track the status of the executable stack on electron.
electron/electron#11628