That’d be no different than patching out dmesg AFAIK. I guess the only advantage with patching it out is we can add a sysctl for superroot to change it at runtime.
That won’t prevent root from using dmesg.
It only seems to be required for installation. As long as grub isn’t installed while using hardened-kernel it should be alright?
There appears to be 2 ways to modify EFI variables. CONFIG_EFI_VARS and CONFIG_EFIVAR_FS.
linux/Kconfig at master · torvalds/linux · GitHub
From the kconfig, it looks like CONFIG_EFI_VARS is legacy.
madaidan via Whonix Forum:
It only seems to be required for installation.
We need reasonable certainties. Otherwise we’d produce stuff which is
later going to be unusable. EFI booting is hard on its own. Adding
disabling of kernel EFI config to the mix makes it even harder.
As long as grub isn’t installed while using hardened-kernel it should
be alright?
How would grub not be installed? It’s a default package in Debian,
Whonix, Kicksecure. You probably mean only required during
grub-install? Well, at some point one needs to run grub-install. For
example when booting a Whonix or Kicksecure Live ISO (to be created in
future) it would hopefully boot a hardened kernel. When then running the
installer, grub-install needs to function. Otherwise at that point
there would be a hard to debug and fix issue.
I see a lot other stuff more important before a hardened kernel can take
off or details such as EFI variables kernel config become a question.
- packaging ⚓ T960 hardened kernel Debian packaging and APT integration - hkapt
- automated builds and tests of kernel (boot in VM and also on bare
metal, run tests, aka automated test suite, for both BIOS and EFI boot,
such a installation, upgrades, whatnot) - if that was sorted, if the
testing process was automated and robust, if we knew if changes break
things, it would be a lot easier to make more changes.
I’d say better get it widely deployed first and then do fine tuning.
Otherwise if we ship something that doesn’t work for most users we end
up keeping using the standard kernel.
2 Likes
madaidan via Whonix Forum:
That’d be no different than patching out dmesg AFAIK. I guess the only advantage with patching it out is we can add a sysctl for superroot to change it at runtime.
I see. I don’t remember discussing patching out dmesg though.
That won’t prevent root from using
dmesg.
I see. Would it suffice to prohibit executing dmesg using
apparmor-profile-everything for all users except superroot?
1 Like
That doesn’t stop the attacker from using their own program. They can copy/paste the dmesg source code.
1 Like
1 Like
1 Like
I see. No log access for root at all then as a development goal?
Could capabilities be used instead to prevent access to dmesg for root?
Worst case scenario I see here that our initial version of hardened kernel won’t even boot after it gets widely deployed - without easy debug - while the debug kernel might actually boot.
1 Like
We already blacklist the module in security-misc anyway. If it was needed for something, we’d know by now.
Yes. The kernel logs can be very useful to an attacker hence why the dmesg_restrict sysctl exists to restrict it to root. There have been many cases of kernel pointer leaks, bypassing kptr_restrict for example.
Yes. dmesg_restrict restricts it to CAP_SYSLOG so we can probably remove that capability but CAP_SYSLOG is used for a lot of other functionality so it might break things.
If we do decide to extend the dmesg_restrict sysctl, the user can just use superroot and disable the restrictions.
2 Likes
Instead, we can set CONFIG_CMDLINE="slub_debug=FZ page_poison=0" and then enable CONFIG_CMDLINE_OVERRIDE so these cannot be overridden by the bootloader.
Although, CONFIG_CMDLINE_OVERRIDE seems to disallow all bootloader arguments.
1 Like
Nothing we would care about:
HDLC was the inspiration for the IEEE 802.2 LLC protocol, and it is the basis for the framing mechanism used with the PPP on synchronous lines, as used by many servers to connect to a WAN, most commonly the Internet.
In other words, it was an inspiration for more widely used protocols and after skimming a very long page about it, there was no mention of a real world use for it.
2 Likes
Same comment as kernel recompilation for better hardening - #358 by Patrick applies?
What’ the threat model for preventing the bootloader from modifying kernel commandline?
Ticket grub boot password would be a user freedom preserving solution for bootloader security that allows for customization / debugging in a safe way.
1 Like
No. I’m not saying to check /proc/cmdline in security-misc. This would set slub_debug=FZ and page_poison=0 by default in the kernel and make sure security-misc can’t override it.
It’s not a security issue. It’s to prevent security-misc from overriding the parameters. If we set CONFIG_CMDLINE="slub_debug=FZ" and prevent it from being overridden, then security-misc setting slub_debug=FZP will have no effect (as it can’t be overridden).
1 Like
Currently, we’re using GCC to compile the kernel but I think we should consider switching to Clang.
If we switch to Clang, we’d lose GCC plugins (RANDSTRUCT, STRUCTLEAK, LATENT_ENTROPY and in the future, STACKLEAK) but we’d gain CONFIG_INIT_STACK_ALL (essentially a stronger alternative to STRUCTLEAK) and CONFIG_LOCAL_INIT (part of linux-hardened).
LATENT_ENTROPY isn’t that important so the only big losses would be RANDSTRUCT and STACKLEAK.
Clang RANDSTRUCT is being worked on though ⚙ D59254 [RFC] Implementation of Clang randstruct
There is also work on implementing Clang Control-Flow Integrity (CFI) and ShadowCallStack (SCS). Currently this is only available on Google Pixels but the KSPP is working on upstreaming it.
Google seems to value CFI/SCS over RANDSTRUCT/STACKLEAK Android Developers Blog: Control Flow Integrity in the Android kernel
This isn’t as big of an issue now as Clang’s benefits aren’t as major in our kernel version but in the future, once CFI/SCS are a thing, we should probably switch.
1 Like
Yes, Clang can be considered. Though, I wouldn’t know how to make the
change and also the packaging is an issue still even with gcc.
LATENT_ENTROPY isn’t that important so the only big losses would be RANDSTRUCT and STACKLEAK.
OK. I guess doesn’t hurt to keep the kernel command line in case it gets
added at some point in future.
1 Like
madaidan via Whonix Forum:
No. I’m not saying to check
/proc/cmdlinein security-misc. This would setslub_debug=FZandpage_poison=0by default in the kernel and make sure security-misc can’t override it.
Other kernel parameters could still be changed?
If yes this case, OK. It’s messy, but if there’s no better solution
non-debug kernel could do it. Debug kernel shouldn’t do that?
This needs a good technical explanation what issue we’re working around
with this so this can still be understood some years from now by others
(including me).
What makes this also messy is the fact then kernel parameters aren’t
only defined in /etc/default/grub.d and/or at boot time using grub edit
function but also hardcoded and forced in kernel config which is defined
elsewhere. Perhaps drop a note in /etc/default/grub.d, adding a kernel
boot parameter that is ignored by the kernel but as a hint for
users/reviewers (and note for developers) that there are “extra” kernel
parameters defined elsewhere?
1 Like
Merged.
1 Like
madaidan via Whonix Forum:
We already blacklist the module in security-misc anyway. If it was needed for something, we’d know by now.
OK.
(I am not sure we have that many security-misc on hosts users yet.)
Yes. The kernel logs can be very useful to an attacker hence why the dmesg_restrict sysctl exists to restrict it to root. There have been many cases of kernel pointer leaks, bypassing kptr_restrict for example.
OK. Please add that rationale to the wiki.
Yes. dmesg_restrict restricts it to CAP_SYSLOG so we can probably remove that capability but CAP_SYSLOG is used for a lot of other functionality so it might break things.
If we do decide to extend the dmesg_restrict sysctl, the user can just use superroot and disable the restrictions.
Kernel patches need to go through kernel.org upstream or any other
appropriate upstream (hardened-linux) that we can use.
Otherwise I am unfortunately convinced that dmesg (replacements) might
give access to kernel pointer leaks which could then be abused.
Though, no dmesg also means we couldn’t know if LKRG kills a process or
panics the kernel. Either legitimate or through a false positive. This
is because LKRG communicates through dmesg. I hope we’re not building
something here which later becomes unusable due to bugs (such as random
poweroff or kernel panic) which nobody can debug since no logs.
2 Likes