These are good things and possibly make the struggle of NixOS worth it.
But the impression the community gives is very much that you can always rollback and everything is in its own sandbox, which is sort of true, but not at all true as soon as malware happens.
I've never really had a huge problem rolling back an ubuntu or arch update when something breaks, so I'm surprised at the amount of effort people are expending for just this feature with no additional security.
> But the impression the community gives is very much that you can always rollback and everything is in its own sandbox
I've never got that impression from the community, since day one I have the impression that it's rollbackable in a revision-control way instead of sandbox-like. The dependencies are actually global instead of sandboxed, Nix just makes it explicit which exact instance of which depends on which exact instance of which. That's not sandboxing at all.
Well to be honest it's actual only occurred to me that you could have that sandboxing impression after reading your comments and yeah I can understand you point.
> But the impression the community gives is very much that you can always rollback and everything is in its own sandbox, which is sort of true, but not at all true as soon as malware happens.
This is more the case with something like Hydra where you have a remote nix store and builder. Then even if you compromise a given nixos instance, they store stays isolated and intact.
So then if you are doing things right, you should be able to optionally back up any mutable data you need and then blow away the entire instance from scratch, creating a new one immediately after.
And bonus points if you can run a UEFI-over-HTTPS image on boot so that your boot image and config are always being delivered (and signed) fresh from a locked down server you control. That way if you want, on boot all nix-store content is validated with `nix store verify --all` before ever being loaded in any trusted context.
If you update ubuntu or arch and something breaks, you have to look at `dpkg.log` or `pacman.log` to see what updated, and then you might need to grab an old package from the archive and manually install it.
This intrinsically doesn't work because dependencies are globally namespaced. You can't have every version of a package installed simultaneously. In Debian, this is not remotely guaranteed. In Nix, it is.
> But the impression the community gives is very much that you can always rollback and everything is in its own sandbox, which is sort of true, but not at all true as soon as malware happens.
I can see why if you do malware research or something like that, you might hear about the rollbacks capability and get your hopes up in a certain way, but that's not really the use case.
NixOS is nice for running untrusted/suspect software in a few ways I can think of, though. (They don't exactly make NixOS a security tool, but I think maybe you could leverage them to build one.)
1. If a NixOS system is compromised, blowing it away and installing from clean media is cheap compared to on other operating systems, since you can retain more of your special configuration. Reinstalling is a bit more like a snapshot restore, at least in terms of the systemwide setup (users, running services and their configurations, and installed packages).
2. NixOS does make it really easy to spin up a clone of your running configuration in a VM instead of directly switching to that config on the local system.
3. The Nix sandbox is a pretty nice place to perform builds from big repos where packages can run arbitrary hooks at build time, like PyPI and NPM, since you can have it build in chroots with temporary build users, no network access, and maybe some other nice things.
There is also actually at least one Nix-based OS trying to achieve new things in security research out there, Spectrum: https://spectrum-os.org/
> I'm surprised at the amount of effort people are expending for just this feature with no additional security.
NixOS (and Nix more generally) doesn't have a singular feature like that driving its usage or development forward, even though rollbacks is a really nice one that will often come to mind when you ask NixOS users what they like about running NixOS.
But if I had to name contenders for the top one or two 'biggest differentiators' from other tools/paradigms that let you achieve similar effects, like other configuration management systems or copy-on-write filesystem snapshotting, I'd say it's the totalizing way that NixOS integrates those features.
Because NixOS generates the configuration of the whole system, it gets to avoid having to inspect most of the system's state, and generally handles the bits of transitioning between configurations that do require inspecting and reasoning about the state of the system quickly and pretty well. There's just a smaller surface area there.
Similarly, you're just more likely to be able to easily roll back with NixOS because those features are built into all of the normal system/package management operations, and leveraging those things is generally the path of least resistance to changing the system. You end up being able to count on them more 'by default'— you're much less likely to make an important change and have a gap without a snapshot. The garbage collection system makes clearing the unused ones data easier (imo). The general reproducibility also gives you multiple sort of layers of intervention for rolling back— even if you do collect all your past generations, your version control system becomes another reliable way of 'rolling back'. Both of those ways of going back and forth through iterations of your configuration can be further combined with similar interventions at other layers, like dotfile management via Home Manager, snapshotting filesystems for unmanaged files, selective persistence via something like Impermanence, etc. These things can add up a system where the kind of ad-hoc changes that might leak through your state management tools (snapper, etckeeper, dotfile management, etc.) become a radical departure from the way you regularly work.
Another differentiator here is maybe the generality: when you Nixify, you sometimes have to do a lot of work up front just to get things working on any deployment target, but the marginal work to go from a NixOS setup to some other kind— generating identical container images, preparing a VM for local use, running your config on macOS, partially sharing your desktop configuration with a server, letting a friend or colleague experiment with or debug your exact setup, preparing an AMI, etc.— is lower, and decreases with each further investment you make in the Nix universe. Different aspects of that inevitably end up being valuable, impressive, or delightful to different users. Taken alone, none of them might seem incomparably compelling over alternative approaches.
1. Everything you need to describe and build a project is obtained by checking it out.
2. No more, works on my machine but not yours problems.
3. No more weird library dependency conflicts.
I've run into all of these and I find them all frustrating when it happens.