I’ve ported this and will send it to linux-hardened. It denies all read-write mounts and writes to block devices once kernel.romount_protect=1 is set. It cannot be changed back during runtime.
We just need to figure out when to set this and how.
1 Like
2 Likes
From the results of GitHub - a13xp0p0v/kconfig-hardened-check: A tool for checking the security hardening options of the Linux kernel, the only things we can really improve now are (excluding things not in our kernel version, SLUB_DEBUG_ON as it doesn’t help, LOADPIN as we aren’t using it, USER_NS as linux-hardened fixes that issue and modules as we’re working on that):
option name | desired val | decision | reason | check result
=========================================================================================================================
CONFIG_STATIC_USERMODEHELPER | y | clipos | self_protection | FAIL: "is not set"
CONFIG_KALLSYMS | is not set | clipos | cut_attack_surface | FAIL: "y"
CONFIG_MAGIC_SYSRQ | is not set | clipos | cut_attack_surface | FAIL: "y"
CONFIG_BPF_JIT | is not set | my | cut_attack_surface | FAIL: "y"
CONFIG_STATIC_USERMODEHELPER would be very useful but this breaks boot for some unknown reason and leaves me with a black screen although we can use LKRG’s umh_lock instead if the issues with the firewall are ever fixed.
Disabling CONFIG_KALLSYMS isn’t that helpful since we set kptr_restrict but it would reduce attack surface.
Disabling CONFIG_MAGIC_SYSRQ isn’t that helpful either as we’re going to restrict SysRq.
The only really useful one is a static usermode helper.
2 Likes
Would be helpful to document this on the wiki so users running the hardening check script don’t come in here and ask "why is X not enabled in your kernel but done in ClipOS?
2 Likes
Anything here that anthraxx or ClipOS can readily pick up?
2 Likes
Dapper is just a forward port of grsec. I don’t think they’ve added any new features and I’m already combing over the original grsec patch anyway.
2 Likes
Yes I know. I was wondering if stuff like RAP can be easily ported forward and integrated by either of these projects because it hasn’t succumbed to bitrot yet.
2 Likes
Not easily. RAP is a very large feature. Porting it would be hard.
Besides, the full version was never publicly released, only a subset of its features were part of the public patch grsecurity
We should just wait until clang CFI is upstream https://outflux.net/slides/2020/lca/cfi.pdf
2 Likes
madaidan via Whonix Forum:
Merged.
1 Like
We can change CONFIG_CMDLINE (requires CONFIG_CMDLINE_BOOL=y) to default to our security-misc boot parameters although most are solved by the config anyway.
1 Like
@Patrick can you create hardened-kernel so I can add documentation? I don’t have permissions to create it.
1 Like
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