| View previous topic :: View next topic |
| Author |
Message |
NTU
Apprentice
Joined: 17 Jul 2015
Posts: 187
|
 Posted: Wed Oct 05, 2016 12:42 am Post subject: Hardened Gentoo with Vanilla kernel (4.8) |
 |
|
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:
| Code: | $ 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.
| Code: | $ 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:
| Code: | # 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.
| Code: | 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!  |
|
| Back to top |
|
 |
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21635
|
| Posted: Wed Oct 05, 2016 1:38 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Wed Oct 05, 2016 3:28 pm Post subject: |
|
|
Just add PAXMARKINS="none" to make.conf to disable all the pax markings.
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1) |
|
| Back to top |
|
|
NTU
Apprentice
Joined: 17 Jul 2015
Posts: 187
|
| Posted: Sat Oct 08, 2016 6:58 pm Post subject: |
|
|
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! |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Oct 09, 2016 5:14 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
NTU
Apprentice
Joined: 17 Jul 2015
Posts: 187
|
| Posted: Tue Oct 11, 2016 6:53 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Oct 12, 2016 8:07 pm Post subject: |
|
|
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). |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
