I'd consider restoring the grsecurity kernel configuration instead of using the hardened config (I intended that one for vanilla only). Then maybe integrate the kernel with the grsec nixos module (renaming it & updating the manual accordingly, esp. anything relevant to trademark issues).

I too would like free grsec to continue but I worry that this is selling something on the grsec legacy without really offering an equivalent product.

$ cat config.nix 
{ stdenv }:
with stdenv.lib;
''
# Auto configuration with these constraints will enable most of the
# important features (RAP, UDEREF, ASLR, memory sanitization).
GRKERNSEC y
# GRKERNSEC_CONFIG_AUTO is not set
GRKERNSEC_CONFIG_CUSTOM y    # do custom configuration
# GRKERNSEC_CONFIG_DESKTOP is not set
# GRKERNSEC_CONFIG_PRIORITY_SECURITY y

# We specify virt guest rather than host here, the latter deselects e.g.,
# paravirtualization.
# GRKERNSEC_CONFIG_VIRT_GUEST y
# Note: assumes platform supports CPU-level virtualization (so no pentium 4)
# GRKERNSEC_CONFIG_VIRT_EPT y
# GRKERNSEC_CONFIG_VIRT_KVM y

# PAX PAX PAX PAX PAX PAX
PAX y

# PaX control
PAX_SOFTMODE y
PAX_PT_PAX_FLAGS y
PAX_XATTR_PAX_FLAGS y
PAX_EI_PAX n

# PaX Nonexecutable Pages
PAX_NOEXEC y
PAX_PAGEEXEC y
PAX_EMUTRAMP y
PAX_MPROTECT y
PAX_MPROTECT_COMPAT n
PAX_ELFRELOCS n
# PAX_KERNEXEC y  # Equivalent to PAGEEXEC and MPROTECT
# PAX_KERNEXEC_PLUGIN y
PAX_KERNEXEC_PLUGIN_METHOD_NONE y # cat /proc/cpuinfo|grep smep
# PAX_KERNEXEC_PLUGIN_METHOD_BTS is not set # See PAX_RAP

# PaX ASLR
PAX_ASLR y
PAX_RANDKSTACK y	     # Kernel Task Stack
PAX_RANDUSTACK y 	     # User Stack
PAX_RANDMMAP y   	     # Mmap without a base

# PaX Miscellaneous
PAX_MEMORY_SANITIZE y
PAX_MEMORY_STACKLEAK y	     # bzero stack
PAX_MEMORY_STRUCTLEAK y      # bzero structs
PAX_MEMORY_UDEREF y   	     # Userspace Deference from Kernel !! Problem?
PAX_REFCOUNT y 	  	     # (re)count references
PAX_USERCOPY y 		     # apply bounds copy_{from, to}_user
PAX_CONSTIFY_PLUGIN y  	     # make struct { void (*fun) {..} } constant.
PAX_SIZE_OVERFLOW y   	     # assert size signature on function arguments
PAX_SIZE_OVERFLOW_EXTRA n    # do extra dynamic analysis
PAX_INITIFY y 		     # free unused kernel functions
PAX_INITIFY_VERBOSE y 	     # enable verbose mode to aid in debugging
PAX_LATENT_ENTROPY y 	     # generate more entropy at boot
PAX_RAP y	   	     # rop protection

# Memory Protections
GRKERNSEC_KMEM y 	     # disable /dev/kmem, /dev/mem, /dev/port, /dev/cpu/*/msr
GRKERNSEC_IO y 	   	     # ioperm restriction
GRKERNSEC_BPF_HARDEN y	     # harden bpf jit
GRKERNSEC_PERF_HARDEN y	     # /proc/sys/kernel/perf_event_paranoid => 3
GRKERNSEC_RAND_THREADSTACK y # put gap btw thread stacks
GRKERNSEC_PROC_MEMMAP y      # disable /proc/self/{maps,stat}
GRKERNSEC_KSTACKOVERFLOW y   # put barrier between kernel task (struct & stack)
GRKERNSEC_BRUTE y 	     # disable brute forcing (meh?)
GRKERNSEC_MODHARDEN n 	     # autoload modules from group=users
GRKERNSEC_HIDESYM y 	     # hide symbols in /proc (ie kallsyms)
GRKERNSEC_RANDSTRUCT y 	     # randomize task struct
GRKERNSEC_RANDSTRUCT_PERFORMANCE y # don't randomize bit fields
GRKERNSEC_KERN_LOCKOUT y     # Lockout violating user

