Done.
Btw if you edit with account I could upgrade that.
1 Like
That seems rather inflexible.
1 Like
I added docs hardened-kernel
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.
https://github.com/clipos/src_external_linux/commit/3e5f9114fc2f70f6d2ae5d10db10869e0564eb03
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-grubwould 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-grubwould not set these options. - When booting a hardened kernel,
update-grubwould 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
⚓ T960 hardened kernel Debian packaging and APT integration - hkapt 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 Features/Virtio RNG - Fedora Project Wiki
2 Likes
CLIP OS recently disabled CONFIG_STAGING.
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.
linux/drivers/staging/Kconfig at master · torvalds/linux · GitHub
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
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.
Entropy, Randomness, /dev/random vs /dev/urandom, Entropy Sources, Entropy Gathering Daemons, RDRAND
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