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

alexeymuranov · 2020-09-10T17:45:43Z

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:

In /etc/nixos/configuration.nix set

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

and rebuild the system.

Install chromium or skypeforlinux, or element-desktop, or Discord, or geogebra into user profile with nix-env -i.
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:

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`

The text was updated successfully, but these errors were encountered:

8573 · 2020-09-10T18:49:02Z

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

alexeymuranov · 2020-09-10T19:01:41Z

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

alexeymuranov · 2020-09-10T19:12:08Z

Setting

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

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

8573 · 2020-09-10T20:17:44Z

Is it new in 20.09?

I don't think so. I've been using it since 2017: 8573/nixos-config@3694d1b.

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 · 2020-09-10T22:31:40Z

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 · 2020-09-10T22:57:03Z

looking at electron/electron#23074 you may try --no-sandbox, not a great solution.

8573 · 2020-09-11T03:30:48Z

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 · 2020-09-11T03:42:43Z

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

nixpkgs/nixos/modules/security/chromium-suid-sandbox.nix

Line 11 in 4c9b89a

    
           (mkRenamedOptionModule [ "programs" "unity3d" "enable" ] [ "security" "chromiumSuidSandbox" "enable" ])

seems to suggest as a possibility.

alexeymuranov · 2020-09-11T06:15:11Z

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)
```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 · 2020-09-11T07:55:36Z

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 · 2020-09-11T08:34:52Z

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

8573 · 2020-09-11T20:23:06Z

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. #89599 (comment)) as a less drastic alternative to changing the kernel. (You also would need security.allowUserNamespaces = true if you don't have that already.)

zackelan · 2020-10-28T05:19:40Z

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 · 2020-10-28T10:02:35Z

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

alexeymuranov · 2020-10-28T16:17:52Z

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 · 2020-10-28T17:04:10Z

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 · 2020-10-28T18:03:17Z

@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 (#89599 (comment)).

@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 · 2020-11-13T22:10:55Z

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 · 2020-11-13T22:49:02Z

@fabianhjr, that option defaults to true anyway.

8573 · 2020-11-14T22:30:35Z

@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.

ryneeverett · 2020-12-02T20:19:55Z

I looks like all these electron apps are using binary distributions, so patching in an environmental variable so we can modify the chrome-sandbox path via wrapper wont be as simple as it is in chromium:

      # We want to be able to specify where the sandbox is via CHROME_DEVEL_SANDBOX
      substituteInPlace sandbox/linux/suid/client/setuid_sandbox_host.cc \
        --replace \
          'return sandbox_binary;' \
          'return base::FilePath(GetDevelSandboxPath());'

stale · 2021-06-02T16:06:09Z

I marked this as stale due to inactivity. → More info

leg7 · 2023-06-10T22:41:40Z

This is still a problem.

nixos-discourse · 2024-01-12T11:40:39Z

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/cannot-run-brave-and-some-electron-programs-chromium-sandbox-issue/37536/3

deepfire · 2024-02-12T19:00:17Z

Is there consensus on a proper, systematic solution?

cc @ryneeverett @8573

IreneKnapp · 2024-03-27T02:18:06Z

I hate to say it, but I'm not sure there's a proper way to solve this without moving all these Electron apps to proper source-based builds

... which, like, we should be doing anyway, there are very good security reasons to, but there are also reasons it's hard and hasn't happened yet

8573 · 2024-04-04T19:09:06Z

My solution for #89599 (which I realize I never got around to submitting to resolve that issue) might work for these Electron apps too. (I agree with IreneKnapp in preferring building the apps from source, but some might be available only pre-built, like Google Chrome.)

IreneKnapp · 2024-04-06T21:44:49Z

oh hey. thanks @8573. indeed, that does seem like it should work for any of these.

alexeymuranov added the 0.kind: bug Something is broken label Sep 10, 2020

alexeymuranov changed the title ~~After upgrading to NixOS 20.09, some applications do not start complaining about chrome-sandbox~~ After upgrading to NixOS 20.09, some applications do not start, complaining about chrome-sandbox Sep 10, 2020

alexeymuranov changed the title ~~After upgrading to NixOS 20.09, some applications do not start, complaining about chrome-sandbox~~ After upgrading to NixOS 20.09, some applications do not start when using linuxPackages_hardened, complaining about chrome-sandbox Sep 11, 2020

stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 2, 2021

joachifm mentioned this issue Jul 23, 2022

slack does not work with kernelPackages set to linuxPackages_latest_hardened #91973

Closed

stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 10, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

alexeymuranov commented Sep 10, 2020 •

edited

Loading

8573 commented Sep 10, 2020

alexeymuranov commented Sep 10, 2020

alexeymuranov commented Sep 10, 2020

8573 commented Sep 10, 2020 •

edited

Loading

jonringer commented Sep 10, 2020

jonringer commented Sep 10, 2020

8573 commented Sep 11, 2020

8573 commented Sep 11, 2020

alexeymuranov commented Sep 11, 2020

primeos commented Sep 11, 2020

alexeymuranov commented Sep 11, 2020

8573 commented Sep 11, 2020

zackelan commented Oct 28, 2020 •

edited

Loading

alexeymuranov commented Oct 28, 2020

alexeymuranov commented Oct 28, 2020

jonringer commented Oct 28, 2020

8573 commented Oct 28, 2020

fabianhjr commented Nov 13, 2020 •

edited

Loading

alexeymuranov commented Nov 13, 2020

8573 commented Nov 14, 2020

ryneeverett commented Dec 2, 2020

stale bot commented Jun 2, 2021

leg7 commented Jun 10, 2023

nixos-discourse commented Jan 12, 2024

deepfire commented Feb 12, 2024

IreneKnapp commented Mar 27, 2024

8573 commented Apr 4, 2024

IreneKnapp commented Apr 6, 2024

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

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

Comments

alexeymuranov commented Sep 10, 2020 • edited Loading

8573 commented Sep 10, 2020

alexeymuranov commented Sep 10, 2020

alexeymuranov commented Sep 10, 2020

8573 commented Sep 10, 2020 • edited Loading

jonringer commented Sep 10, 2020

jonringer commented Sep 10, 2020

8573 commented Sep 11, 2020

8573 commented Sep 11, 2020

alexeymuranov commented Sep 11, 2020

primeos commented Sep 11, 2020

alexeymuranov commented Sep 11, 2020

8573 commented Sep 11, 2020

zackelan commented Oct 28, 2020 • edited Loading

alexeymuranov commented Oct 28, 2020

alexeymuranov commented Oct 28, 2020

jonringer commented Oct 28, 2020

8573 commented Oct 28, 2020

fabianhjr commented Nov 13, 2020 • edited Loading

alexeymuranov commented Nov 13, 2020

8573 commented Nov 14, 2020

ryneeverett commented Dec 2, 2020

stale bot commented Jun 2, 2021

leg7 commented Jun 10, 2023

nixos-discourse commented Jan 12, 2024

deepfire commented Feb 12, 2024

IreneKnapp commented Mar 27, 2024

8573 commented Apr 4, 2024

IreneKnapp commented Apr 6, 2024

alexeymuranov commented Sep 10, 2020 •

edited

Loading

8573 commented Sep 10, 2020 •

edited

Loading

zackelan commented Oct 28, 2020 •

edited

Loading

fabianhjr commented Nov 13, 2020 •

edited

Loading