Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
alexeymuranov opened this issue Sep 10, 2020 · 28 comments

Comments

@alexeymuranov
Copy link
Contributor

alexeymuranov commented Sep 10, 2020

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
    { #...
      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:

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
Copy link
Contributor

8573 commented Sep 10, 2020

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

@alexeymuranov
Copy link
Contributor Author

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

@alexeymuranov
Copy link
Contributor Author

Setting

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

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

@8573
Copy link
Contributor

8573 commented Sep 10, 2020

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

@alexeymuranov 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
@jonringer
Copy link
Contributor

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
Copy link
Contributor

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

@8573
Copy link
Contributor

8573 commented Sep 11, 2020

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
Copy link
Contributor

8573 commented Sep 11, 2020

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

(mkRenamedOptionModule [ "programs" "unity3d" "enable" ] [ "security" "chromiumSuidSandbox" "enable" ])
seems to suggest as a possibility.

@alexeymuranov
Copy link
Contributor Author

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
Copy link
Member

primeos commented Sep 11, 2020

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
Copy link
Contributor Author

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

@alexeymuranov 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
@8573
Copy link
Contributor

8573 commented Sep 11, 2020

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
Copy link

zackelan commented Oct 28, 2020

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
Copy link
Contributor Author

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

@alexeymuranov
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor

8573 commented Oct 28, 2020

@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
Copy link
Member

fabianhjr commented Nov 13, 2020

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
Copy link
Contributor Author

@fabianhjr, that option defaults to true anyway.

@8573
Copy link
Contributor

8573 commented Nov 14, 2020

@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
Copy link
Contributor

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
Copy link

stale bot commented Jun 2, 2021

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

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

leg7 commented Jun 10, 2023

This is still a problem.

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

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
Copy link
Contributor

Is there consensus on a proper, systematic solution?

cc @ryneeverett @8573

@IreneKnapp
Copy link
Contributor

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
Copy link
Contributor

8573 commented Apr 4, 2024

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests