{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiczeva5rcrkwlmw3nj6pc7yewb3iur244ogfanif5fggjx2tdvo74",
    "uri": "at://did:plc:haakkg7y3xdghcdmprxeexso/app.bsky.feed.post/3mlkp2zn2nqn2"
  },
  "path": "/t/is-secureblue-linux-secureblue-dev-also-vulnerable-by-these-three-recent-linux-vulnerabilities-copy-fail-copy-fail-2-and-dirty-frag/37728?page=2#post_23",
  "publishedAt": "2026-05-11T05:40:48.000Z",
  "site": "https://discuss.privacyguides.net",
  "tags": [
    "suid-root",
    "@SkewedZeppelin"
  ],
  "textContent": "There are a lot of mistaken assumptions in this thread that are just being repeated, and the chosen “solution” is adding to the confusion.\n\nThe practical exploit paths for Copyfail leverage suid-root binaries, which secureblue has entirely eliminated in our non-nvidia images. The vulnerability itself isn’t prevented by this but it substantially raises the exploit bar so as to render all published exploit paths nonfunctional on secureblue. Suid binaries are a common source of attack surface used in exploit chains, so this isn’t very surprising. It’s just the latest example that highlights why eliminating suid-root is so important.\n\nMoving on, the “dirtyfrag” exploit actually refers to two paths:\n\nOne is the xfrm-ESP path, which requires unprivileged user namespaces, which secureblue blocks by default using SELinux.\n\nThe other is the RXRPC path, which does not require unprivileged user namespaces.\n\n> A) I don’t have Discord to join their public dev channel.\n\nThis is not an excuse for making assumptions and drawing conclusions from them. If you don’t know, ask. Barring that, the least you can do is not spread your assumptions.\n\n> But like my real question is what’s even the point of secureblue? I thought secureblue was the one to protect us from such stuff. But it’s also vulnerable to the CVE’s just like ever other distro.\n\nOn the contrary these exploits are a great example of why proactive security is so important and how it can mitigate exploit paths (copyfail) or even prevent exploit paths entirely (the xfrm-ESP path).\n\n> changing some things\n\nWe are looking into implementing some kind of module allowlisting inspired by the one that @SkewedZeppelin is building. We’re also building out our SELinux policy to restrict non-kernel processes from accessing various sockets. We’re also already in the process of working with NVIDIA devs to remove the only remaining suid-root binary from our images, which only exists on the nvidia images, `nvidia-modprobe`. As far as I’m aware, secureblue is the only desktop linux system that provides a fully suid-root and sgid-root free system, which means it was the only desktop linux system not susceptible to the published copyfail exploit paths.",
  "title": "Is secureblue linux [ secureblue.dev ] also vulnerable by these three recent linux vulnerabilities - Copy Fail, Copy Fail 2 and Dirty Frag?"
}