Bug 11659 - Implement Kernel Self Protection Settings
Summary: Implement Kernel Self Protection Settings
Status: CLOSED FIXED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all All
: Will affect all users Security
Assignee: Peter Müller
QA Contact:
URL:
Keywords: Security, Umbrella
Depends on:
Blocks: KERNEL414
  Show dependency treegraph
 
Reported: 2018-03-03 14:09 UTC by Peter Müller
Modified: 2018-10-15 13:45 UTC (History)
2 users (show)

See Also:


Attachments
attachment-18065-0.html (503 bytes, text/html)
2018-03-03 15:23 UTC, Michael Tremer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Müller 2018-03-03 14:09:24 UTC
At http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings , there are various settings listed for making the Linux kernel more secure.

This is an umbrella bug to integrate them to the kernel version IPFire ships (Michael told me that most of the configure-values are set, but we need to go detailled through them).
Comment 1 Michael Tremer 2018-03-03 15:23:24 UTC
Created attachment 563 [details]
attachment-18065-0.html

As far as i remember we talked about you going through the list of settings and see where we differ. Please review the kernel configuration of 4.14.

I went through this a while ago and don’t recall that we were missing anything major with our current grsec kernel.
Comment 2 Peter Müller 2018-03-03 21:30:24 UTC
As far as I am concerned, the following CONFIG options in Kernel 4.14 (x86_64) differ to that listed at the website:

- CONFIG_IO_STRICT_DEVMEM
- CONFIG_DEBUG_CREDENTIALS
- CONFIG_DEBUG_NOTIFIERS
- CONFIG_DEBUG_SG
- CONFIG_BUG_ON_DATA_CORRUPTION
- CONFIG_SCHED_STACK_END_CHECK
- CONFIG_SECURITY_YAMA
- CONFIG_SLUB_DEBUG_ON
- CONFIG_PAGE_POISONING
- CONFIG_PAGE_POISONING_NO_SANITY
- CONFIG_PAGE_POISONING_ZERO
- CONFIG_PANIC_ON_OOPS (?)
- CONFIG_PANIC_TIMEOUT (?)
- CONFIG_MODULE_SIG
- CONFIG_MODULE_SIG_FORCE
- CONFIG_MODULE_SIG_ALL
- CONFIG_MODULE_SIG_SHA512
- CONFIG_MODULE_SIG_HASH
- CONFIG_MODULE_SIG_KEY
- CONFIG_DEFAULT_MMAP_MIN_ADDR (set to 4096, suggested 65536)

I am not an expert here, so some of them might be disabled in the IPFire version for a reason (especially those dealing with kernel module signing, however, I consider this feature being interesting).

The sysctl checks were omitted here, since I could not figure out where they are configured.
Comment 3 Michael Tremer 2018-03-16 15:04:34 UTC
(In reply to Peter Müller from comment #2)
> As far as I am concerned, the following CONFIG options in Kernel 4.14
> (x86_64) differ to that listed at the website:
> 
> - CONFIG_IO_STRICT_DEVMEM
> - CONFIG_DEBUG_CREDENTIALS
> - CONFIG_DEBUG_NOTIFIERS
> - CONFIG_DEBUG_SG
> - CONFIG_BUG_ON_DATA_CORRUPTION
> - CONFIG_SCHED_STACK_END_CHECK
> - CONFIG_SECURITY_YAMA
> - CONFIG_SLUB_DEBUG_ON
> - CONFIG_PAGE_POISONING
> - CONFIG_PAGE_POISONING_NO_SANITY
> - CONFIG_PAGE_POISONING_ZERO
> - CONFIG_PANIC_ON_OOPS (?)
> - CONFIG_PANIC_TIMEOUT (?)
> - CONFIG_MODULE_SIG
> - CONFIG_MODULE_SIG_FORCE
> - CONFIG_MODULE_SIG_ALL
> - CONFIG_MODULE_SIG_SHA512
> - CONFIG_MODULE_SIG_HASH
> - CONFIG_MODULE_SIG_KEY
> - CONFIG_DEFAULT_MMAP_MIN_ADDR (set to 4096, suggested 65536)
> 
> I am not an expert here, so some of them might be disabled in the IPFire
> version for a reason (especially those dealing with kernel module signing,
> however, I consider this feature being interesting).
> 
> The sysctl checks were omitted here, since I could not figure out where they
> are configured.

I have two comments here:

a) I think there is a risk in enabling BUG_ON_DATA_CORRUPTION and all the PANIC_* parameters because these make DoS attacks even easier. With a webserver within a farm of hundreds this might make sense and another system can take over, but in most cases there is no other firewall. As long as the system can recover from this data corruption, we should allow it to do that.

Drivers oops sometimes. It's not good, but there is no need to panic right away.

