Nixpkgs: After upgrading to NixOS 20.09, some applications do not start when using linuxPackages_hardened, complaining about chrome-sandbox

[alexeymuranov]

Describe the bug

After upgrading to NixOS 20.09 Alpha using linuxPackages_hardened, chromium, skypeforlinux, element-desktop, Discord, geogebra do not start and produce the message:

The SUID sandbox helper binary was found, but is not configured correctly.

For example:

$ element-desktop
[7118:0910/194017.479748:FATAL:setuid_sandbox_host.cc(158)] 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 /nix/store/vxm05gk1ri7rnfhlx9l20506aa3x7fpm-electron-9.0.2/lib/electron/chrome-sandbox is owned by root and has mode 4755.
fish: “element-desktop” terminated by signal SIGTRAP (Trace or breakpoint trap)

The problem happens when using

{ #...
  boot.kernelPackages = pkgs.linuxPackages_hardened; 
}

There is no problem when using

{ #...
  boot.kernelPackages = pkgs.linuxPackages_5_4; 
}

To Reproduce

Steps to reproduce the behavior:

1. In /etc/nixos/configuration.nix set
   nix { #... boot.kernelPackages = pkgs.linuxPackages_hardened; }
   and rebuild the system.
2. Install chromium or skypeforlinux, or element-desktop, or Discord, or geogebra into user profile with nix-env -i.
3. Try to start one of these applications from terminal.

Expected behavior

The application should start normally.

Additional context

No problem with linuxPackages_5_4 instead of linuxPackages_hardened.

Possibly related issues:

• #89599.
• electron/electron/issues/17972
• electron-userland/electron-builder/issues/3872

Notify maintainers

Metadata

$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.62-hardened, NixOS, 20.09alpha47.c411fe8ae08 (Nightingale)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.7`
 - channels(alexey): `""`
 - channels(root): `"nixos-20.09alpha47.c411fe8ae08"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[8573]

What does nixos-option security.chromiumSuidSandbox.enable say?

[alexeymuranov]

@8573 it's false. Should i set it to true? Is it new in 20.09?

[alexeymuranov]

Setting

{ # ...
  security.chromiumSuidSandbox.enable = true;
}

resolves the problem for chromium but not for any of the others.

[8573]

Is it new in 20.09?

I don't think so. I've been using it since 2017: https://github.com/8573/nixos-config/commit/3694d1b264ef9c7311bf5783d213078cca6a3511.

Setting

{ # ...
  security.chromiumSuidSandbox.enable = true;
}

resolves the problem for chromium but not for any of the others.

Yes, unfortunately it seems that each Electron application needs a new NixOS module option to make its wrapped Chromium's SUID sandbox work.

I'm afraid I'm not knowledgeable as to what might have changed that would have changed whether you would need to set this manually. I had thought that it might have been that you had security.chromiumSuidSandbox enabled but something had broken it, but nixos-option shows that's not the case.

Edit: I suggest putting a comma between "start" and "complaining" in the issue title. :-)

---

cc @jonringer as release manager

[jonringer]

Hm, I'm not entirely sure, I'm able to start the applications without issues on master (which should include behaviors from 20.09).

[jonringer]

looking at https://github.com/electron/electron/issues/23074 you may try --no-sandbox, not a great solution.

[8573]

