Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (Cyborg)
  • No Skin
Collapse
Brand Logo

CIRCLE WITH A DOT

  1. Home
  2. Uncategorized
  3. While #NixOS should not be affected by #CopyFail as it uses recent kernels, here are additional fixes you can apply:

While #NixOS should not be affected by #CopyFail as it uses recent kernels, here are additional fixes you can apply:

Scheduled Pinned Locked Moved Uncategorized
nixoscopyfailsudopkexec
3 Posts 3 Posters 1 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • rhababerbarbar@tux.socialR This user is from outside of this forum
    rhababerbarbar@tux.socialR This user is from outside of this forum
    rhababerbarbar@tux.social
    wrote last edited by
    #1

    While #NixOS should not be affected by #CopyFail as it uses recent kernels, here are additional fixes you can apply:

    Disabling setuid does not mitigate it, but reduces the attack surfaces overall significantly.

    Instead of #sudo, #su, #pkexec and other #setuid binaries you can use #run0 or a dedicated root account.

    I have disabled setuid for a bunch of binaries I don't need, they still work when ran as root, with run0 or #sudo-rs.

    ```nix
    boot.blacklistedKernelModules = [
    "algif_aead"
    ];

    security.sudo.enable = false;

    security.wrappers = {
    su.enable = false;
    pkexec.enable = false;

    # example setuid binary
    chsh = {
    source = "${pkgs.shadow}/bin/chsh";
    setuid = lib.mkForce false;
    owner = "root";
    group = "root";
    };
    };
    ```

    marie@chaos.socialM 1 Reply Last reply
    1
    0
    • rhababerbarbar@tux.socialR rhababerbarbar@tux.social

      While #NixOS should not be affected by #CopyFail as it uses recent kernels, here are additional fixes you can apply:

      Disabling setuid does not mitigate it, but reduces the attack surfaces overall significantly.

      Instead of #sudo, #su, #pkexec and other #setuid binaries you can use #run0 or a dedicated root account.

      I have disabled setuid for a bunch of binaries I don't need, they still work when ran as root, with run0 or #sudo-rs.

      ```nix
      boot.blacklistedKernelModules = [
      "algif_aead"
      ];

      security.sudo.enable = false;

      security.wrappers = {
      su.enable = false;
      pkexec.enable = false;

      # example setuid binary
      chsh = {
      source = "${pkgs.shadow}/bin/chsh";
      setuid = lib.mkForce false;
      owner = "root";
      group = "root";
      };
      };
      ```

      marie@chaos.socialM This user is from outside of this forum
      marie@chaos.socialM This user is from outside of this forum
      marie@chaos.social
      wrote last edited by
      #2

      @Rhababerbarbar setuid binaries have nothing to do with the vulnerability, they are just an easy way of exploiting it. Avoiding them does not make you less vulnerable to copyfail. (blacklisting the kernel module is good)

      jay@social.zerojay.comJ 1 Reply Last reply
      0
      • R relay@relay.infosec.exchange shared this topic
      • marie@chaos.socialM marie@chaos.social

        @Rhababerbarbar setuid binaries have nothing to do with the vulnerability, they are just an easy way of exploiting it. Avoiding them does not make you less vulnerable to copyfail. (blacklisting the kernel module is good)

        jay@social.zerojay.comJ This user is from outside of this forum
        jay@social.zerojay.comJ This user is from outside of this forum
        jay@social.zerojay.com
        wrote last edited by
        #3

        @marie @Rhababerbarbar Also, almost no one is going to be running the vulnerable kernel module anyways unless they compiled a monolithic kernel so..., yeah, feels pretty overblown to me.

        1 Reply Last reply
        1
        0
        • R relay@relay.publicsquare.global shared this topic
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups