Bottles lacks sandbox

[linsui]

Describe the bug

The bottles is built with buildFHSEnv which uses bubblewrap under the hood. However it doesn't not provide sandbox features as the Flatpak version which also uses bubblewrap. The buildFHSEnv wrapper binds all directory under / which makes the file system isolation useless.

https://github.com/NixOS/nixpkgs/blob/2aef5cd131b49b9e39135a5734fd7e64ce8d8bec/pkgs/build-support/build-fhsenv-bubblewrap/default.nix#L161-L168

In addition, I can't sandbox it with firejail since bubblewrap is used. Now I feel that the bottles package in Nixpkgs is in a predicament: it still needs to download lots of binaries from Internet on startup but lack the sandbox feature the flatpak package provides and remove the possibility to do it in another way.

I thought the buildFHSEnv and the bottles package should expose some interfaces so that the users can tweak the bubblewrap args. It would be even better if it can work with the portal. I'm not sure if it's possible, maybe another choice is building a flatpak package and run it with flatpak.

Steps To Reproduce

Steps to reproduce the behavior:

1. Install Bottles and create a bottle which can't share user directory in the settings.
2. Run a program in the bottle and find that it can access the whole user directory.

Expected behavior

It would be great if the nix package can works as the flatpak package.

Notify maintainers

@Atemu @SuperSamus

[Atemu]

buildFHSEnv provides absolutely no sandboxing guarantees. It's designed to be as transparent as possible; a compatibility layer.

Having sandboxing capabilities could be a nice extra but it's not the intended function of buildFHSEnv. In fact, NixOS itself provides very little (if any) real sandboxing capabilities to begin with.

I don't know how firejail works but the FHSEnv script does not elevate any privileges; it can only access what's already there. If some sandboxing tool was to limit i.e. the filesystem view via a userns and runs the FHSEnv inside that, the FHSEnv should only be able to access that limited view of the filesystem too, not anything more.

What happens when you try to run a FHSEnv in a firejail? Are you able to access paths you shouldn't be?

[linsui]

With

  programs.firejail = {
    enable = true;
    wrappedBinaries = {
      bottles = {
        executable = "${lib.getBin pkgs.bottles}/bin/bottles";
      };
  };

I get

Parent pid 798250, child pid 798272
Error: dumpable process
Remove read permission on fseccomp executable
Warning: cleaning all supplementary groups
Error: dumpable process
Remove read permission on fseccomp executable
Error: dumpable process
Remove read permission on fseccomp executable
Warning: cleaning all supplementary groups
Child process initialized in 242.48 ms
bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'.

So looks like I can't use bwrap in fairjail. :shrug:

[Atemu]

It seems like Firejail drops the privileges to create new userns because you can apparently escape the sandbox that way?

https://github.com/netblue30/firejail/issues/1603#issuecomment-336338268

So yeah, that makes Firejail fundamentally incompatible with FHSEnvs or any other kind of nested namespaces such as Steam.

I don't think there can be anything done about that. Implementing a new userns-based sandboxing solution is far outside the scope of Nixpkgs I think.

[linsui]

Yes, so I thought a simple workaround is expose some interfaces so that the user can override the bwrap args. It's less convenient than the protal but at least works.

A better approch may be implementing something similiar to https://github.com/nixpak/nixpak.