A better solution might be to copy into one's NixOS configuration what security.chromiumSuidSandbox does (which isn't much), for each of the failing programs, although I have not tested that myself (I don't use any of these programs but Chromium).

[8573]

Apologies, I posted too quickly; I see now that that code can't immediately be adapted for Electron applications, as it only SUID-ifies the sandbox program for Chromium specifically. Presumably each of the applications has some other sandbox program that would need to be added to security.wrappers.

However, looking at the reported error message, I see it mentions /nix/store/vxm05gk1ri7rnfhlx9l20506aa3x7fpm-electron-9.0.2/lib/electron/chrome-sandbox, suggesting that Electron apps can use a single, common sandbox program, which would simplify enabling their sandbox.

Alternatively, they perhaps could use the sandbox program in the Chromium package, so that security.chromiumSuidSandbox.enable = true would enable it for Electron apps too, as https://github.com/NixOS/nixpkgs/blob/4c9b89a764a80d9f280a9197a40454f54d3728a3/nixos/modules/security/chromium-suid-sandbox.nix#L11 seems to suggest as a possibility.

[alexeymuranov]

However, looking at the reported error message, I see it mentions /nix/store/vxm05gk1ri7rnfhlx9l20506aa3x7fpm-electron-9.0.2/lib/electron/chrome-sandbox, suggesting that Electron apps can use a single, common sandbox program, which would simplify enabling their sandbox.

Different error messages refer to different chrome-sandbox:

$ geogebra
[3110:0911/080917.332908: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 /nix/store/j4njggy230cw1bbmsixxswcjdq4pn9w0-electron-6.1.12/lib/electron/chrome-sandbox is owned by root and has mode 4755.
fish: “geogebra” terminated by signal SIGTRAP (Trace or breakpoint trap)

$ skypeforlinux
[3143:0911/080940.935335: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 /nix/store/pyvv5lzy5lv3pmm916c1f0jlpq4lwg3s-skypeforlinux-8.63.0.76/share/skypeforlinux/chrome-sandbox is owned by root and has mode 4755.
fish: “skypeforlinux” terminated by signal SIGTRAP (Trace or breakpoint trap)



md5-718646b8f734478c180b6e694622f186



```console
$ Discord
[3286:0911/081401.200537: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 /nix/store/xc1mak2lk1y0g66nfrldslhhkfgxqm7k-discord-0.0.11/opt/Discord/chrome-sandbox is owned by root and has mode 4755.
fish: “Discord” terminated by signal SIGTRAP (Trace or breakpoint trap)

[primeos]

This is likely a duplicate of #89599 (basically chromiumSuidSandbox is deprecated but the normal unprivileged-user-namespace sandbox doesn't work with the Linux hardened profile by default).

[alexeymuranov]

@primeos , thanks. Indeed, everything works with linuxPackages_5_4 instead of linuxPackages_hardened.

[8573]

Oops, I overlooked that your kernel is hardened. In that case, if you prefer not to use security.wrappers, you should be able to disable the relevant access control with boot.kernel.sysctl."kernel.unprivileged_userns_clone" = 1 (cf. https://github.com/NixOS/nixpkgs/issues/89599#issuecomment-644532117) as a less drastic alternative to changing the kernel. (You also would need security.allowUserNamespaces = true if you don't have that already.)

[zackelan]

Ran into this as part of my 20.03 -> 20.09 upgrade, running the 5.4-hardened kernel. Adding the error message here so this issue will be found in search results:

Oct 27 22:06:40 xsession[10359]: [10359:10359:1027/220639.948043:FATAL:setuid_sandbox_host.cc(158)] 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 /nix/store/sqy7zcf9c64gvwpyr15r0wbiqgviv33f-chromium-86.0.4240.111-sandbox/bin/__chromium-suid-sandbox is owned by root and has mode 4755.

That workaround did get Chromium (as well as Atom, the only other Electron-based app I use) running:

boot.kernel.sysctl."kernel.unprivileged_userns_clone" = 1;

[alexeymuranov]

@zackelan thanks! Could you give some explanation of what this option does?

[alexeymuranov]

So, indeed, setting the option

{ # ...
  boot.kernel.sysctl."kernel.unprivileged_userns_clone" = 1;
}

solves the issue for me.

Is it supposed to be done this way?

[jonringer]

packages in the nix store do not have any suid permissions. That's why /run/wrappers/bin exists on NixOS, where those permissions are given outside the nix store.

[8573]

@alexeymuranov wrote—

Could you give some explanation of what this option does?

It enables unprivileged users to create _user namespaces_, which are a sandboxing feature in the Linux kernel that ironically are known for creating enough security vulnerabilities that Debian patches its kernels to disable this by default. The NixOS hardened kernel (which is this) seems to agree with Debian on this.

Chromium has two main (mutually exclusive) sandboxing methods, one based on setuid and one based on unprivileged creation of user namespaces ("unprivileged user namespaces"). Apparently the Chromium developers find the setuid sandbox to be more of a maintenance burden and would like to drop it in favor of the user namespace sandbox, but that would mean dropping support for Debian, so I think continuing to use the setuid sandbox seems likely to be supported for a long time by the standards of FOSS (https://github.com/NixOS/nixpkgs/issues/89599#issuecomment-644532117).

@alexeymuranov wrote—

Is it supposed to be done this way?

I would say the more proper NixOS thing to do is to use security.wrappers to enable the necessary setuid sandboxes to work. For Chromium this is done by security.chromiumSuidSandbox.enable = true, as previously shown, but for Electron applications such as Atom some investigation may be needed. This may be as simple as putting ${pkgs.atom}/path/about/which/the/error/message/complains into security.wrappers, or it may be not so simple. (I have no familiarity with Electron applications myself.) If someone figures out what exactly to put in security.wrappers, I'm sure a patch to add a new NixOS module for it would be appreciated.

[fabianhjr]

Hi @8573, wouldn't it be better to use the security.allowUserNamespaces option rather than boot.kernel.sysctl."kernel.unprivileged_userns_clone" = 1; ?

Edit: Nvm, has no effect on this issue.

[alexeymuranov]

@fabianhjr, that option defaults to true anyway.

[8573]

@fabianhjr wrote—

Hi @8573, wouldn't it be better to use the security.allowUserNamespaces option rather than boot.kernel.sysctl."kernel.unprivileged_userns_clone" = 1; ?

Edit: Nvm, has no effect on this issue.

If one chooses to use the unprivileged user namespace sandbox rather than security.wrappers, it is necessary to use both of the NixOS options that you cite: the first enables user namespaces in general; the second allows unprivileged users to use user namespaces.