7 ms·

> 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.

by nextos 2y ago

> 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 no access to ~/, except those directories that are needed by the task. That would prevent e.g. a rogue pip package from stealing SSH keys. Still, I think the xz backdoor did not work on NixOS because its unusual non FHS-compliant filesystem structure.

ratorx 2y ago
You don’t even need to run in a container for this. It’s possible to do this entirely in systemd service configuration. The easiest way is just to have separate user for every service and reduce stuff running as root. You can also restrict filesystem access, network access and even syscall access (although some of this may be implemented as a container under the hood). Unfortunately, this wouldn’t help with the xz vulnerability because the SSH server is the one loading the compromised library in that case (indirectly). Since SSH itself needs to have access to the private keys, it’s not really easy to secure it against vulnerabilities in the library it loads itself. On the flip side, unless the vulnerability is in one of the important binaries/shared libraries, the amount of damage it can cause it probably quite contained with simply having good user isolation. Nix can make this analysis really simple (because of explicitly specified dependencies), so you can crack down on critical dependencies a lot more easily.
- nextos 2y ago
  > 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 for any ad hoc use case. This greatly reduces any security threat. It's a poor-man's QubesOS.
  - ratorx 2y ago
    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 pledge/unveil for this kind of thing on OpenBSD, although that’s for a different threat model.
    - nextos 2y ago
      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.
      - NekkoDroid 2y ago
        > Firejail and bwrap are setuid sandbox frontends. bwrap does not require SUID, it only needs it if user namespaces are disabled for unpriviledged users.
        sirspamalot108 2y ago
        [flagged]
    - deleted 2y ago
      [deleted]
  - XorNot 2y ago
    Literally any container runtime can do this for you. No one does it though because it's annoying as hell to upfront figure out what you want, and then be unable to increase that list later. Like if I were to try and find a not annoying way to do this, it would be to snapshot and overlay mount my filesystem at process launch time, then give a heuristic warning at process termination about what was changed. But then we're still into basically SELinux territory which because of course there's upfront things we don't want to allow read access to - i.e. SSH keys. (don't know what the lesson here is other then "for the love of god could we get a standardized secrets filesystem and/or API or something". Looking at you Hashicorp Vault and ~/.vault-token).
- sirspamalot101 2y ago
  [flagged]
- markhahn 2y ago
  sshd was compromised, and it doesn't access private keys. (well, probably the host key.)
lolinder 2y ago
> 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'd wanted to.
- sirspamalot101 2y ago
  [flagged]
- sirspamalot112 2y ago
  [dead]
immibis 2y ago
It's interesting to observe that every process is already restricted to only be able to do computation by default. Then along comes the OS with a plethora of holes in the sandbox to do various things. And then it's strange that we take those holes for granted and apply bandaid patches over them instead of not creating the holes to begin with. Why can't we ask the kernel to create a new extremely limited memory map and run some code until a certain software interrupt fires, then restore the previous context? Why should we have to start with a fully powered-up process and then close off its abilities, instead of starting with no capabilities except the in/out buffers and computation? In this model, there could be a deliberate backdoor in the computation and it still couldn't do anything besides DoS. See also https://xkcd.com/2044 https://xkcd.com/2044
- sollewitt 2y ago
  https://fuchsia.dev/fuchsia-src/get-started/learn/intro/sandboxing https://fuchsia.dev/fuchsia-src/get-started/learn/intro/sand...
jorvi 2y ago
> 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.
- genewitch 2y ago
  This is by design do you can't exfiltrate data. Nix is so advanced I feel like a caveman with my openrc Gentoo.
  - XorNot 2y ago
    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).
    - genewitch 2y ago
      Oh, i know. I was making a joke at Nix's expense, such that i fully expected to be downvoted for said joke, but i also expected some "nah-uh, that's not why;" and then a page of evangelism for NixOS, the one True™ OS.
  - jcelerier 2y ago
    > This is by design Hopefully one day people will finally accept that this is bad design and that humans require compromises on security
- charcircuit 2y ago
  >You can often only drag 'n drop from ~/Downloads/ Drag and drop could be made to always work since it's being done by a user. Request this feature from your operating system's developer.
anonfordays 2y ago
>My number one priority would be to implement fine-grained ephemeral containers. Guix has these already. Besides how large the package repos are, what other reasons would one chose Guix over NixOS?
- nextos 2y ago
  Non-standard services daemon vs systemd. Otherwise, available packages are tidy and well defined. NixPkgs, which I use and develop for, is less tidy.
