Signal 1.27.1 will not run

[danburd]

When trying to start Signal 1.27.1, it fails to load with the following error:

`
$ flatpak run org.signal.Signal

[2:0906/090612.388077: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 /app/Signal/chrome-sandbox is owned by root and has mode 4755.
`

This is on an up-to-date Fedora 30 system on an x86_64 desktop computer.

[jonboulle]

same symptom for me also on Fedora 30/x86_64. I tried fiddling with the permissions as the error suggested but still couldn't get it working so ended up downgrading to 1.26.2.

[bermeitinger-b]

There is a workaround where you could add --no-sandbox as run parameter:

flatpak run org.signal.Signal --no-sandbox

However, I'm not sure if this has any security impact or what it does. It's electron's "fault".

[binnih]

Same problem here on Fedora 30

[bermeitinger-b]

This seems to be linked to the recent Electron version. electron/electron#17972

Judging that flatpak already does sandboxing, we could disable it for the app.

[Mikaela]

In case it's of any interest, the Wire Flatpak is also using --no-sandbox flathub/com.wire.WireDesktop#21 (even if there it apparently comes from upstream).

[mrckndt]

Upstream is disabling the sandbox signalapp/Signal-Desktop@1ca0d82

[enricotagliavini]

Same problem here on Fedora 30. I tried to

chmod 4755 /var/lib/flatpak/app/org.signal.Signal/x86_64/stable/1e3511ba121e52ec204af717a7f522dc5edc821d6ee4d2c8eea63c4c9237fe1a/files/Signal/chrome-sandbox

but it didn't worked. The chrome-sandbox still fails and strace shows the clone() syscall with CLONE_NEWUSER failing

19719 readlink("/proc/self/exe", "/app/Signal/signal-desktop", 4096) = 26
19719 access("/app/Signal/chrome-sandbox", F_OK) = 0
19719 getresuid([1000], [1000], [1000]) = 0
19719 getresgid([1000], [1000], [1000]) = 0
19719 clone(child_stack=0x7fffbcdc6410, flags=CLONE_NEWUSER|SIGCHLD) = -1 EPERM (Operation not permitted)
19719 lstat("/app", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
19719 lstat("/app/Signal", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
19719 lstat("/app/Signal/signal-desktop", {st_mode=S_IFREG|0755, st_size=112456472, ...}) = 0
19719 socketpair(AF_UNIX, SOCK_SEQPACKET, 0, [11, 12]) = 0
19719 setsockopt(11, SOL_SOCKET, SO_PASSCRED, [1], 4) = 0
19719 access("/app/Signal/chrome-sandbox", F_OK) = 0
19719 stat("/app/Signal/chrome-sandbox", {st_mode=S_IFREG|S_ISUID|0755, st_size=235840, ...}) = 0
19719 access("/app/Signal/chrome-sandbox", X_OK) = 0
19719 getpid()                          = 2
19719 write(2, "[2:0907/113237.256171: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 /app/Signal/chrome-sandbox is owned by root and has mode 4755.\n", 275) = 275

I suppose this is intentional in flatpak as you already apply a sandbox and SETUID binaries are turned off by default (or you would be able to escape the sandbox I guess). It also makes sense that you cannot create a new namespace as creating a new namespace is a way of acquiring capabilities, so it needs to be forbidden. It's a bit confusing to be honest, maybe I misunderstood how it works.

Running with --no-sandbox makes it work again as expected.

The question might be: is the flatpak sandbox as good as the chrome-sandbox so the latter can be safely disabled without regrets? And also: does it even make sense to rely on the sandbox of a flatpak application where you usually assume you don't have to completely trust the app itself (and that's the reason you sandbox it in the first place)? Signal has unrestricted access to /home however, so so long for not trusting it. But that's going to stay, chrome-sandbox or not, and I don't think the chrome-sandbox helps more in protecting /home, does it?

[mrckndt]

The underlaying issue can be found here electron/electron#17972 and flatpak/flatpak#3044. While Electron/Chromium is using suid there seems to be no other solution than running with --no-sandbox.

[binnih]

Same problem with 1.27.2

[bermeitinger-b]

Yes, I'm sorry. I thought the fix from upstream would transfer into the package but it doesn't. It should now, as the call script now also includes --no-sandbox.