# Hardened Gentoo with Vanilla kernel (4.8)

## NTU

Hello,

Kernel 4.8 merged quite a few new security patches based off of PaX. I noticed that Gentoo Hardened by default has pax_kernel set, as well as masked USE flags such as sanitize. paxctl is also part of the system world, considering I'm not using PaX though, I did this:

```
$ cat /etc/portage/profile/packages

-*dev-python/pypax

-*app-misc/pax-utils

-*sys-apps/paxctl

-*sys-apps/paxctld

-*sys-apps/elfix
```

Some of them might not be needed, added them in anyway in case I'd miss one. The reason I use hardened is for hardened userland, automatic SSP/PIE. I noticed that when using getfattr I came across this.

```
$ getfattr /usr/bin/python2

getfattr: Removing leading '/' from absolute path names

# file: usr/bin/python2

user.pax.flags

$ getfattr /usr/bin/python3

getfattr: Removing leading '/' from absolute path names

# file: usr/bin/python3

user.pax.flags
```

Recompiling python 2 and 3 didn't make them disappear, so I ran the following:

```
# setfattr -x user.pax.flags /usr/bin/python2

# setfattr -x user.pax.flags /usr/bin/python3
```

If Gentoo Hardened is meant to be run on ONLY the hardened kernel, then why not just mask the vanilla and gentoo sources as well? I don't think users should be pushed into / assumed that they're using a PaX kernel if they're running hardened. I think that when emerging hardened-sources, there should be a message that pops up (like those ones in summary.log) that says to be sure to be put pax_kernel in your USE flags and such. Thoughts of this transition?

I was actually going to be digging through the patch blob itself and breaking it up into pieces as the development platform for Grsecurity is very backwards. No public git, no proper patch tracking and noting of changes, just a "here's a 9MB kernel patch with a dumb down changelog, have fun!" I've tried talking to the Grsecurity developers in a very polite, professional manner, about properly going through the patch and cleaning it up so it's not just sitting all in one file, only to come back to have a long list of insults waiting for me. They have no interest in breaking up the patch blob, nobody cares, alright that's fine, but what I do find interesting is how much spender and his buddies do NOT want me modifying their patch and going through their code, which is a bit suspicious IMO, especially considering how angry and emotional the team got. I will share with you the same thing I shared with them for whatever it's worth. Here is the list of features I'll be breaking up.