# Role Based Access Control Options (RBAC)
# GRKERNSEC_NO_RBAC n 	     # disable /dev/grsec and RBAC
# GRKERNSEC_ACL_HIDEKERN n   # hide kernel tasks
GRKERNSEC_ACL_MAXTRIES 3     # max tries to access RBAC
GRKERNSEC_ACL_TIMEOUT 30     # timeout to retry to access RBAC

# Filesystem Protections
GRKERNSEC_PROC y	     # enable /proc restrictions
GRKERNSEC_PROC_USER y	     # restrict non-root users
GRKERNSEC_PROC_ADD y	     # additional restrictions
GRKERNSEC_LINK y   	     # follow symlinx restrictions
GRKERNSEC_SYMLINKOWN n	     # something about symlinx?
GRKERNSEC_FIFO n     	     # restrict FIFO's
GRKERNSEC_SYSFS_RESTRICT n   # don't enable it yet
GRKERNSEC_ROFS n	     # read-only fs, don't need
GRKERNSEC_DEVICE_SIDECHANNEL y # prevent side-channel, timing to devices

# Chroot Restrictions
GRKERNSEC_CHROOT n		# disable them for now
# GRKERNSEC_CHROOT_MOUNT n
# GRKERNSEC_CHROOT_DOUBLE n
# GRKERNSEC_CHROOT_PIVOT n
# GRKERNSEC_CHROOT_CHDIR n
# GRKERNSEC_CHROOT_CHMOD n
# GRKERNSEC_CHROOT_FCHDIR n
# GRKERNSEC_CHROOT_MKNOD n
# GRKERNSEC_CHROOT_SHMAT n
# GRKERNSEC_CHROOT_UNIX n
# GRKERNSEC_CHROOT_FINDTASK n
# GRKERNSEC_CHROOT_NICE n
# GRKERNSEC_CHROOT_SYSCTL n
# GRKERNSEC_CHROOT_RENAME n
# GRKERNSEC_CHROOT_CAPS n
# GRKERNSEC_CHROOT_INITRD n

# Kernel Audititing
GRKERNSEC_AUDIT_GROUP n	     # audit everybody, not just a group
# GRKERNSEC_AUDIT_GID is not set
GRKERNSEC_EXECLOG n   	     # log execve(), disables, too much noise
GRKERNSEC_RESLOG y	     # resource limit overstep logging
GRKERNSEC_CHROOT_EXECLOG n   # chroot() execve() logging
GRKERNSEC_AUDIT_PTRACE y     # log ptrace()
GRKERNSEC_AUDIT_CHDIR n	     # log chdir()
GRKERNSEC_AUDIT_MOUNT y	     # log mount()
GRKERNSEC_SIGNAL y     # signal SIGSEGV
GRKERNSEC_FORKFAIL y   # log failed fork()
GRKERNSEC_TIME y	     # log time changes
GRKERNSEC_PROC_IPADDR y      # put /proc/pid/ipaddr of the user
GRKERNSEC_RWXMAP_LOG y	     # log denied RWX mmap() calls

# Executable Protections
GRKERNSEC_DMESG y	     # deny dmesg(8)
GRKERNSEC_HARDEN_PTRACE y    # don't attach to random process
GRKERNSEC_PTRACE_READEXEC y  # ptrace() only elfs that are readable to the user
GRKERNSEC_SETXID y	     # enforce all threads to drop priviledges at once
GRKERNSEC_HARDEN_IPC y	     # harden IPC objects
GRKERNSEC_HARDEN_TTY y	     # harden tty
GRKERNSEC_TPE n	     	     # trusted path executions

# Network Protections
GRKERNSEC_BLACKHOLE y	     # network blackhole, (no RST etc)
GRKERNSEC_NO_SIMULT_CONNECT y # very interesting option (??)
GRKERNSEC_SOCKET n	     # restict sockets to a GID

# Physical Protections
GRKERNSEC_DENYUSB n	     # deny new usb devices

# Sysctl Support
GRKERNSEC_SYSCTL y
GRKERNSEC_SYSCTL_DISTRO y
# Assume that appropriate sysctls are toggled once the system is up
GRKERNSEC_SYSCTL_ON n

# Logging Options
GRKERNSEC_FLOODTIME 3
GRKERNSEC_FLOODBURST 4
''

