I’m thinking of setting up multi user nix on a compute cluster. The advantage would be to have a shared storage where common packages are reused, this is a great advantage compared to conda where every environment duplicates storage and inodes.

However, the packages are installed as root. As such I’m a bit wary of whether a user installing something could have the system run malware as root by installing a package.

What are the safeguards in place and how do I know I can trust them?

  • balsoft@lemmy.ml
    2·
    18 hours ago

    I’d like to note that the 4 points are not separate issues, they are all requirements in order for an attacker to get access.

    I’m not too worried about hash squatting, I guess there’s no way around it, but other ways of managing packages have way worse flaws than that.

    “hash squatting” is not really an issue on its own. Unless an attacker can breach the sandbox, given the same derivation hash, the resulting derivation output would be the same regardless of which user requested the build.

    I do want my users to be able to build packages. In most cases I imagine we’ll use pre built packages, but often packages available are not optimized for certain architectures.

    Actually, Nix without the ability to build derivations would just be useless. In Nix, everything is a derivation, even if you just want to have multiple packages installed into your user profile at once, behind the scenes it’s a derivation which simply combines binaries from multiple other derivations, which will not be available in the remote cache and needs to be “built” (in the most trivial sense possible) locally.

    How does the nix sandbox work? Just so I know what I’m working with. Do you know where I can read about it?

    You can think of the Nix sandbox as a kind of lightweight container, into which Nix mounts all the dependencies needed to build the derivation (including source code and such), and then runs the builder command. On Linux it is using User Namespaces (and a few other sandboxing tools), in a similar way to what Docker does (in fact there is some work to use runc as a sandbox backend but it’s not usable yet). I don’t know if it’s described in a lot of detail anywhere, but a brief description is available in the manual.

    Does root actively run installed packages at any point? If that is the case I’d be a bit wary to use nix for this purpose.

    Once again, just random packages in Nix Store are not “installed” in any real sense. In order for any user (incl. root) to install/run something, they have to be the one explicitly doing it, e.g. via nix profile install or nix shell. That also means that if you’re not using NixOS, you can actually just not do anything as a root user and then no code from /nix/store will be executed with root privileges at all.

    To reiterate, unless your threat model involves sophisticated attackers[1], users installing packages with Nix is as secure as them just building code from source manually, or dropping binaries into their own $HOME/.local/bin. One user installing a package into their profile does not affect other users or root in any way.

    From what I can tell from your other replies, you are setting up a common build server with your coworkers. In that case I’d say it’s 100% fine, both workplaces where I’ve been doing Nix work had a server like this, there were never any issues with privilege escalation or malware spreading between users.

    1. The attackers need to have access to an unpatched 0-day Nix sandbox breach or a critical nix-daemon issue, which is very unlikely. If that makes you feel any safer, I know that Nix has been scanned for vulnerabilities by at least one frontier-class LLM with no such vulnerabilities discovered, so just a script-kiddie with access to ChatGPT won’t be able to find anything like that. ↩︎

    • ranzispa@mander.xyzOP
      1·
      11 hours ago

      Thank you, you reassured me quite a bit. I’ll have a good read of the manual.

      It is not really a build server, it’s a compute server. I’ll have users installing hundreds of different software packages, most of them using incompatible libraries and thus I was thinking of using Nix. Alternatives would be LMOD, which however requires the administrator to install very single piece of software, which… We don’t really have a dedicated system administrator and I don’t really want to go through the compilation instructions of every single piece of software we use. Alternatively everyone could compile their own software or install it through something like conda, but that eats up a lot of storage space since every library would be duplicated across users.

      • balsoft@lemmy.ml
        2·
        11 hours ago

        Well, in that case remember to force everyone to use the same Nixpkgs version (otherwise you’ll still end up with a lot of duplicated packages), and run nix-store --optimise; nix-collect-garbage -d regularly (ideally via cron or something).