91–100 of 192 posts
Note that NixOS and reproducible builds did not detect the xz backdoor, and in fact NixOS shipped the malicious builds of xz (though they didn't do anything because the malware didn't target NixOS): > I am a NixOS developer and I was surprised when the backdoor was revealed to see that the malicious version of xz had ended up being distributed to our users. As always theory and reality are different, and the thing th…
Earlier quoted context omitted.
> NixOS and reproducible builds did not detect the xz backdoor Nix declarativeness is quite useful to increase protection against exploits in a number of ways. Unfortunately, there is still a lot of untapped potential. My number one priority would be to implement fine-grained ephemeral containers. Guix has these already. This would make it convenient to run every single process with restricted privileges, including n…
> I think the xz backdoor did not work on NixOS because its unusual non FHS-compliant filesystem structure. Right, but this is not part of the security model, it's an incidental attribute of the OS that's there for other reasons and easily solved for if the attacker had prioritized it. The only reason why it didn't work is because the attacker didn't bother making it work on NixOS, not because he couldn't have if he'…
Earlier quoted context omitted.
The standard never has been and never will be absolute security. That’s an impossible threshold nothing would ever meet even though it’s objectively true that software today is generally more secure than software 30 years ago. The strongman claim being made is “Nix is harder and more expensive to exploit than traditional build systems”. So sure, if you find a cheap way to exploit Nix, track me down. But until then, i…
> But until then, it remains at least plausible & in practice very likely that Nix is harder to exploit than alternate systems on a technical level. Do people even read package derivations? Feels like it'd be easy to check in a derivation with an exploit.
So the argument hinges on the fact that the XZ maintainer hid malicious code in the tarballs that were not checked into Git. The author demonstrates that Nix can be configured to generate the tarballs from git that go into building the binaries. What I don't see, however, is how is this a feature that requires Nix or NixOS? Any build system out there (including the stuff that goes into RPMs and Debs) can be configure…
The article does in fact cite the reproducible-builds project, in the section on "Leveraging bitwise reproducibility". From your comment I am not convinced you understood the point of the article, which is: * the NixOS build process was unable to perform a full-source build of xz because xz is required too early in the bootstrap; * a proposed adjustment to nixpkgs to automatically detect compromises of nixpkgs depend…
If we want to focus on a thing that NixOS could have prevented, we should focus on the CrowdStrike incident. Being able to boot to yesterday's config because today's config isn't working would've mitigated most of the problems.
I feel the author is a bit tunnel visioned by what happens to happen this time. The Jiatan incident has a sample size of one, it'd be a bit short sighted to think that's the only way it could happen. You can imagine various scenarios where the defenses suggested here will not have worked. Also I (as a nix user myself) think it's unlikely NixOS would have caught it. As evidenced by the fact that it didn't. (Yeah I rea…
I don't like how this site causes my headphones to crackle...
Earlier quoted context omitted.
Or they have N other such projects in flight. The xz backdoor wasn’t that much work, just playing the long game. The person doing the xz project could easily do several other projects at the same time. A lot of issues do get undetected. E.g. the Debian OpenSSL security accident was only detected when a gazillion servers had predictable SSH keys.
Most likely yes. That doesn't really impact the funny factor for me.
> To build xz from sources, we need autoconf to generate the configure script. But autoconf has a dependency on xz!
Both directions of this seem crazy to me.
1. Why the heck should a build configuration tool like autoconf be unable to function without a compression tool like xz? That makes no sense on its face.
2. For that matter, why the heck should xz, a tool that is supposedly so fundamental, have a hard dependency on a boilerplate generator like autoconf?
At the end of the day all autoconf is doing is telling you how to invoke your compiler. You ought to have a way to do that without the tool, even if it produces a suboptimal binary. If you care about security, instead of taking a giant tarball you don't understand and the running another tool in it, shouldn't you just generate that command line somehow (even in an untrusted fashion), review it, and then use that human-verified script to bootstrap?
And if you need a (de)compressor that low on the dependency tree so that literally the entire world might one day rest on it, surely you can isolate the actual computation for bootstrapping purposes and just expose it with just the open/read/write/close syscalls as dependencies? Why do you need all the bells and whistles?