Firejail sandboxing broke in version 3.3.0 upon introduction of chrome-sandbox executable

[bruceleerabbit]

This is the command that successfully sandboxed EM ver. 3.1.1:

firejail --name=electronmail\
             --env=ELECTRON_MAIL_USER_DATA_DIR="$HOME"/.config/electron-mail\
             --noblacklist="$HOME"/.config/electron-mail --whitelist="$HOME"/.config/electron-mail\
             --output="$HOME"/log/em.log\
             /opt/ElectronMail/electron-mail --host-resolver-rules='MAP * ~NOTFOUND , EXCLUDE 127.0.0.1'

I jumped to version 3.5.0, and it no longer runs within firejail. It terminates immediately after launch with no output.

Is there a new directory that EM needs access to apart from "$HOME"/.config/electron-mail?

[vladimiry]

Is there a new directory that EM needs access to apart from "$HOME"/.config/electron-mail?

I don't think so.

Can you try other versions in the 3.1.1-3.5.0 range so we know more precisely with which version it stopped to work? Also set ELECTRON_ENABLE_STACK_DUMPING=true and ELECTRON_ENABLE_LOGGING=true env variables which should activate addition printing to console.

[bruceleerabbit]

This 3.5.0 output looks relevant:

FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /opt/ElectronMail/chrome-sandbox is owned by root and has mode 4755.

OTOH, it seems the file already has the recommended ownership and permissions:

$ stat /opt/ElectronMail/chrome-sandbox
  File: /opt/ElectronMail/chrome-sandbox
  Size: 5185424         Blocks: 10128      IO Block: 4096   regular file
Device: fe00h/65024d    Inode: 2492456     Links: 1
Access: (4755/-rwsr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2019-06-14 21:01:57.000000000 -0400
Modify: 2019-06-12 05:57:02.000000000 -0400
Change: 2019-06-14 21:02:24.845181089 -0400
 Birth: -

update

ver	status
3.1.1	works
3.2.0	works (BTW, /opt/ElectronMail/chrome-sandbox does not exist in this version)
3.3.0	crashes at launch
3.3.1	crashes at launch
3.4.0	untested
3.4.1	untested
3.5.0	crashes at launch

The introduction of chrome-sandbox is part of the problem.

[vladimiry]

Thanks for the thoughtful report. It started to fail for you since v3.3.0 it's when the app got updated to Electron v5 which has OS-level sandbox enabled by default. This is, in general, a well-known issue which I was playing around with since early beta versions and I did a lot in order to make the app based on Electron v5 work stable and it normally does (the firejail case is the specific one). But firejail seems to ignore the SUID bit probably due to the security concerns. This is what you can try to do in order to tackle the issue:

• Activating User Namespace running sudo sysctl kernel.unprivileged_userns_clone=1. It's a system-wide change. If the User Namespace is available the Electron-based apps are supposed to use it and only fall back to SUID Sandbox if the User Namespace is unavailable. But I'm not aware of how these things work with firejail.
• Adding --no-sandbox argument to the app. firejail already enables some isolation and so adding this argument would probably not make the app more insecure (similar to the running Snap package case).

Besides, consider using Snap package as it comes with built-in isolation features. Snap package, by the way, has --no-sandbox argument hardcoded which doesn't make the app more insecure as the app is already running in snapd sandbox.

[bruceleerabbit]

Thanks for the suggestions. The --no-sandbox switch solved the problem for me. The tip about snap package isolation is interesting but I guess I'll stick with firejail for uniformity since I already make heavy use of it.

I'll leave the issue open in case someone wants to document it.

[vladimiry]

I'll leave the issue open in case someone wants to document it.

Closing as resolved. Comments are not blocked so one will be able to pop into in the case of a need.

[bruceleerabbit]

When I said someone might want to document it, I meant not here but in the user documents; so that other users could learn of the --no-sandbox option. I don't see a man page or mention of the option in readme.md.

[vladimiry]

Referencing the issue with #146.

I don't see a man page or mention of the option in readme.md.

--no-sandbox argument is undocumented for a reason, it should not be used in normal cases. Means all the packages attached to releases are supposed to work well without a need to use that argument but only in the case of a clean environment. If one enhances the environment somehow then one imposes the burden of ensuring that the app still works well. I'm happy to assist but it doesn't mean all the hacks are going to be documented and recommended for use.