sirspamalot106 2y ago
[dead]
dralley 2y ago
>Still, I think the xz backdoor did not work on NixOS because its unusual non FHS-compliant filesystem structure. It didn't work on NixOS because the build-time hooks that inserted the backdoor only activated itself when it recognized that it was being built for an RPM or Debian package.
- johnisgood 2y ago
  Which could have been adjusted, of course.
xp84 2y ago
I get the potential need for such draconian measures in perhaps, some top secret government installations or something, but gosh that sounds tiring -- a lot like MacOS lately asking me "(AppName) wants to access your Downloads folder, cancel or allow?" when I have just directed it to open a file.
- microtonal 2y ago
  Even if you only use trusted applications and they have stringent security policies avoiding supply chain compromises, RCEs are a fact of life. E.g. iMessage vulnerabilities are found all the time and there are probably a lot of vulnerabilities that are not reported because state actors hold on to them. This is the reason why iOS uses application sandboxing and on top of that Blastdoor for iMessage. Maybe Linux isn't as effected now because it is not very popular as a desktop system. But this issue will have to be addressed as/when Linux becomes more popular. Having networked clients that do image parsing, etc. (usually in C code) without any sandboxing will just lead to mass exploitation, data exfiltration, etc. The Linux desktop has to move away from the 90ies security model where the internet was relatively safe and attackers would only be after UID 0. a lot like MacOS lately asking me "(AppName) wants to access your Downloads folder, cancel or allow?" when I have just directed it to open a file. I don't think it asks that when it goes through a portal (e.g. file dialog)?