```
PAX_USERCOPY (seems to now be mainlined)

PAX_USERCOPY_DEBUG (ez gg)

PAX_USERCOPY_SLABS (seems to now be mainlined)

GRKERNSEC_PROC

GRKERNSEC_PROC_ADD

GRKERNSEC_PROC_GID

GRKERNSEC_PROC_IPADDR

GRKERNSEC_PROC_USER

GRKERNSEC_PROC_USERGROUP

GRKERNSEC_LINK

PAX_MEMORY_STACKLEAK

PAX_MEMORY_STRUCTLEAK (ez)

GRKERNSEC_KMEM (will require some work)

GRKERNSEC_VM86 (ez)

GRKERNSEC_IO (ez)

GRKERNSEC_BPF_HARDEN (ez)

GRKERNSEC_PERF_HARDEN (ez)

GRKERNSEC_KSTACKOVERFLOW (support with PAX_MEMORY_STACKLEAK, thanks Kconfig)

GRKERNSEC_BRUTE

GRKERNSEC_MODHARDEN

GRKERNSEC_HIDESYM (support with GRKERNSEC_PERF_HARDEN)

GRKERNSEC_RANDSTRUCT

GRKERNSEC_KERN_LOCKOUT (ez)

GRKERNSEC_RBAC_DEBUG

GRKERNSEC_NO_RBAC

GRKERNSEC_ACL_HIDEKERN (ez)

GRKERNSEC_ACL_MAXTRIES (ez)

GRKERNSEC_ACL_TIMEOUT (ez)

GRKERNSEC_KMEM

GRKERNSEC_VM86

GRKERNSEC_FIFO

GRKERNSEC_SYSFS_RESTRICT

GRKERNSEC_DEVICE_SIDECHANNEL (ez)

GRKERNSEC_CHROOT

GRKERNSEC_CHROOT_* (all of them)

GRKERNSEC_RESLOG

GRKERNSEC_AUDIT_PTRACE

GRKERNSEC_AUDIT_MOUNT

GRKERNSEC_SIGNAL

GRKERNSEC_FORKFAIL

GRKERNSEC_DMESG

GRKERNSEC_HARDEN_PTRACE

GRKERNSEC_PTRACE_READEXEC (support with GRKERNSEC_AUDIT_PTRACE and GRKERNSEC_HARDEN_PTRACE)

GRKERNSEC_SETXID

GRKERNSEC_HARDEN_IPC

GRKERNSEC_HARDEN_TTY

GRKERNSEC_BLACKHOLE (work)

GRKERNSEC_NO_SIMULT_CONNECT

GRKERNSEC_SYSCTL

GRKERNSEC_SYSCTL_*

GRKERNSEC_FLOODTIME

GRKERNSEC_FLOODBURST

GRKERNSEC

PAX

Additional Realistic Notes:

GRKERNSEC_BPF_HARDEN:

Convert to blacklisting BPF kconfig options (BPF_JIT, CBPF_JIT, EBPF_JIT)

bpf_jit_32.c: bpf_jit_enable __read_mostly -> bpf_jit_enable __read_only

Above is shortcut (hehe lul)

PAX_CONSTIFY_PLUGIN (Kconfig says this requires PAX_KERNEXEC but I don't see how...)

Yet to review but most likely ez:

More grsec audit, more proc, dev/usb/tty/net, chroot/jail and other restrictions

Drop features which require wide changes to fs, drivers, netfilter etc

(You can find these around GRKERNSEC_LINK section of Kconfig)

Unrealistic:

List is pretty comprehensive at this point.

PAX_SIZE_OVERFLOW (too big, too much work, modifies too much behavior)

PAX_MEMORY_UDEREF (too much work)

PAX_REFCOUNT (too much work, modifies too much behavior)

PAX_KERNEXEC (too much work, modifies too much behavior)

PAX_EMUTRAMP (if we skip this we can avoid PAX_PAGEEXEC and PAX_SEGMEXEC, lots of work)

PAX_PAGEEXEC (required by EMUTRAMP, depends on PAX_NOEXEC)

PAX_SEGMEXEC (required by EMUTRAMP)

PAX_NOEXEC (grsecurity.h says one of PAGEEXEC, SEGMEXEC, or KERNEXEC must be enabled)

PAX_KERNEXEC_MODULE_TEXT (requires PAX_KERNEXEC)

PAX_KERNEXEC_PLUGIN (not supporting PAX_KERNEXEC)

PAX_KERNEXEC_PLUGIN_METHOD_* (not supporting PAX_KERNEXEC)

PAX_EMUPLT (requires MPROTECT)

PAX_ETEXECRELOCS (requires MPROTECT)

PAX_ELFRELOCS (requires MPROTECT)

PAX_MPROTECT_COMPAT (obvious)

PAX_SEGMEXEC (depends on PAX_NOEXEC)

GRKERNSEC_RWXMAP_LOG (depends on PAX_MPROTECT)

GRKERNSEC_RAND_THREADSTACK (depends on PAX_RANDMMAP)

GRKERNSEC_PROC_MEMMAP (depends on PAX_RANDMMAP || PAX_SEGMEXEC ?? ASLR?)

PAX_MPROTECT

Additional notes:

PAX_RAP (unstable for me right now)

PAX_DLRESOLVE (nobody uses pre-libc 2.4)

PAX_EMUSIGRT (depends on PAX_EMUTRAMP and security risk, dumb)

PAX_ASLR looks doable (CONFIG_PAX_RANDKSTACK ez, CONFIG_PAX_RANDUSTACK depends on PAX_RANDMMAP)

Blacklisting PAE all togethor when PAX enabled might be better than integrating PAX_ENABLE_PAE

PAX_MEMORY_SANITIZE looks to be PAGE_POISONING_ZERO (now mainline)

ez but stuff I don't use:

GRKERNSEC_SYMLINKOWN

GRKERNSEC_SYMLINKOWN_GID

GRKERNSEC_ROFS

GRKERNSEC_AUDIT_GROUP

GRKERNSEC_AUDIT_GID

GRKERNSEC_EXECLOG (spam)

GRKERNSEC_AUDIT_CHDIR (spam)

GRKERNSEC_PROC_IPADDR

GRKERNSEC_SOCKET

GRKERNSEC_SOCKET_*

GRKERNSEC_DENYUSB

GRKERNSEC_DENYUSB_FORCE

GRKERNSEC_RANDSTRUCT_PERFORMANCE

GRKERNSEC_TPE

GRKERNSEC_TPE_*

PAX_LATENT_ENTROPY

If PAX_RANDMMAP is to be supported, add the following:

PAX_EI_PAX

PAX_PT_PAX_FLAGS

PAX_XATTR_PAX_FLAGS

PAX_HAVE_ACL_FLAGS

PAX_NO_ACL_FLAGS

PAX_HOOK_ACL_FLAGS

PAX_SOFTMODE
```

It's a work in progress but that's what I have so far in regards to the separation of the patch. I'll be hosting the patchset on my github. If you'd like to volunteer in the development let me know, I wouldn't have to do this if grsecurity was a bit more development friendly.

