Running 1.30.1 on Cent OS 7's latest kernel still requires --no-sandbox to run. I am not sure if this is relevant or not… ☺

Setting the SUID bit on chrome-sandbox via chmod 4755 chrome-sandbox was not working for me (Debian 10). I had to enable user namespaces sandboxing (see e.g. here for reference) via sysctl kernel.unprivileged_userns_clone=1.

On Debian 11 the kernel.unprivileged_userns_clone is set to 1 by default, it seems. I tested dropping --no-sandbox from command line arguments on Debian 11 (Bullseye) and signal-desktop started without an error.

Setting the SUID bit on the helper is deprecated in Chromium, the aim is to replace it with the namespace sandbox (which is the default right now): explainer. All maintained kernel versions already support the namespace sandbox.

I think an ideal solution right now would be to have a helper that adds --no-sandbox only if /proc/sys/kernel/unprivileged_userns_clone (and its variants from other distros) reads as 0. Would this work?

I just remove it from the .desktop file whenever I do an update and Signal seems to start just fine (Ubuntu 20.04.3 LTS).

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

seems like a serious security/privacy issue, no?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Stalebot is great :)

stale-bot is the only one interested on "working" on the ticket.

IIRC, aving kernel.unprivileged_userns_clone=1 has had multiple security problems / right escalations in the past.

signal-desktop only needs the capability at start-up, but temporarily enabling capabilities for that time span also needs root and that doesnt seem like a proper workaround either.

This is a security vulnerability and it has not been addressed yet. The Electron documentation explicitly recommends against this:

You can also disable Chromium's sandbox entirely with the --no-sandbox CLI flag, which will disable the sandbox for all processes (including utility processes). We highly recommend that you only use this flag for testing purposes, and never in production.

I found out about this by chance as I was looking at running processes and I noticed the --no-sandbox flag. So not only is this the default behavior, but it is also not transparent to the user.

I find it quite concerning that a security-oriented app like Signal goes against "highly recommended" security practices and seems to give little consideration to complaints for over 5 years. Messaging apps can and do be targeted as an attack vector to break into the OS -- see Pegasus. I'm not a sandbox expert, but I'd expect sandboxing to provide at least some degree of protection against that kind of threat.

The Signal app seems to work perfectly on Ubuntu without the --no-sandbox flag. As a workaround, I just copied the .desktop file to the local folder and removed the flag:

cp /usr/share/applications/signal-desktop.desktop ~/.local/share/applications/

This automatically overrides the Signal entry in the app menu. But this is clearly not the right solution for the average user and also means that any future (potentially important) changes to the packaged-owned .desktop file are overridden too.

Hi @korg91, the next beta release of Signal Desktop (7.38) removes the --no-sandbox CLI flag and also includes a recent electron-builder update that supports Chromium's user namespaces sandbox. There is still more work to do, but we would appreciate your help testing the latest beta on Linux when it is released.

Do these upstream updates also cancel the need for mounting /tmp/ without noexec? As, in: #6897

If user namespaces are used, then no need to write executable ont the host's /tmp/.

Hi @korg91, the next beta release of Signal Desktop (7.38) removes the --no-sandbox CLI flag and also includes a recent electron-builder update that supports Chromium's user namespaces sandbox. There is still more work to do, but we would appreciate your help testing the latest beta on Linux when it is released.

Signal Desktop 7.38 is running fine here on Debian 12. Though I still see a process running with --no-zygote-sandbox. According from what I read this should not be used because it is necessary for the sandbox.
And another process is running with --service-sandbox-type=none. Ideally this should also not be used.