This option enables normal printk support. Removing it eliminates most
of the message strings from the kernel image and makes the kernel more
or less silent. As this makes it very difficult to diagnose system
problems, saying N here is strongly discouraged.
We don’t have any real data. Can only speculate. A google search for the name of the wifi device plus “linux forum” brings up lots of search results. Search terms:
“RTL8192U” linux forum
“RTL8188EU” linux forum
“RTL8712U” linux forum
“RTL8723BS” linux forum
“RTL8192E” linux forum
People are using these devices. Therefore I think it’s better to keep these modules for wifi devices.
That also shows that the approach of 1 kernel config for the host (and another 1 for all VMs) covering it all cannot be perfect. Either hardware support becomes more broken than Debian default (which is already not working for many people) or it’s not a minimal amount of kernel modules.
Maybe the Clip OS approach of generating the kernel config on the user’s system (?) would bring more optional results. But probably also at higher development and maintenance efforts. And even then we’d have to decide on a default which gets used when users boot the system for the very first time.
For hosts: Maybe kernel re-compilation could be done at first boot of system or during installation to be tailored for the system. But all of this is far fetched in future.
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.
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.
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.
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?
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.
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.
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.
HDLC was the inspiration for the IEEE 802.2LLC 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.
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).
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.
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.
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.