b) The signing makes releases very hard because we could not ship single modules any more and we build loads of modules out of tree. Please try this in IPFire 3 first since we build the kernel there in one piece and it is a good playground for this, I think.
Comment 5 Michael Tremer 2018-05-18 16:04:19 UTC
(In reply to Michael Tremer from comment #3)
> (In reply to Peter Müller from comment #2)
> > As far as I am concerned, the following CONFIG options in Kernel 4.14
> > (x86_64) differ to that listed at the website:
> > 
> > - CONFIG_IO_STRICT_DEVMEM
> > - CONFIG_DEBUG_CREDENTIALS
> > - CONFIG_DEBUG_NOTIFIERS
> > - CONFIG_DEBUG_SG
> > - CONFIG_BUG_ON_DATA_CORRUPTION

I completely disagree that this should be enabled. A kernel crashing away on a small oops is a denial-of-service attack vector.

> > - CONFIG_SCHED_STACK_END_CHECK

This is only switched on on i586 (non-PAE). Is there a reason or dependency?

> > - CONFIG_SECURITY_YAMA
> > - CONFIG_SLUB_DEBUG_ON

SLUB_DEBUG is y on x86 and should be disabled.

> > - CONFIG_PAGE_POISONING

Enabled on i586 and should potentially be enabled on all others as well when possible.

> > - CONFIG_PAGE_POISONING_NO_SANITY

Always unset.

> > - CONFIG_PAGE_POISONING_ZERO

Always set.

> > - CONFIG_PANIC_ON_OOPS (?)

Disabled and that is how it should be. See above.

> > - CONFIG_PANIC_TIMEOUT (?)

Is zero. Usually set on command line.

> > - CONFIG_MODULE_SIG
> > - CONFIG_MODULE_SIG_FORCE
> > - CONFIG_MODULE_SIG_ALL
> > - CONFIG_MODULE_SIG_SHA512
> > - CONFIG_MODULE_SIG_HASH
> > - CONFIG_MODULE_SIG_KEY

We are building external modules and we are shipping only parts of the kernel at times which does not allow us to sign any modules.

> > - CONFIG_DEFAULT_MMAP_MIN_ADDR (set to 4096, suggested 65536)

Is 64k now.

Arne, could you look into changing the ones suggested above?
Comment 6 Peter Müller 2018-06-10 10:10:52 UTC
Just as a foot note: Could we update kernel to 4.14.42 in Core Update 122? It features security fixes against Spectre.

@Michael: Thanks for feedback. I will have a look at these settings again and submit patches for next release, if you are okay with that. Leaves me some time to do pentesting...
Comment 7 Peter Müller 2018-06-10 10:12:41 UTC
(In reply to Peter Müller from comment #6)
> Just as a foot note: Could we update kernel to 4.14.42 in Core Update 122?
> It features security fixes against Spectre.
Forget it - just saw the 4.14.48 tag... :-\
> 
> @Michael: Thanks for feedback. I will have a look at these settings again
> and submit patches for next release, if you are okay with that. Leaves me
> some time to do pentesting...
Comment 8 Peter Müller 2018-08-06 22:22:12 UTC
I will take care of this.
Comment 10 Michael Tremer 2018-08-16 19:40:02 UTC
Why has this moved from BZ to the list?
Comment 11 Peter Müller 2018-09-23 11:06:52 UTC
After having spoken with Arne, this is the status quo:

Config switches to enable:
- CONFIG_DEBUG_WX (is disabled on AARCH64)
- CONFIG_SCHED_STACK_END_CHECK (is enabled on i586)
- CONFIG_HARDENED_USERCOPY (is disabled on AARCH64 and ARM)
- CONFIG_PAGE_POISONING (to be enabled on x86_64 only)
- CONFIG_PAGE_POISONING_NO_SANITY (is disabled on all architectures)
- CONFIG_PAGE_POISONING_ZERO (is enabled on i586 PAE only)
- CONFIG_FORTIFY_SOURCE (is disabled on AARCH64)
- CONFIG_INET_DIAG (is enabled on all architecture)


Further investigation needed:
- CONFIG_CC_STACKPROTECTOR_STRONG (is unset on i586 PAE in favour of CONFIG_CC_STACKPROTECTOR_REGULAR, causes crash while using VMs on PAE kernels, Arne tries to enable it anyway)
- CONFIG_SLUB_DEBUG (is disabled on AARCH64 and i586 PAE, strange, to be done)
- CONFIG_ACPI_CUSTOM_METHOD (is enabled on all except ARM and AARCH64, disable, cpugovenor problems?)
- CONFIG_BINFMT_MISC (is enabled on all architecture, build systems need this, but probably unused otherwise)

Config switches which cannot be activated:
- CONFIG_DEVMEM (due to virtualisation)
- CONFIG_IO_STRICT_DEVMEM (due to virtualisation)
- CONFIG_BUG_ON_DATA_CORRUPTION (introduces DoS attack vector)
- CONFIG_DEBUG_CREDENTIALS (dto.)
- CONFIG_DEBUG_NOTIFIERS (dto.)
- CONFIG_DEBUG_SG (dto.)
- CONFIG_SECURITY_YAMA (no audit wanted ???)

Compiling switches which cannot be activated:
- CONFIG_GCC_PLUGIN_RANDSTRUCT (will break modules)

Kernel boot parameters:
- slab_nomerge (to be enabled)
- page_poison=1 (will likely introduce performance impact, to be enabled?)

sysctl's which differ (I will take care of these):
- user.max_user_namespaces is 15345 (recommended: 0)
- kernel.kexec_load_disabled is not found (recommended: 1) -> TBD, patch
- kernel.yama.ptrace_scope is not found (recommended: 1)
- net.core.bpf_jit_harden is 0 (recommended: 2)
- kernel.unprivileged_bpf_disabled is not found (recommended: 1)
Comment 12 Michael Tremer 2018-09-23 15:17:53 UTC
Any commits that reference these changes?
Comment 13 Michael Tremer 2018-10-15 13:45:26 UTC
I suppose this is now all done and relased.