grapheneos / linux-hardened Goto Github PK

Ideally, out-of-line metadata like bitmaps would be used. However, progress can be made without any drastic changes particularly when canaries are enabled. It would be nice to have fast range-checking code, similar to the existing debug code but likely without the expensive % checking alignment or at least it should be micro-optimized. It also needs to check in more places than the debug code to have the full intended security value.

Ideally this would use a keyed hash, but SipHash is likely too slow. The random ^ canary_address technique doesn't even make each one unique on little endian architectures due to the leading zero.

I get kernel panic immediately after I resume from suspend with 4.11.1.a. Previous versions didn't have this issue. Vanillia 4.11.1 works ok. Due to nature of this bug I don't have any logs.

4.12 kernel builds successfully with custom .config. Patched against 4.12a, the same build fails with...

In file included from ./include/linux/elf.h:4:0,          
                 from ./include/linux/module.h:15,        
                 from fs/binfmt_elf.c:12:                 
fs/binfmt_elf.c: In function 'randomize_stack_top':       
./arch/x86/include/asm/elf.h:326:56: error: 'mmap_rnd_compat_bits' undeclared (first use in this function); did you mean 'mmap_rnd_bits'?
 #define __STACK_RND_MASK(is32bit) ((is32bit) ? (1UL << mmap_rnd_compat_bits) - 1 : (1UL << mmap_rnd_bits) - 1)     
                                                        ^
./arch/x86/include/asm/elf.h:327:24: note: in expansion of macro '__STACK_RND_MASK'                                 
 #define STACK_RND_MASK __STACK_RND_MASK(mmap_is_ia32())  
                        ^~~~~~~~~~~~~~~~
fs/binfmt_elf.c:672:22: note: in expansion of macro 'STACK_RND_MASK'                                                
   random_variable &= STACK_RND_MASK;                     
                      ^~~~~~~~~~~~~~
./arch/x86/include/asm/elf.h:326:56: note: each undeclared identifier is reported only once for each function it appears in
 #define __STACK_RND_MASK(is32bit) ((is32bit) ? (1UL << mmap_rnd_compat_bits) - 1 : (1UL << mmap_rnd_bits) - 1)     
                                                        ^
./arch/x86/include/asm/elf.h:327:24: note: in expansion of macro '__STACK_RND_MASK'                                 
 #define STACK_RND_MASK __STACK_RND_MASK(mmap_is_ia32())  
                        ^~~~~~~~~~~~~~~~
fs/binfmt_elf.c:672:22: note: in expansion of macro 'STACK_RND_MASK'                                                
   random_variable &= STACK_RND_MASK;                     
                      ^~~~~~~~~~~~~~
make[1]: *** [scripts/Makefile.build:302: fs/binfmt_elf.o] Error 1                                                  
make[1]: *** Waiting for unfinished jobs....              
make: *** [Makefile:1019: fs] Error 2                     
==> ERROR: A failure occurred in build().   

This is a very low priority for linux-hardened since SELinux can be used to provide the same functionality and more.

Only extended attribute exceptions need to be supported and it's probably a good idea to use a new one to avoid conflicts with how PaX uses user.pax.flags in the future.

Could be done by moving the SSP guard value to a reserved register to make it faster and teaching the compiler to XOR the return address into the canary like https://gist.github.com/thestinger/b8502a881d871fbc75d91bc00576157b (which is only complete for x86_64 as we don't want frame pointers enabled but it currently depends on them for arm64).

This is in-progress as part of KSPP already. It would make sense to do some of this work here since they took an opt-in approach instead of opt-out. However, it's probably a good idea to focus on other things and keep an eye on it to avoid duplicating work.

At the moment I use hardened Gentoo with a 4.9. grsec kernel. Because this kernel is discontinued, I consider to use your kernel instead.

The "Kernel-Info" about emutamp says:

This means more or less that without Emutramp not even the package-manager works. Because of this I am wondering why emutramp is an "out of scope feature (legacy)"

PS: Gentoo's site (https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart) says the following about Emutramp:

... do not turn on or off some feature without knowing what you are doing. This is particularly true for EMUTRAMP (Emulate trampolines) which is turned on by default, and turning it off can break python and therefore your system! The reason is that python and libffi write code on the fly, either by RWX mmap-ings which PaX's MPROTECT will kill, or by falling back on trying to write little code snippets to files which other features in Grsecurity will kill, like Trused Path Execution. (See bug #484472.) In Gentoo, we've opted to patch python and libffi to use trampolines that can be safely handled by emulation in a PaX kernel. (See bug #329499.) We then PaX mark the python executable with -E to enable emulation of trampolines. Without EMUTRAMP on in the kernel, python will fail in trying to generate its RWX mmap-ings and die every time. (As a temporary workaround if you get into this situation, you can disable MPROTECT on python with paxctl-ng -m and then restore the original markings once you have booted back into a PaX kernel with EMUTRAMP.)

This will also improve arg/env randomization. As part of this, the mmap base will need to be properly offset to avoid problems.

Hi,

The pentesters use the TCP timestamp response for fingerprinted based on the behavior and to find the remote host's uptime.

I suggest you change the default value (which should slightly increase the performance).

tcp_timestamps_secure.txt

This is a simple alternative to Brad's "random_timestamp.diff" patch.

Thanks.

This is in-progress as part of KSPP already so there's no need for it to happen here.

The bounds and object-size sanitizers in the debugging mode are useful for moving code towards compatibility with more complete bounds checking along with being decent security features in their own right via the trapping mode. Coverage isn't great but it's decent enough to be useful and the performance cost is only going to get higher with more complete implementations even with substantial optimization improvements.

It would be useful to figure out how far away kernel code is from being able to use these in production. Targeted usage for core kernel code that's used everywhere can make this realistic. These features can be enabled on a case-by-case basis which is not only useful for compatibility but also performance, since performance-critical areas for a workload can be excluded if necessary on a subsystem / module, file or even function basis via no_sanitize.

Hello,

are there any instructions how to install your patch set onto a "vanilla-kernel"? Is there a version mapping, e. g. patchset 4.12.9 belongs to the vanilla-kernel 4.12.9? (I am on gentoo hardened and seeking for a new hardened kernel)

Additionally, can you explain briefly the differences between your efforts and "https://github.com/minipli/linux-unofficial_grsec"?

Thanks in advance!

This is in-progress as part of KSPP already so there's no need for it to happen here.

Ubuntu 17.04 does not boot when applying either the 4.11.2.a or the 4.11.2.b patch and building a 4.11.2 kernel. Boot seems to stop just after "loading initramfs". Please let me know what I can do to provide additional details. Note: I am yet to try a vanilla 4.11.2 kernel.

I have a btrfs compressed root volume. When I try to boot it on the hardened kernel, it panics:

Kernal panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Using version 4.11.e on ArchLinux; could be a 4.11 bug upstream now that I think of it.

Will work on getting more info, end of trace (apologies, I need to get a better test environment, it's on a vps):

STRUCTLEAK is extremely conservative and only does function-level structs with __user data inside them. It would be nice to have more aggressive heuristics. The most aggressive would simply be zeroing all locals including those in inner blocks by default and relying on optimization to remove it when not required, but there are a lot of options to explore to reduce the cost.

CopperheadOS has the most aggressive take implemented for Clang as -fsanitize=local-init.

PaXtest - Copyright(c) 2003-2016 by Peter Busser [email protected] and Brad Spengler [email protected]
Released under the GNU Public Licence version 2 or later

Mode: 1
Blackhat
Kernel:
Linux 4.10.16-gnu-1-hardened SMP x86_64 GNU/Linux

Test results:
/usr/bin/paxtest: string 69: /usr/lib/paxtest/gcc: no such file

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable stack (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments : Vulnerable
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)
Heap randomization test (PIE) :

p.s.

you call this "hardened kernel" ;)

I feel like a hardened version of longterm kernel releases would be very useful, as it then allows easy usage on systems such as Debian and Ubuntu LTS with conservative update schedules. Hardened kernels would be very useful on public servers, which tend to run conservative distros. Besides, longterm releases like 4.9.x and 4.4.x change slowly and publicly available grsec patches, so it'll probably be easier to port various features compared to doing the same thing on the quickly moving target that is the stable version.

This is in-progress as part of KSPP already so there's no need for it to happen here.

This is in-progress as part of KSPP already so there's no need for it to happen here.

For example, PaX MPROTECT prevents relro sections from becoming writable again.

Similar to #34 (see explanation there) but for -fsanitize=integer and subsets of it. Unsigned integer overflow is well-defined but still quite suspicious and intended overflows would ideally be marked. Some subsystems might buy into doing this and using it for debugging and fuzzing. Signed integer overflow is usually undefined, but the kernel makes it well-defined via -fno-strict-overflow so it's almost just as hard to push for that. Marking the intended overflows is not that much to ask for though and it can be done in a way that's pretty. The no_sanitize attribute exists for doing it at the function level but ideally they'd be marked on a case-by-case basis with the _builtin*_overflow intrinsics via wrappers making them sane to use for this.

This will provide a lot more coverage than SIZE_OVERFLOW and uncover a lot more issues, so it's a lot more work and should be targeted in scope.

Used to be on linux-grsec.

Hi,

The linux kernel symbols /proc/kallsyms is regularly used in exploits. Example:
nelson, linux-rds-exploit, cheddar_bay, therebel, wunderbar_emporium, robert-you-suck, linux-rds-exploit etc...

Although the CONFIG_KALLSYMS option can be disabled, this is very rare in distributions.
Changing the access rights would therefore limit or complicate certain exploits that uses kernel symbols.

restrict-kallsyms.patch

Thanks

Not really an issue, more a request for clarification in the docs:

Is denyusb implemented with a sysctl like the grsec implementation was, if so what is the flag?

The cpu_init x86_configure_nx call seems incompatible with this, and there are changes in grsecurity removing that code. It shouldn't need pax_open_kernel/pax_close_kernel as long as the same path is taken.