conradev 2y ago
The maintainer would just change the sandboxing constraints to weaken the software. Just like they did in the first place. You can try to make obfuscation difficult, but it’s always possible.
jstanley 2y ago
> including no access to ~/ This is such a headache with snap and flatpak though. If you're trying to do something that the package maintainer thought of in 5 minutes of testing then it's usually fine, but still inside any non-trivial application you'll often find parts that try to use extra privileges that aren't documented because they're not normally considered "privileges". Some examples of sandboxing issues: * FreeCAD doesn't have access to /usr which means when you try to make a Draft ShapeString you can't pick any fonts * FreeCAD stores the path to the shape of a milling cutter inside your project, but that path is inside /mnt/.FreeCAhjhffg or whatever so it doesn't work after you restart the program * Inkscape gcodetools has its own "idiomatic" way of saving out results which doesn't use a file dialog, and therefore can't save any gcode because it can't write to your home directory * Matrix is only allowed to access ~/Downloads/ which means you can't share any files with anyone unless you copy them into Downloads first * "Recent" in the Gimp file picker doesn't show any of my recent files, presumably because it is using its own sandboxed file dialog which doesn't have access to the actual "Recent" files * Docker can't access /tmp/.X11-unix which means you can't give docker containers access to X In all of these cases you can work around it of course (mainly by having an accurate mental model of the problem and guessing a path that the program is allowed to access), but the user experience is just made worse for no benefit. The general theme is that the user wants the sandboxed program to be able to do something that the person who assigned privileges didn't think of. So maybe if we must do sandboxing, let's make it easy for users to break programs out of the sandbox when it suits them?
- fc417fc802 2y ago
  You raise many good points. One of the primary reasons I don't use nix or guix for everything is because it seems like there's too much magic and it's often too difficult for me to figure out how to modify a detail if a toggle wasn't explicitly provided for it. Even just getting insight into the chain of events to debug things was incredibly obtuse the last time I played with nix. Like cmake on steroids. At least cmake will spit out a multi-megabyte trace file for me to pick through. (I'm convinced cmake is an elaborate conspiracy to waste developer time.) > let's make it easy for users to break programs out of the sandbox when it suits them? At least for Flatpak given the things you described this is quite straightforward via bind mounts. Although it did seem a bit goofy having an entire list of per-application bind mounts in my fstab. Maybe things have improved since I last tried going that route? > "idiomatic" ... doesn't use a file dialog, That's an Inkscape (plugin?) bug plain and simple. GUI apps should be using the appropriate xdg portals for all supported operations at this point. The only excuse (IMHO) is for missing or broken functionality. It would be like a system tray widget not working and blaming the DE instead of the program that fails to implement the decently old and widely adopted standard. > Matrix ... you can't share any files with anyone Which client is this? Anyway the xdg portal should work. Did the dev try it? Programs should never need blanket access to save or open specific user supplied paths as a one off. That's a large part of the point of sandboxing stuff in the first place.
gf000 2y ago
Such sandboxes would only work well, if the whole OS would be built around supporting them. You would essentially need Android or iOS for it to not be a pain in the ass Nonetheless, in this year and age this should be the bare minimum from a security point of view.
- fc417fc802 2y ago
  The usual answer in Android is "you can't do that". The primary difference from my perspective is that developers for those platforms design with the limitations in mind. Stuff on linux often just breaks and requires involved workarounds if it wasn't intended by the developer to be stuffed into a flatpak. (And might not even compile under nix without half a dozen monkey patches to the build system, let alone run once built.)
  - microtonal 2y ago
    I think developers of desktop application are generally open towards facilitating sandboxing though. Most applications use standard XDG folders for files, use standard toolkit file pickers, etc. I don't have hard data, but my impression is that the general tendency in Flatpaks is that they are able to do more sandboxing over time. When Flatpak was new, a lot of applications pretty much required completely opening their sandboxes, the same applications have much more limited privileges nowadays. It's a long process, but at least with desktop applications there is progress. Unfortunately, the same can't really be said about command-line tools and development tools (NPM, cargo, pip, editor plugins, etc.).
    - fc417fc802 2y ago
      I'm not even sure what it would look like for CLI tools. Probably the sanboxing tools themselves need better controls and better UX for those controls. For CLI a solution would probably look a lot like unshare or (a more user friendly version of) setcap. The user would need to reach out to the sandbox to communicate what additional things to permit during this specific session. And then inevitably someone would configure the equivalent of passwordless sudo at which point I wonder what the point of the whole thing was to begin with. Related, we need a better paradigm for CLI to differentiate between user versus programmatically generated input. A program shouldn't be able to impersonate me unless I explicitly granted it some extremely unusual privileges.
mid-kid 2y ago
> Still, I think the xz backdoor did not work on NixOS because its unusual non FHS-compliant filesystem structure. It didn't work on nixos because the build-time check included checking whether the build was being executed in a debian or fedora build environment. This was to avoid suspicious build failures on distros with weird toolchains or incompatible architectures/ABIs/library versions. (The backdoor was a precompiled .o file so rather ABI sensitive)

by nextos 2y ago

ratorx 2y ago

You don’t even need to run in a container for this. It’s possible to do this entirely in systemd service configuration. The easiest way is just to have separate user for every service and reduce stuff running as root. You can also restrict filesystem access, network access and even syscall access (although some of this may be implemented as a container under the hood). Unfortunately, this wouldn’t help with the xz vulnerability because the SSH server is the one loading the compromised library in that case (indirectly). Since SSH itself needs to have access to the private keys, it’s not really easy to secure it against vulnerabilities in the library it loads itself. On the flip side, unless the vulnerability is in one of the important binaries/shared libraries, the amount of damage it can cause it probably quite contained with simply having good user isolation. Nix can make this analysis really simple (because of explicitly specified dependencies), so you can crack down on critical dependencies a lot more easily.

nextos 2y ago
> 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 for any ad hoc use case. This greatly reduces any security threat. It's a poor-man's QubesOS.
- ratorx 2y ago
  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 pledge/unveil for this kind of thing on OpenBSD, although that’s for a different threat model.
  - nextos 2y ago
    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.
    - NekkoDroid 2y ago
      > Firejail and bwrap are setuid sandbox frontends. bwrap does not require SUID, it only needs it if user namespaces are disabled for unpriviledged users.
      - sirspamalot108 2y ago
        [flagged]
  - deleted 2y ago
    [deleted]
- XorNot 2y ago
  Literally any container runtime can do this for you. No one does it though because it's annoying as hell to upfront figure out what you want, and then be unable to increase that list later. Like if I were to try and find a not annoying way to do this, it would be to snapshot and overlay mount my filesystem at process launch time, then give a heuristic warning at process termination about what was changed. But then we're still into basically SELinux territory which because of course there's upfront things we don't want to allow read access to - i.e. SSH keys. (don't know what the lesson here is other then "for the love of god could we get a standardized secrets filesystem and/or API or something". Looking at you Hashicorp Vault and ~/.vault-token).
sirspamalot101 2y ago
[flagged]
markhahn 2y ago
sshd was compromised, and it doesn't access private keys. (well, probably the host key.)

lolinder 2y ago

> 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'd wanted to.

sirspamalot101 2y ago
[flagged]
sirspamalot112 2y ago
[dead]

immibis 2y ago

It's interesting to observe that every process is already restricted to only be able to do computation by default. Then along comes the OS with a plethora of holes in the sandbox to do various things. And then it's strange that we take those holes for granted and apply bandaid patches over them instead of not creating the holes to begin with. Why can't we ask the kernel to create a new extremely limited memory map and run some code until a certain software interrupt fires, then restore the previous context? Why should we have to start with a fully powered-up process and then close off its abilities, instead of starting with no capabilities except the in/out buffers and computation? In this model, there could be a deliberate backdoor in the computation and it still couldn't do anything besides DoS. See also https://xkcd.com/2044 https://xkcd.com/2044

sollewitt 2y ago
https://fuchsia.dev/fuchsia-src/get-started/learn/intro/sandboxing https://fuchsia.dev/fuchsia-src/get-started/learn/intro/sand...

jorvi 2y ago

> 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.

genewitch 2y ago
This is by design do you can't exfiltrate data. Nix is so advanced I feel like a caveman with my openrc Gentoo.
- XorNot 2y ago
  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).
  - genewitch 2y ago
    Oh, i know. I was making a joke at Nix's expense, such that i fully expected to be downvoted for said joke, but i also expected some "nah-uh, that's not why;" and then a page of evangelism for NixOS, the one True™ OS.
- jcelerier 2y ago
  > This is by design Hopefully one day people will finally accept that this is bad design and that humans require compromises on security
charcircuit 2y ago
>You can often only drag 'n drop from ~/Downloads/ Drag and drop could be made to always work since it's being done by a user. Request this feature from your operating system's developer.

anonfordays 2y ago

>My number one priority would be to implement fine-grained ephemeral containers. Guix has these already. Besides how large the package repos are, what other reasons would one chose Guix over NixOS?

nextos 2y ago
Non-standard services daemon vs systemd. Otherwise, available packages are tidy and well defined. NixPkgs, which I use and develop for, is less tidy.

sirspamalot106 2y ago

[dead]

dralley 2y ago

>Still, I think the xz backdoor did not work on NixOS because its unusual non FHS-compliant filesystem structure. It didn't work on NixOS because the build-time hooks that inserted the backdoor only activated itself when it recognized that it was being built for an RPM or Debian package.

johnisgood 2y ago
Which could have been adjusted, of course.

xp84 2y ago

I get the potential need for such draconian measures in perhaps, some top secret government installations or something, but gosh that sounds tiring -- a lot like MacOS lately asking me "(AppName) wants to access your Downloads folder, cancel or allow?" when I have just directed it to open a file.

microtonal 2y ago
Even if you only use trusted applications and they have stringent security policies avoiding supply chain compromises, RCEs are a fact of life. E.g. iMessage vulnerabilities are found all the time and there are probably a lot of vulnerabilities that are not reported because state actors hold on to them. This is the reason why iOS uses application sandboxing and on top of that Blastdoor for iMessage. Maybe Linux isn't as effected now because it is not very popular as a desktop system. But this issue will have to be addressed as/when Linux becomes more popular. Having networked clients that do image parsing, etc. (usually in C code) without any sandboxing will just lead to mass exploitation, data exfiltration, etc. The Linux desktop has to move away from the 90ies security model where the internet was relatively safe and attackers would only be after UID 0. a lot like MacOS lately asking me "(AppName) wants to access your Downloads folder, cancel or allow?" when I have just directed it to open a file. I don't think it asks that when it goes through a portal (e.g. file dialog)?

conradev 2y ago

The maintainer would just change the sandboxing constraints to weaken the software. Just like they did in the first place. You can try to make obfuscation difficult, but it’s always possible.

jstanley 2y ago

> including no access to ~/ This is such a headache with snap and flatpak though. If you're trying to do something that the package maintainer thought of in 5 minutes of testing then it's usually fine, but still inside any non-trivial application you'll often find parts that try to use extra privileges that aren't documented because they're not normally considered "privileges". Some examples of sandboxing issues: * FreeCAD doesn't have access to /usr which means when you try to make a Draft ShapeString you can't pick any fonts * FreeCAD stores the path to the shape of a milling cutter inside your project, but that path is inside /mnt/.FreeCAhjhffg or whatever so it doesn't work after you restart the program * Inkscape gcodetools has its own "idiomatic" way of saving out results which doesn't use a file dialog, and therefore can't save any gcode because it can't write to your home directory * Matrix is only allowed to access ~/Downloads/ which means you can't share any files with anyone unless you copy them into Downloads first * "Recent" in the Gimp file picker doesn't show any of my recent files, presumably because it is using its own sandboxed file dialog which doesn't have access to the actual "Recent" files * Docker can't access /tmp/.X11-unix which means you can't give docker containers access to X In all of these cases you can work around it of course (mainly by having an accurate mental model of the problem and guessing a path that the program is allowed to access), but the user experience is just made worse for no benefit. The general theme is that the user wants the sandboxed program to be able to do something that the person who assigned privileges didn't think of. So maybe if we must do sandboxing, let's make it easy for users to break programs out of the sandbox when it suits them?

fc417fc802 2y ago
You raise many good points. One of the primary reasons I don't use nix or guix for everything is because it seems like there's too much magic and it's often too difficult for me to figure out how to modify a detail if a toggle wasn't explicitly provided for it. Even just getting insight into the chain of events to debug things was incredibly obtuse the last time I played with nix. Like cmake on steroids. At least cmake will spit out a multi-megabyte trace file for me to pick through. (I'm convinced cmake is an elaborate conspiracy to waste developer time.) > let's make it easy for users to break programs out of the sandbox when it suits them? At least for Flatpak given the things you described this is quite straightforward via bind mounts. Although it did seem a bit goofy having an entire list of per-application bind mounts in my fstab. Maybe things have improved since I last tried going that route? > "idiomatic" ... doesn't use a file dialog, That's an Inkscape (plugin?) bug plain and simple. GUI apps should be using the appropriate xdg portals for all supported operations at this point. The only excuse (IMHO) is for missing or broken functionality. It would be like a system tray widget not working and blaming the DE instead of the program that fails to implement the decently old and widely adopted standard. > Matrix ... you can't share any files with anyone Which client is this? Anyway the xdg portal should work. Did the dev try it? Programs should never need blanket access to save or open specific user supplied paths as a one off. That's a large part of the point of sandboxing stuff in the first place.

gf000 2y ago

Such sandboxes would only work well, if the whole OS would be built around supporting them. You would essentially need Android or iOS for it to not be a pain in the ass Nonetheless, in this year and age this should be the bare minimum from a security point of view.

fc417fc802 2y ago
The usual answer in Android is "you can't do that". The primary difference from my perspective is that developers for those platforms design with the limitations in mind. Stuff on linux often just breaks and requires involved workarounds if it wasn't intended by the developer to be stuffed into a flatpak. (And might not even compile under nix without half a dozen monkey patches to the build system, let alone run once built.)
- microtonal 2y ago
  I think developers of desktop application are generally open towards facilitating sandboxing though. Most applications use standard XDG folders for files, use standard toolkit file pickers, etc. I don't have hard data, but my impression is that the general tendency in Flatpaks is that they are able to do more sandboxing over time. When Flatpak was new, a lot of applications pretty much required completely opening their sandboxes, the same applications have much more limited privileges nowadays. It's a long process, but at least with desktop applications there is progress. Unfortunately, the same can't really be said about command-line tools and development tools (NPM, cargo, pip, editor plugins, etc.).
  - fc417fc802 2y ago
    I'm not even sure what it would look like for CLI tools. Probably the sanboxing tools themselves need better controls and better UX for those controls. For CLI a solution would probably look a lot like unshare or (a more user friendly version of) setcap. The user would need to reach out to the sandbox to communicate what additional things to permit during this specific session. And then inevitably someone would configure the equivalent of passwordless sudo at which point I wonder what the point of the whole thing was to begin with. Related, we need a better paradigm for CLI to differentiate between user versus programmatically generated input. A program shouldn't be able to impersonate me unless I explicitly granted it some extremely unusual privileges.

mid-kid 2y ago

> Still, I think the xz backdoor did not work on NixOS because its unusual non FHS-compliant filesystem structure. It didn't work on nixos because the build-time check included checking whether the build was being executed in a debian or fedora build environment. This was to avoid suspicious build failures on distros with weird toolchains or incompatible architectures/ABIs/library versions. (The backdoor was a precompiled .o file so rather ABI sensitive)