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.

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.

(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.

Further info:
- https://linuxacademy.com/howtoguides/posts/show/topic/19700-linux-security-and-server-hardening-part1
- https://www.cyberciti.biz/faq/linux-kernel-etcsysctl-conf-security-hardening/

(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?

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...

(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...

I will take care of this.

https://lists.ipfire.org/pipermail/development/2018-August/004712.html

Why has this moved from BZ to the list?

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)

Any commits that reference these changes?

I suppose this is now all done and relased.