kernel recompilation for better hardening

[Patrick]

@madaidan

I don’t get any prompts. Are you sure the config is at .config in the kernel source directory?

Yes, I am sure.

diff usr/share/hardened-vm-kernel/kernel-config ~/kernel/linux-source-4.19/.config ; echo $?

0

@madaidan

We can just copy/paste all that into our package. So users will just need to install hardened-vm-kernel and it will handle everything rather than needing to use wrappers or other things.

I don’t know if that is possible without using a package. For example to trigger DKMS, a new kernel package needs to be installed. It may be possible to reinvent all of this (call DKMS ourselfes) but the bigger the hack, the more likely it will have bugs.

question | with a package | without a package
What kernel version is installed? | Check kernel package version. | ?
How to remove that kernel? | apt purge… | ?

By not using a package many things get messy / lots of code duplication / bugs.

[madaidan]

@Patrick

Yes, I am sure.

I can’t reproduce this. Exactly which of the config options does it prompt you about? Is it all of the ones you said or where some automatically selected?

[Patrick_mobile]

@Patrick

Preemption Model 1. No Forced Preemption (Server) (PREEMPT_NONE) > 2. Voluntary Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY) 3. Preemptible Kernel (Low-Latency Desktop) (PREEMPT__LL) (NEW) 4. Preemptible Kernel (Basic RT) (PREEMPT_RTB) (NEW) 5. Fully Preemptible Kernel (RT) (PREEMPT_RT_FULL) (NEW) choice[1-5?]:

Just one question. Just exactly that. That’s it.
Deleted working folder? That state. That might make the difference.

[madaidan]

That’s weird. CONFIG_PREEMPT_VOLUNTARY is already enabled https://github.com/Whonix/hardened-vm-kernel/blob/master/usr/share/hardened-vm-kernel/kernel-config#L89

Same as the default Debian config.

[madaidan]

@Patrick_mobile

Also don’t use kernel signing / module signing during build?

I think we should sign all modules during build. After the build, we can sign lkrg, vbox guest additions etc. with scripts/sign-file, then we can destroy the private key with shred -zu in certs/ and enforce only signed module loading. This way, only signed modules can load, vbox won’t break and we don’t need to worry about a private key.

[Patrick_mobile]

Signing yes. If you can create that code to do singing, please turn on. Otherwise, meanwhile please turn off.

This also needs to integrated with DKMS.

Since the essence of DKMS is a single contained bash script, we could safely ship a newer version which supports module signing. See: enforce kernel module software signature verification [module signing] / disallow kernel module loading by default - #53 by Patrick

But even while the newer version of DKMS supports module singing, modules such as virtualbox do not make use of it. Automated module signing during kernel upgrade and module upgrade is still a non-trivial challenge.

When modules are upgraded, these need to be recompiled. This happens automatic by DKMS (but not yet with module signing). Therefore we cannot delete the signing key. But we could restrict signing key access with appaprmor-profile-everything.

[Patrick]

@madaidan

Disable debugfs

That is about /sys/kernel/debug folder? Perhaps better to restrict that through security-misc (permission hardening) and/or apparmor-profile-everything? Why? Maybe same as this very post: kernel recompilation for better hardening - #139 by Patrick

[Patrick]

@madaidan

That’s weird. CONFIG_PREEMPT_VOLUNTARY is already enabled https://github.com/Whonix/hardened-vm-kernel/blob/master/usr/share/hardened-vm-kernel/kernel-config#L89

Same as the default Debian config.

Added CI support in git master.

• hardened-kernel/.travis.yml at master · Kicksecure/hardened-kernel · GitHub
• https://github.com/Whonix/hardened-vm-kernel/blob/master/usr/share/hardened-vm-kernel/ci_test
• https://github.com/Whonix/hardened-vm-kernel/blob/master/usr/share/hardened-vm-kernel/build

But Travis CI is Ubuntu based. Not sure it is worth the effort making the CI build compatible with Ubuntu. Did run into some issues due to version differences (Linux 4.15 vs 4.19) but now fixed. I don’t know if there is a Debian buster based CI. Inquired just now:

[question] Can this project be used by upstreams? · Issue #62 · lamby/travis.debian.net · GitHub

Otherwise I’d be happy to use any other CI service.

https://travis-ci.com/Whonix/hardened-vm-kernel

The current build hangs.

https://travis-ci.com/Whonix/hardened-vm-kernel/builds/141763417

