I don't like how this site causes my headphones to crackle...
NixOS and reproducible builds could have detected the xz backdoor
31–40 of 192 posts
Re: NixOS and reproducible builds could have detected the xz backdoor
#32Earlier quoted context omitted.
> It’s possible to do this entirely in systemd service configuration Sure, but I think that leaves out many use cases. What if I want to e.g. start a Python shell that has access to certain directories, and nothing else, including no network access? Nix provides a good way of doing that for common use cases, as it has decent support for Firejail. But I would like something like Guix containers, which is convenient fo…
Yeah, I guess most existing Linux stuff that is actually configured (so not SELinux etc) is geared at system processes not user ones. Transparently running all user applications in properly isolated containers would be quite neat. Does Firejail handle dynamic access (eg. I may want an xz invocation to work on my private keys, but not THIS specific one where I’ve given it a completely different file?). I quite like pl…
Firejail and bwrap are setuid sandbox frontends. You can wrap e.g. a new xz invocation to let it work on your private keys.
But Nix relies on ephemeral shells and flakes, and they don't play so well with each other. The interface is clumsy. Guix, in contrast, has a pretty nice set of CLI switches for these features.
Even normal distros should prioritize some simple graphical UI for this. Running programs with minimal privileges would result in a significant enhancement of security. The kernel features for achieving this are already there.
Re: NixOS and reproducible builds could have detected the xz backdoor
#33NixOS is really irrelevant here because the xz backdoor specifically targeted RedHat and Debian. It's equally relevant to say the xz backdoor didn't affect Windows (ironically the backdoor was ultimately found by a Microsoft employee, an oft-overlooked detail).
Re: NixOS and reproducible builds could have detected the xz backdoor
#34So 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…
I see.
Re: NixOS and reproducible builds could have detected the xz backdoor
#35Note 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…
> 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…
> This would make it convenient to run every single process with restricted privileges, including no access to ~/
Please no. I understand why Flatpaks do it, but this is one of the most ridiculously annoying things about the Flatpak sandbox. You can often only drag 'n drop from ~/Downloads/, and from any other location either causes the receiving application to glitch out, fail silently, or fail with a general error. Hell, you sometimes can't even copy-paste an image from one application to another via the copy-paste buffer! Meanwhile on macOS and Windows it works perfectly.
Re: NixOS and reproducible builds could have detected the xz backdoor
#36Earlier 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…
> This would make it convenient to run every single process with restricted privileges, including no access to ~/ Please no. I understand why Flatpaks do it, but this is one of the most ridiculously annoying things about the Flatpak sandbox. You can often only drag 'n drop from ~/Downloads/, and from any other location either causes the receiving application to glitch out, fail silently, or fail with a general error.…
This is by design do you can't exfiltrate data. Nix is so advanced I feel like a caveman with my openrc Gentoo.
Re: NixOS and reproducible builds could have detected the xz backdoor
#37Earlier quoted context omitted.
The backdoor build script specifically checked for things indicating that it's being built for debian, and if not, not inserting the backdoor; so it only ever was non-reproducible in situations where reproducibility wasn't expected. Not hard to make sure a backdoor with control over the build environment doesn't raise suspicions in non-targeted places.
also wasn't the backdoor reproducible to begin with? If it had targeted every system, you'd just get reproducible backdoored binaries.
The infected version was only the tarball, which was part of the obfuscation (i.e. people may look at git commits, but who individually checks autogenerated code in tarballs of every release)
Building from the git commit the release claimed to be from would result in a different binary than building from the tarball if the environment check passed.
Re: NixOS and reproducible builds could have detected the xz backdoor
#38Earlier quoted context omitted.
Yeah, I guess most existing Linux stuff that is actually configured (so not SELinux etc) is geared at system processes not user ones. Transparently running all user applications in properly isolated containers would be quite neat. Does Firejail handle dynamic access (eg. I may want an xz invocation to work on my private keys, but not THIS specific one where I’ve given it a completely different file?). I quite like pl…
Firejail and bwrap are setuid sandbox frontends. You can wrap e.g. a new xz invocation to let it work on your private keys. But Nix relies on ephemeral shells and flakes, and they don't play so well with each other. The interface is clumsy. Guix, in contrast, has a pretty nice set of CLI switches for these features. Even normal distros should prioritize some simple graphical UI for this. Running programs with minimal…
> Firejail and bwrap are setuid sandbox frontends.
bwrap does not require SUID, it only needs it if user namespaces are disabled for unpriviledged users.
Re: NixOS and reproducible builds could have detected the xz backdoor
#39Earlier quoted context omitted.
> This would make it convenient to run every single process with restricted privileges, including no access to ~/ Please no. I understand why Flatpaks do it, but this is one of the most ridiculously annoying things about the Flatpak sandbox. You can often only drag 'n drop from ~/Downloads/, and from any other location either causes the receiving application to glitch out, fail silently, or fail with a general error.…
This is by design do you can't exfiltrate data. Nix is so advanced I feel like a caveman with my openrc Gentoo.
I mean I could also just not use computers, or the internet and that would be perfectly secure as well.
Breaking or making actively annoying expected and useful functionality isn't security (and has a long track record of leading to workarounds which compromise security).
Re: NixOS and reproducible builds could have detected the xz backdoor
#40Earlier quoted context omitted.
> This would make it convenient to run every single process with restricted privileges, including no access to ~/ Please no. I understand why Flatpaks do it, but this is one of the most ridiculously annoying things about the Flatpak sandbox. You can often only drag 'n drop from ~/Downloads/, and from any other location either causes the receiving application to glitch out, fail silently, or fail with a general error.…
This is by design do you can't exfiltrate data. Nix is so advanced I feel like a caveman with my openrc Gentoo.
> This is by design
Hopefully one day people will finally accept that this is bad design and that humans require compromises on security