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.