This thread was really about the hardened-sources assumption by the portage profile, sorry I derailed my own thread!   :Razz: 

----------

## Hu

You may want to get involved with the Kernel Self Protection Project, which is also working on extracting some grsecurity features for inclusion upstream.  Merging those upstream would shrink future grsecurity blob dumps, which might make it easier to trace their activity.

----------

## zorry

Just add PAXMARKINS="none" to make.conf to disable all the pax markings.

----------

## NTU

Ah it's PAX_MARKINGS="none"

https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/pax-utils.eclass

That way I don't need to purge profile system packages. Gentoo has complained before about removing packages from your profile, such as nano, and how it may break your system.

Nano is so bad they don't even reference it in Silicon Valley.

https://www.youtube.com/watch?v=K5WW7JOBSjg

The Kernel Self Protection Project looks awesome, I'll have to look into that. In regards to the merges shrinking future grsecurity blobs, you have definitely not spoken to their development team. They claim that every single feature from grsecurity that hits upstream is halfass and improperly integrated, with virtually no improvement to security. The blobs will never get smaller, there will always be there own implementation on top of (or in place of) the future upstream kernel set of security patches. It's even that way now, such as PAX_USERCOPY. There is the kernel's USERCOPY, then when you apply the PaX patch, there's that one too, because the one in mainline isn't "done right." KASLR vs PAX_ASLR it's the same story there. It's not that they just forgot to remove those redundant features from the patches, it's done on purpose due to the fact the code isn't good enough for them, albeit much cleaner and developer friendly. It'd be nice though Hu, we can always dream.

Cheers mates!

----------

## mv

 *NTU wrote:*   

> They claim that every single feature from grsecurity that hits upstream is halfass and improperly integrated

 

Do you have some link to this discussion? It would be interesting to see the full arguments to judge whether they are right or whether it is NIH-syndrome.

----------

## NTU

https://forums.grsecurity.net/viewtopic.php?f=7&t=3367

https://forums.grsecurity.net/viewtopic.php?f=7&t=4476

He screams "cargo cult" at me too over IRC for splitting up the patch, must be his favorite word. Regardless, I'll be "copy+pasting" stuff too because a 9MB kernel patch blob is not how you do kernel development, unless you want to make things difficult for every other person outside your little circle of friends.

 *Quote:*   

> spender: we don't internally have things split out, we're not pulling a redhat patch on people

 

yet at the same time, they send me this: https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar and I think that's why they're so violent whenever I talk to them, they don't want the development process to be open, and after reading this, it doesn't surprise me:

https://grsecurity.net/announce.php

I am perceived as a threat for opening up the curtain, and they've already had people in the past that screw them over. Screwing them over isn't even the right way to put it, people did things with their source code, that they released with their own free-will, by choice, for no cost, but because they didn't copy and paste things and use their code their way, and do everything on their terms, they got mad, just as they're mad at me for forking their project the same way the companies did. Guys, this is an OPEN SOURCE project, getting mad at someone for sharing and distributing work that you have done under a public license, especially where the license says "This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation" is silly. As an RTAI developer, if someone forks RTAI on top of my work, re-writes everything and uses ancient code, as unsupported as it is (by anyone) regardless of how unstable or how it was "implemented incorrectly" I really don't care. I'm not claiming that the code from grsecurity is my own code that I wrote, and neither are the kernel developers, spender himself even helped the kernel devs by reporting an eBPF vulnerability to upstream:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=60a3b2253c413cf601783b070507d7dd6620c954

which I assume was taken or at least based off of code from his own project:

 *Quote:*   

> grsecurity was unaffected by this vulnerability.

 

yet bashes them (and me) and calls them a cargo cult. If I wanted to harden the kernel and make sure it gets done right, I'd send a broken up patchset of the project, documenting a lot of the changes and tracking the development process for others, working closely with the mainline developers and actively work on getting things merged in, so a wide range of Linux users (distributions who base their kernels off of kernel.org, users who use kernel.org directly, etc) can all be running the same source code. You can't expect to throw patch blobs out there and either expect it to get merged into mainline AS-IS, nor expect anybody to NOT break it up and merge it in piece by piece, at least I wouldn't, but that's just me. I especially wouldn't go around insulting everyone who modifies my open source project or using it how they see fit, even if it's used in a way I wouldn't. If people want to print out pages of my source code and flush them down a toilet and post a video of it on YouTube, who cares, the GPL doesn't say you can't do that.

----------

## mv

Thanks for the interesting links.

I think technically, spender has some points concerning KASLR. But obviously his big negative reaction on the whole kernel security project and your efforts are due to the fact that he wants to make a living with grsecurity. Perhaps he wouldn't even make his patches open source if he would not have been forced to (for technical reasons and perhaps by GPL).

----------

