[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

kernel recompilation for better hardening

Done.

Btw if you edit with account I could upgrade that.

1 Like

That seems rather inflexible.

1 Like

I added docs https://www.whonix.org/w/index.php?title=Hardened-kernel&stable=0

Has an overview, list of options we disable/enable, linux-hardened enhancements and options we don’t use.

2 Likes

It turns out, CLIP OS doesn’t actually use the STACKLEAK patch anymore. It dropped it a while ago.

In this new major kernel version, we drop ‘feature/stackleak’ which was extending upstream’s STACKLEAK with alloca() calls checking (7a94313 - “stackleak: reintroduce checking of alloca() calls”). The rationale described at that time was:

  • act as a failsafe, for instance if VLAs were to be inadvertently reintroduced: this should not happen now that -Wvla is used;
  • protect out-of-tree code: likewise, plus we control such code.
1 Like

We can use CONFIG_CMDLINE for this. Set CONFIG_CMDLINE="hardened-kernel" or similar then grep /proc/cmdline in security-misc.

1 Like

You mean using CONFIG_CMDLINE="hardened-kernel" to detect that a hardened kernel is running and therefore setting different grub command line options? That might not work well. Could be a similar issue to this.

  • When Whonix is build in chroot, this will not be set. Hence, update-grub would not set these options.
  • Similar when someone is still booting a standard kernel and wants to try out the hardened kernel. At kernel installation time, still the standard kernel is running. Hence, update-grub would not set these options.
  • When booting a hardened kernel, update-grub would set these kernel command for co-installed standard kernels too.
1 Like

Will my lockdown patches ever be merged?

They’re really important. Without them, root can easily escalate to kernel mode, making “untrusted root” useless.

They’re almost identical to the upstream patches (excluding a different variable name and lockdown-kconfig.patch). The official lockdown patches won’t be coming to LTS anytime soon and there’s no other project I know of I can submit these to.

I also added a boot parameter to easily enable/disable this (lockdown=on/lockdown=off) although it’s not tested yet.

1 Like

Tested it. It works.

1 Like

I think the issue with CONFIG_STATIC_USERMODEHELPER is that it requires userspace support which barely anyone implements.

We’d need to create a single, read-only binary (the default location is /sbin/usermode-helper) that can filter all call_usermodehelper() calls. I don’t know how this would be done and I can’t find any examples. The only distro I can find that enables this option is CLIP OS but they don’t use a static usermode helper binary and instead disable it altogether (by setting CONFIG_STATIC_USERMODEHELPER_PATH=""). Doing this on Debian though still breaks boot.

Without this, attackers can trick the kernel into executing their own code to bypass SMAP/SMEP.

Alternatively, grsecurity had a (weaker) feature that whitelisted system directories (it didn’t have a config option). We could implement this then deny writing to those directories with apparmor-profile-everything.

1 Like

madaidan via Whonix Forum:

Will my lockdown patches ever be merged?

I can’t review them. And I haven’t found any other reviewer yet either.

If no upstream wants to take them (in that kernel version), then I can’t
review these patches either.

They’re almost identical to the upstream patches (excluding a different variable name and lockdown-kconfig.patch). The official lockdown patches won’t be coming to LTS anytime soon and there’s no other project I know of I can submit these to.

Similar or even 100% same as upstream patches. As said before backport
something, also the context on where these patches are plugged in have
to be understood which I don’t understand either.

They’re really important. Without them, root can easily escalate to
kernel mode, making “untrusted root” useless.

I’d rather re-consider a different kernel version in this case.

These kernel patches are imo also rushed ahead a lot. Solving
https://phabricator.whonix.org/T960 isn’t trivial at all.

2 Likes

Should we compile more RNGs as built-in?

There are the following HWRNG options:

CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=m
CONFIG_HW_RANDOM_VIA=m
CONFIG_HW_RANDOM_VIRTIO=m

I think we should make CONFIG_HW_RANDOM_VIRTIO built-in for the VM kernel and the rest built-in for the host kernel.

There’s also another RNG module we might want to use, CONFIG_CRYPTO_ANSI_CPRNG, but I don’t know about that.

1 Like

No, because we chose to completely distrust hwrngs. I think we are better off stripping them out of the kernel.

2 Likes

We don’t. We only distrust them for initial entropy. Stripping them out entirely isn’t really a good idea.

Virtio RNG isn’t a real HWRNG anyway https://fedoraproject.org/wiki/Features/Virtio_RNG

2 Likes

CLIP OS recently disabled CONFIG_STAGING.

https://github.com/clipos/src_platform_config-linux-hardware/commit/ec648fd1e01a439919411e48e477172158d0ef79

From the docs:

Staging drivers are typically of lower quality and under heavy development. They are thus more likely to contain bugs, including security vulnerabilities, and should be avoided.

https://github.com/torvalds/linux/blob/master/drivers/staging/Kconfig

This option allows you to select a number of drivers that are not of the “normal” Linux kernel quality level. These drivers are placed here in order to get a wider audience to make use of them. Please note that these drivers are under heavy development, may or may not work, and may contain userspace interfaces that most likely will be changed in the near future.

2 Likes

https://review.clip-os.org/c/clipos/src_platform_config-linux-hardware/+/5191

1 Like

Kernel 5.5 will have an option to disable the iopl() and ioperm() syscalls.

3 Likes

Looks like a good candidate to disable. sys_rawio is one of those capabilities that I do not even like when it has to be there. As an example, when building app profiles with Apparmor, I always see if it can run with that one denied. I know it’s just one out of very many caps that could be potentially dangerous, but every bit helps.

2 Likes

It’s safe to use any source of entropy but not trust it / not credit it.

https://www.whonix.org/wiki/Dev/Entropy#Credit_Entropy

2 Likes

Good idea.

(Not suggested but just in case anyone would think that: Please don’t set any of these options to n (no). A better fallback is m just in case.)

1 Like

asked: https://github.com/smuellerDD/jitterentropy-library/issues/16#issuecomment-589606893

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]