I’ve always heard that NixOS is not vulnerable to a lot of CVEs and exploits because of the way it is designed.
I was wondering if anyone is aware of any specific CVE in the past or any other common exploit and why NixOS is immune against it.
Would be great to explore NixOS more in the security context and might also make it easier to evangelize it.
This strikes me as a myth. Sure, NixOS doesn’t use an fhs environment by default, and the nix store is mounted read-only, so this makes certain exploits a bit more awkward to perform because a script designed for ubuntu won’t work out of the box, but that’s just making the exploit after a CVE has been abused a tad more difficult.
Ultimately most CVEs are bugs in actively running software, and NixOS doesn’t change much about how software runs besides using unusual paths for their binaries and configuration files.
There aren’t many other meaningful differences from a security perspective. If anything, since apparmor/selinux are disabled by default, there are relatively fewer package maintainers, the package update cycle takes two weeks, and things like secure boot are quite hard to achieve, NixOS is probably less secure will take more conscious effort on the user’s end to prepare for certain threat models.
So at best NixOS has a bit of “security-through-obscurity”. There’s no baked in immunity to CVEs in general I’m aware of.
17 Likes
Well said 
I’d add that NixOS community has a Security channel you can join on matrix, it’s active and full of skilled people, but unfortunately they are just understaffed. So feel free to give them a hand if you want the situation to improve.
Also, it’s easy to know exactly what you have in production using Nix/NixOS, which is helpful if you want to know if a given version is vulnerable. In addition, it’s also easy to ship a local patch to fix a CVE and rebuild your program, or recompile using a different OpenSSL version (between 1.1 or 3.0) like it has been recommended with the highly critical OpenSSL CVEs we had recently.
5 Likes
While I love that part about NixOS, it’s important to point out that this is only true when you actually use nix to deploy and build your software. Containers and other pre-built binaries of various shapes cannot be tracked by nix with sufficient resolution to know whether there are vulnerable blobs in them.
Even when only using packages from nixpkgs, there are a small number of packages that simply download precompiled things as well. There’s no good way to automate checking for CVEs in such packages. And even if such packages were forbidden, there are plenty of applications which download further unvetted code at runtime (usually proprietary, right now I’m using steam for example…).
Don’t be lulled into a false sense of security just because you’re using NixOS. It’s always important to understand the provenance of your software, even if nix really helps tracking most of it.
6 Likes
Indeed, all those things must be taken into consideration.
1 Like
I’d appreciate it if we did those comments with a clear threat model because they just push FUD on the Internet for no reason. Not all security researchers agrees on the usefulness of AppArmor/SELinux vs. the new attack surface it provides. 
Also, security is a sociotechnical problem, it is true that NixOS is more secure based on the simple fact that it’s not a prime target for usage and development of payloads for this target is bound to not be a priority for attackers, except if you are facing a customized attack towards you.
Huh? Containers built by Nix are perfectly trackable. What do you mean exactly by that?
It is possible to filter out the source type to remove binary blobs, this metadata is not perfectly complete, but it does exist in meta of many packages.
There was vulnix in the past, I don’t think it’s maintained anymore though it was transferred to nix-community.
nods But again, security research has to be discussed with a threat model in the context. If your threat model is to defend against all type of runtime behaviors of your application, you probably need to distinguish server and desktop usage.
In server usage, NixOS applies a fair amount of systemd hardening and continues to do so to all its services, not everything is perfect, of course.
In desktop usage, this is a work in progress and to the best of my knowledge, https://spectrum-os.org/ is working to provide an interesting solution.
I’d rather say:
- Define your threat model and what is acceptable to you or not as a risk
- See if NixOS thwarts them because of incidental reasons or conscious decision choices
Provenance of the software is a tiny part of the problem, no matter what the supply chain security industry wants you to believe.
5 Likes
Well, the delay in getting critical updates to the channel is unfortunate in most models.
Not having resources for attempts at downstream maintenance… OK, this is a sword sharp on all sides, we also lack resources for inventing the Debian OpenSSL «cleanup» in the key generation.
True that many packages do get updated faster than elsewhere in the end…
3 Likes
We have solutions for this, but I feel like no one pursued them because it already upgrades fast enough.
Now, we had a problem while we had 3 release channels at the same time for the “deprecated” one, e.g. 22.11.
SOS can be worked on to fix that problem.
But what I am more interested in is measuring how much time does it take in average to receive security fixes.
2 Likes
Yes, without a clear definition “security” is a very vague word. I do however think there is a place to discuss common features that NixOS effectively lacks, especially in a context where new users might feel around to see if it suits their needs.
Specifically the case in which containers are not built by nix. It’s still quite common to see people pull images from dockerhub, which yes, may be totally fine within their threat model.
It’s just quite possible that someone takes from this conversation that nix can replace all vulnerable openssl versions on their system, which in reality heavily depends on their use of it.
I think it’s worth making sure that users don’t have misconceptions about what nix actually provides, even in abscence of a specific threat model.
Given how much time I’ve spent working around that industry my internalized biases may shine through a little here 
2 Likes
That isn’t so much different for other distros and their update cycle is usually longer for normal updates but patches can arrive faster.
Secureboot with lanzaboote is quite easy compared to other distros especially when using zfs.
NixOS is probably marginally better equipped against binary execution because you cannot just run /bin/bash and the paths from other distro attacks do not just work but that’s just obscurity.
3 Likes
We are not happy yet with the polish 
though!
1 Like