Should review generally which systemd target pulls services. Some services make much more sense (better security) when run during sysinit target before anything else that might get exploited later on (desktop environment, browser, web servers, etc.)
Quote Lennart Poettering (systemd developer) said in 2014
Sorry, but we simply don’t support hidepid= as it is implemented right now in the kernel. We need to be able to get meta data out of /proc for clients. journald needs that, polkit, does, our apis do that, there’s probably a lot more.
hidepid= is a bit naive there.
I’d actually like to support it better, but if we do that I figure we need some kernel changes first. instead of being a kernel-wide setting it should be a per-mount point setting, so that we can turn it on for some services, and turn it off for others, simply by passing different settings to the procfs in their respective mount namespaces.
Anyway, the way it stands now, we cannot support this. Sorry.
That quote is a bit old. Things may or may not be better by now.
During boot, the kernel logs are displayed on the console. As the kernel logs are meant to be restricted to root (kernel.dmesg_restrict=1), this should probably be disabled.
Setting kernel.printk=3 3 3 3 with sysctl configures it so only really important errors will be displayed.
Also whonixcheck needs lockdown wrt log viewing. Allows users to see log on systemd warning/error/cycle messages. Running whonixcheck should require sudo but as much as possible should run unprivileged.
I still see some logs after running that. Changing the kernel.printk sysctl hides more. I can still see some logs even with changing kernel.printk as it starts displaying logs before systemd-sysctl is executed. The only way around that would be setting kernel.printk in the initramfs, before systemd has started if it’s even possible.
During security-misc installation and/or a systemd service.
Looks global.
Logs can still be viewed with sudo dmesg. They were never available to unprivileged users in the first place as Debian sets kernel.dmesg_restrict=1 by default.
I considered verbose boot a usability feature. Better progress report during boot. Doesn’t look frozen. A lot users think it’s frozen and give up. Also good for debugging / see issues. Might have to reconsider / find alternative.
Under the enhanced threat model of hiding as much information from user as possible, user has no business reading most of whonixcheck output. But nontrivial change since whonixcheck also used as connectivity checker / progress meter after ACW.
init_on_alloc=1 makes the kernel initialize newly allocated pages and heap objects with zeroes.
init_on_free=1 makes the kernel initialize freed pages and heap objects with zeroes upon their deletion. This helps to ensure sensitive data doesn’t leak via use-after-free accesses.
I am not sure what the difference between init_on_free=1 and page_poison=1 is. They seem to do the same.
The link above says
If either SLUB poisoning or page poisoning is enabled, we disable
init_on_alloc and init_on_free so that initialization doesn’t interfere
with debugging.
And yes, as Kees and Daniel mentioned, it’s definitely not just dmesg. In fact, the primary things tend to be /proc and /sys, not dmesg itself.
Another example of this would be commit 31b0b385f69d (“nf_conntrack: avoid kernel pointer value leak in slab name”), where the fact that the slab name had a pointer in it leaked it in the filenames in /sys, because we export slab statistics under /sys/kernel/slab/. And each file was readable only by root, but the file names were readable by everybody.
The full system apparmor profile gives fine-grained access to /sys and /proc so that would make kernel pointer leaks very unlikely.