grsec fix kernel version

[evrim]

Issue description

Hello,

How can I fix the kernel version and continue with the grsec kernel?

nixos-rebuild switch

building Nix...
building the system configuration...
error: Upstream has ceased free support for grsecurity/PaX.

See https://grsecurity.net/passing_the_baton.php
and https://grsecurity.net/passing_the_baton_faq.php
for more information.

(use ‘--show-trace’ to show detailed location information)

Steps to reproduce

Technical details

• System: 17.03.1057.c545296adc (Gorilla)

[vcunat]

I suppose that would really only work for a limited time, as pinning to old kernel would stop you from receiving security updates to it...

[vcunat]

See also #25277.

[joachifm]

You could use https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec but there's no telling how long that'll keep going.

[joachifm]

Also, there's the issue of bugs in grsec/PaX itself: who'd you report them to and who'd be qualified to fix them? There have been serious bugs before, there's no reason to believe the last public test patch is "perfect".

[mrobbetts]

I definitely see some value in offering the latest grsec-patched kernel version, at least for a while. Is it a big maintenance burden to do that?

[vcunat]

Note: if this is revived, we probably shouldn't call it grsec(urity) anymore.

[NeQuissimus]

Not sure how much it helps @mrobbetts but we do have the Copperhead kernel in nixpkgs (https://github.com/copperhead/linux-hardened). They integrate and update regularly and a lot of changes are based on PaX/grsec (Repo says "Changes from PaX / grsecurity are marked as such")

[evrim]

I integrated minipli kernel (4.9.40-unofficial+grsec) using a custom module, compiling it right atm. I'll be able to tell more this week, I hope.

[NeQuissimus]

Cool, curious to see how that goes :)

[evrim]

After fiddling with the computer, it decided to work.

$ uname -a
Linux hostname 4.9.40-unofficial+grsec #1-NixOS SMP Thu Jan 1 00:00:01 UTC 1970 x86_64 GNU/Linux
$ journalctl -k -f
-- Logs begin at Fri 2017-04-21 07:05:08 +03. --
Jul 31 18:52:02 hostname kernel: grsec: denied read of sensitive /proc/pid/maps entry via fd passed across exec by /nix/store/q1idzrdisw0ikqi4kvv7rlz8930kxkhl-firefox-unwrapped-54.0.1/lib/firefox-54.0.1/firefox[Web Content:1554] uid/euid:1000/1000 gid/egid:100/100, parent /nix/store/q1idzrdisw0ikqi4kvv7rlz8930kxkhl-firefox-unwrapped-54.0.1/lib/firefox-54.0.1/firefox[Gecko_IOThread:1375] uid/euid:1000/1000 gid/egid:100/100
Jul 31 18:52:02 hostname kernel: grsec: more alerts, logging disabled for 10 seconds

If #25208 is fixed, I'll be very happy. It takes ages to compile.

What should we do now, revive?
I propose the name "batonsecurity" in case of revival.

[NeQuissimus]

You could just sent in a PR with a kernel derivation similar to that of Copperhead?!
It should just work if you switch out the variables and URL

[NeQuissimus]

@evrim Did you want me to create the PR?

[evrim]

@NeQuissimus I've used the following if you are interested in compiling.

{ stdenv, hostPlatform, fetchFromGitHub, perl, buildLinux, ...}@args:
let
  kernelPath =  + "/pkgs/os-specific/linux/kernel/";
  branch = "4.9";
  version = branch + ".40";
  revision = "74213b1";
in import (kernelPath + "/generic.nix") (args // {
   inherit version;
   ignoreConfigErrors = true;
   extraMeta.branch = branch;
   modDirVersion = version + "-unofficial+grsec";
   src = fetchFromGitHub {
     owner = "minipli";
     repo = "linux-unofficial_grsec";
     rev = revision;
     sha256 = "1rv345hciwc1mjz6r8wx8f0fqd4mkc84q36nna7xq1rlgml8m933";
   };
   kernelPatches = args.kernelPatches;
   features.iwlwifi = true;
   features.efiBootStub = true;
   features.needsCifsUtils = true;
   features.netfilterRPFilter = true;
} // (args.argsOverride or {}))

[evrim]

won't fix.