Notes:

• dmesg(8) is not working, i guess its ported to vanilla already,
• disabled chroot since i want to experience, test with buildFHSEnv

I have enabled ignore unused options in manual-config and the result is as follows:

$ cat unused_options 
warning: unused option: BPF_EVENTS
warning: unused option: DEBUG_SET_MODULE_RONX
warning: unused option: DEVKMEM
warning: unused option: DYNAMIC_DEBUG
warning: unused option: FTRACE
warning: unused option: FTRACE_SYSCALLS
warning: unused option: FUNCTION_PROFILER
warning: unused option: FUNCTION_TRACER
warning: unused option: KEXEC_JUMP
warning: unused option: NOTIFIER_ERROR_INJECTION
warning: unused option: PAX_CONSTIFY_PLUGIN
warning: unused option: PAX_MEMORY_UDEREF
warning: unused option: RANDOMIZE_BASE
warning: unused option: RING_BUFFER_BENCHMARK
warning: unused option: SCHED_TRACER
warning: unused option: SECURITY_YAMA
warning: unused option: STACK_TRACER
warning: unused option: SUNRPC_DEBUG
warning: unused option: UPROBE_EVENT
warning: unused option: USERFAULTFD

Interestingly, UDEREF is said to be unused. This is a bummer, I would like to have that feature.
Anyway, these are my experiences, I hope it helps.

modified kmod patch, please check/verify before merging.

 cat batonsec-kmod.patch 
diff -ru a/kernel/kmod.c b/kernel/kmod.c
--- a/kernel/kmod.c	2016-04-21 17:06:09.882281660 +0200
+++ b/kernel/kmod.c	2016-04-21 17:08:17.458949309 +0200
@@ -290,11 +290,12 @@
 	   out the path to be used prior to this point and are now operating
 	   on that copy
 	*/
