With all the supply chain attacks in the Linux ecosystem, isn’t the natural solution to move to full application sandboxing?

Flatpacking is great but not all applications support it.

Is it too much of a hassle?

  • ghost_laptop@lemmy.ml
    link
    fedilink
    arrow-up
    3
    ·
    1日前

    The latest attack on the AUR would be solvable by Nix, in theory, Qubes would still suffer from this, only it’s compartmentalized, whereas Nix would be safe from my understanding.

    • FineCoatMummy@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      2
      ·
      12時間前

      The latest attack on the AUR

      For anyone else like me who was OOTL, I guess that refers to this…

      https://thehackernews.com/2026/06/over-400-arch-linux-aur-packages.html

      If a flagged package ran, treat the host as credential-compromised. Rotate everything the stealer touches: browser sessions, SSH keys, GitHub and npm tokens, Slack, Teams and Discord sessions, Vault tokens, Docker and Podman credentials, and any cloud keys.

      If the package ran as root, assume the rootkit is present and reinstall from trusted media. There is no way to trust the system otherwise.

      Jeepers!

      • moonpiedumplings@programming.dev
        link
        fedilink
        English
        arrow-up
        6
        ·
        edit-2
        22時間前

        This is not the same. The AUR was a supply chain attack, where good packages where replaced with malicious one’s.

        Nix is better at stopping things like that from happening, becuase they have a monorepo, where most package updates or changes are reviewed by another person. The AUR is just a collection of individual git repos (or branches), where each maintainer can make updates or changes with no oversight.

          • moonpiedumplings@programming.dev
            link
            fedilink
            English
            arrow-up
            5
            ·
            edit-2
            22時間前

            The original person you replied was commenting that nix was less vulnerable to supply chain attacks. Your reply is essentially completely off topic, talking about CVE’s. They are not the same type of issue. Having an actively running piece of malware on your system is vastly more concerning than a vulnerability someone has yet to exploit, and the supply chain security techniques needed to protect against the former are different as well.

            Immutability is an extremely poor defense against any form of attack. Immutability is literally a filesystem feature where a flag, chatttr -i is set on files or folders. Any program with root can adjust this flag, and any program running as a user could download additional binaries to or modify the users home directory. This is how the nix daemon works.

            Now, if nixos followed (or you configured it to follow) a model where only binaries in the nix store could be executed, and nothing else could be executed (in addition to maybe say, using selinux to enforce that only the nix daemon is editing the nix store), that would be much more secure and very interesting. But it’s not doing that.

            Edit: correction, the nix store is not actually immutable on the filesystem level. It merely holds immutable “outputs”, the packages and functions it generates. You’re not supposed to edit them… but nothing stops you (if you’re root or the nix daemon user). You can verify the nix store pretty easily, but it’s not an ongoing process, that is to say it wouldn’t catch malicious changes.

            What I said above about a theoretical applocker enabled like system based on Nix still applies, however.

      • ghost_laptop@lemmy.ml
        link
        fedilink
        arrow-up
        3
        ·
        1日前

        how would nix be affected by an attack like the one in the aur? nix packages its own dependencies, which are then packaged into other packages. the attack on the aur was possible because some software called for a library to be downloaded somewhere and npm was affected which ended up affecting the aur. for it to work on nix someone would have to upload a malicious package into the nixpkgs, which im not saying its impossible, but at the bare minimum there’s a bigger barrier than basically 0 compared to the aur.