But this is not a “perfect proof” since running on Ubuntu with older kernel version.

[Patrick]

The differences interactive vs non-interactive could be a result of different installed packages / programs on the build machine.

Fixed this on my local machine.

fix non-interactive build issue

Please review that change. Please check best settings for prempt on everything.

CONFIG_HAVE_PREEMPT_LAZY=y is getting enabled either way by running make deb-pkg. Even if set to

# CONFIG_HAVE_PREEMPT_LAZY is not set

Or

CONFIG_HAVE_PREEMPT_LAZY=n

Please compare .config prior make deb-pkg with .config after make deb-pkg. It changes. And that I find very unusual, weird (not implying malicious, just saying to not have this misinterpreted / misquoted by third parties).

[Patrick]

Latest CI build https://travis-ci.com/Whonix/hardened-vm-kernel/builds/141767669 hangs at Cross-compiler tool prefix (CROSS_COMPILE) [] (NEW). Not sure it’s worth fixing Ubuntu based CI? Maybe time to revisit Dev/Continuous Integration - Whonix or look if there are new CI services now.

[madaidan]

@Patrick

That is about /sys/kernel/debug folder? Perhaps better to restrict that through security-misc (permission hardening) and/or apparmor-profile-everything? Why? Maybe same as this very post: kernel recompilation for better hardening

/sys/kernel/debug/ is the usual mount point for it and it’s already restricted to root in Debian by default so we can’t do any permission hardening with it in security-misc.

We can’t just restrict this with apparmor-profile-everything. debugfs doesn’t have to be at /sys/kernel/debug/. An attacker can mount it anywhere. For example, run

mount -t debugfs none /mnt

Now there is a debugfs mounted at /mnt. If apparmor-profile-everything denied access to /sys/kernel/debug/, it will do nothing to stop the attacker from just accessing this new mount at /mnt.

[madaidan]

@Patrick

Please compare .config prior make deb-pkg with .config after make deb-pkg . It changes. And that I find very unusual, weird (not implying malicious, just saying to not have this misinterpreted / misquoted by third parties).

I’m not seeing anything except the header change.

user@host:~/kernel/linux-source-4.19$ diff -u ../config .config
--- ../config
+++ .config
@@ -1,6 +1,5 @@
 #
-# Whonix custom kernel configuration
-# Optimized for virtual machines and security
+# Automatically generated file; DO NOT EDIT.
 # Linux/x86 4.19.67 Kernel Configuration
 #
 
user@host:~/kernel/linux-source-4.19$

[Patrick_mobile]

apparmor-profile-everything is going to restrict mount anyhow since that command can be abused for many very bad things.

[madaidan]

@madaidan

This kernel won’t be able to be used on hosts. Otherwise we’d need to enable all hardware config options which would drastically increase the time needed to compile and add attack surface.

Unless, during the install we find out what hardware the user uses, select config options based on that and compile the kernel although this can easily go very wrong.

[Patrick_mobile]

Better to rename from hardened-vm-kernel to hardened-kernel? Reason is the compile script and install hacks might be shared. Ideally for host kernel we’d offer precompiled but with a drop-in config snippet we’ll let the user opt-in for local self-compilation. Using all the same code but just some variables change depending on VM or host.

[madaidan]

@Patrick_mobile

Better to rename from hardened-vm-kernel to hardened-kernel?

Sure if we do decide to try and make a host kernel.

[Patrick_mobile]

Awesome. Will rename now as later package rename and migration is a nontrivial, error prone process for users who upgrade.

[Patrick]

Patrick_mobile via Whonix Forum:

Awesome. Will rename now as later package rename and migration is a nontrivial, error prone process for users who upgrade.

Initial packaging is done:

GitHub - Kicksecure/hardened-kernel: Hardened kernel configuration optimized...

[Patrick]

madaidan via Whonix Forum:

Should CONFIG_PROC_PAGE_MONITOR be disabled?

linux/fs/proc/Kconfig at master · torvalds/linux · GitHub

Various /proc files exist to monitor process memory utilization:
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.

It was called “brain-dead” and a security risk by grsecurty.

It was also used in exploiting rowhammer to gain kernel privileges.

Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges

Better disable read/write access with apparmor-profile-everything instead?

[madaidan]

@Patrick

Better disable read/write access with apparmor-profile-everything instead?

It’s just going to add compile time then.