-	if ((strncmp(sub_info->path, "/sbin/", 6) && strncmp(sub_info->path, "/usr/lib/", 9) &&
-	     strncmp(sub_info->path, "/lib/", 5) && strncmp(sub_info->path, "/lib64/", 7) &&
-	     strncmp(sub_info->path, "/usr/libexec/", 13) && strncmp(sub_info->path, "/usr/bin/", 9) &&
-	     strncmp(sub_info->path, "/usr/sbin/", 10) && strcmp(sub_info->path, "/bin/false") && 
-	     strcmp(sub_info->path, "/usr/share/apport/apport")) || strstr(sub_info->path, "..")) {
+	if ((strncmp(sub_info->path, "/run/current-system/sw/bin/", 27) &&
+	     strncmp(sub_info->path, "/run/current-system/sw/sbin/", 28) &&
+	     strncmp(sub_info->path, "/bin/false", 10) && 
+	     strncmp(sub_info->path, "/nix/store/", 11) &&
+	     strncmp(sub_info->path, "/run/current-system/systemd/", 28)) ||
+	    strstr(sub_info->path, "..")) {
 		printk(KERN_ALERT "grsec: denied exec of usermode helper binary %.950s located outside of permitted system paths\n", sub_info->path);
 		retval = -EPERM;
 		goto out;

@evrim, where did your kernel config come from?

@NeQuissimus Its mine, took from nowhere.

@evrim Do you mind if I include it in this PR?

@NeQuissimus Not at all, go ahead.

I am just re-running the test, then I will update

Remind that, you will need the kmod patch if you like the machine to boot.

Yes, I restored a few files we used to have when grsec was still free, this was one of them.

The job exceeded the maximum time limit for jobs, and has been terminated.

...as expected :) (Kernel builds take longer than TravisCI allows)

grsecurity test:

[...]
machine: exit status 0
machine# [    8.510248] PAX: execution attempt in: <heap>, 02a4d000-02a70000 02a4d000
machine# [    8.510251] PAX: terminating task: /nix/store/lhd47iy9x0lcvkrf2in04v226xxrg8cs-paxtest-0.9.15/lib/paxtest/mprotheap(mprotheap):743, uid/euid: 0/0, PC: 0000000002a4ee90, SP: 00007bea936e3e38
4 out of 4 tests succeeded
test script finished in 9.78s
cleaning up
killing machine (pid 110)
vde_switch: EOF on stdin, cleaning up and exiting
vde_switch: Could not remove ctl dir '/tmp/nix-build-vm-test-run-grsecurity.drv-0/vde1.ctl': Directory not empty
/nix/store/ky92lhhrmxx6j8vf35pmfcky8fffyzvi-vm-test-run-grsecurity

So for the kernel config, I merged what we used to have which what you have. It should be relatively sane.
Don't worry about the mess I am making with the common config, I have a re-org PR for that incoming; that file has been bugging me for a while.

• Kernel builds
• Test passes

Final remark.I had the following grsec complaint last week:

"cannot execute /run/current-system/sw/bin/bridge-stp usermode helper"  

So, the above kmod patch is an updated version. I am still unsure about the bin and sbin stuff. Maybe bridge-stp should be moved to sbin/ and we remove bin/ from the list.

Anyway, good luck with the PR's. I hope it gets through without a fuss.

Best.

Do you think we are good to merge now? I'd love for Hydra to build this, so I can try it out next week and see what trouble I run into at work :)

I'm against using this patch, as I've explained elsewhere, but it seems I'm alone in thinking its a bad idea so I'll just pretend this doesn't exist ...

More importantly, I believe not enough has been done to distinguish this from the "real" grsecurity, which is a trademark of Open Source Security, Inc. As it is, I think end-users can easily be mislead.

Oh, I must have missed that. Can you point me towards why you would not use it?

I can see the reasoning behind it showing up as "grsec". What do you think we should do about it? I am open to suggestions. I am unsure about renaming all the NixOS modules. The kernel identifies as "grsec+unofficial", should we rename that?

https://grsecurity.net/passing_the_baton_faq.php

This actually specifically asks not to use the grsecurity trademark. I will make some changes to rename these things.
Now, would we want to rename the module? Is it still a valid use case for somebody to want the "real" grsec?

Briefly, I think that a complex patch like this ought to have a real upstream proactively fixing flaws. There's more to maintaining this than resolving merge conflicts & keeping it compiling, imo. Also note that the original patch would include various fixes in addition to the grsec/PaX stuff, so the forward-port really is a deficient product, even if spender and co somehow managed to create a perfect piece of software, suitable for use unchanged in perpetuity.

As far as the trademark thing is concerned, that's really more of a legal question, I don't know what the standard is exactly. I'd think that any user-visible module names, options, and package names should not contain the words grsecurity or PaX. Just calling this "unoffical grsecurity" seems to me akin to selling a carbonated cola flavoured beverage called "Unofficial Coca Cola".

The more I think about it, the more I think you are correct. At the same time, it would be valuable to have a "more secure" alternative to a vanilla kernel (even with a hardened config).
Now, I am maintaining the Copperhead hardened linux kernel, which takes some of the grsec/pax things but does proper maintenance (Used to be the Gentoo "hardened kernel" project - https://wiki.gentoo.org/wiki/Hardened_Kernel).

I could imagine using that as a base for a "secure" NixOS...
We could explore how well the kernel config works against that? Let me put together a PR and see what happens there. The trademark thing is something I would not want to mess with so I'd say we let this minipli thing along for now. (although it does work, I am running it right now)

Standardizing on a single "hardened" config sounds like a good idea. If you trust copperhead, I'd be fine with replacing linux_hardened with that. Having two of those seems redundant anyway.

Re. copperhead, my impression from lurking on their IRC is that the wiki doesn't tell the full story of where the project's at (my takeaway is that it kind of failed). The drama surrounding the project is why I thought it better to just focus on vanilla (KSPP existed before copperhead). Then again, I can't demonstrate that the vanilla mitigations actually help so all of it might turn out to be theathre ...

hmm, maybe hardening a vanilla kernel by hand is the way to go after all... None of the "unofficial grsec successors" out there make me truly happy :)
Copperhead looks fine but it has none of the PaX stuff...

My initial idea with the "hardened" kernel config was mostly as a test bed with a view to eventually get stuff into the standard config. I think that eventually benefits more people & reduces maintenance burden.

https://www.theregister.co.uk/2017/08/03/linux_kernel_grsecurity_sues_bruce_perens_for_defamation/
Updated In late June, noted open-source programmer Bruce Perens warned that using Grsecurity's Linux kernel security could invite legal trouble.

"As a customer, it's my opinion that you would be subject to both contributory infringement and breach of contract by employing this product in conjunction with the Linux kernel under the no-redistribution policy currently employed by Grsecurity," Perens wrote on his blog.