Kernel Hardening - security-misc

Outreach done to:

(as per enforce kernel module software signature verification [module signing] / disallow kernel module loading by default - #47 by Patrick)


Could we please work on the presentation of package security-misc?

Contributions / suggestions for
Github description, github website, githab tags?

Technical implementation is good but presentation might be lacking and outreach and popularity of security-misc is almost non-existing.

Once that is done, we could notify related parties of the existence of this package and add to relevant lists.


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.)

1 Like

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.

1 Like

No, it’s still the same. things like logind usually do need an exception but proc-hidepid.service always executes after them so it’s not that bad.

1 Like

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 see Does printk() cause any security issues?

This can improve boot and shutdown speed too. I’ve noticed that performance improves significantly after setting this.

1 Like

Not sure exactly how to solve this but something should be done.

Was contemplating:

dmesg --console-off

Where/when to run that command? That command is per console or user or global?

The context which pointed that out: timesync Error: vgsvcTimeSyncWorker: VbglR3GetHostTime failed - #7 by Patrick_mobile

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.

1 Like

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.

sudo helps?

1 Like

I guess that’s ok? Unavoidable? At least sudo/root required.

But whonixcheck shouldn’t show to nonroot/nonsudo users.

1 Like

Might be cause or related…?

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.

1 Like

No. I ran it as root.

It wouldn’t be too hard to make it only display the logs if the user is root.

1 Like

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.

1 Like

Perhaps specifically those are ones that should better be hidden? If anything, hide it all for completeness sake?

1 Like

If really important errors are hidden too then users might just see a black screen and have no idea what’s happened.

E.g. a kernel panic happens for whatever reason and important errors are hidden so the user doesn’t know.

1 Like
1 Like issue.

sudo make install
make -C /lib/modules/4.19.0-6-amd64/build M=/home/user/sourcesother/lkrg-0.7 modules_install
make[1]: Entering directory ‘/usr/src/linux-headers-4.19.0-6-amd64’
INSTALL /home/user/sourcesother/lkrg-0.7/p_lkrg.ko
DEPMOD 4.19.0-6-amd64
Warning: modules_install: missing ‘’ file. Skipping depmod.
make[1]: Leaving directory ‘/usr/src/linux-headers-4.19.0-6-amd64’
depmod -a
/home/user/sourcesother/lkrg-0.7/scripts/bootup/ install
[*] Executing LKRG’s bootup installation script
[+] Systemd detected
Installing lkrg.service file under /run/systemd/system folder
Enabling lkrg.service on bootup
Created symlink /etc/systemd/system/ → /run/systemd/system/lkrg.service.
To start lkrg.service please use: systemctl start lkrg

1 Like

We should use the init_on_alloc=1 and init_on_free=1 boot parameters once they get to the Debian stable kernel.

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.

So I’m not sure which to use.

There is a Tails ticket for this Enable the init_on_alloc=1 and init_on_free=1 Linux options (#17236) · Issues · tails / tails · GitLab and they also use page_poison=1 so we should wait and see what they say.

linux-hardened seems to prefer init_on_free over page_poison.

Also see security things in Linux v5.3 « codeblog


The program doesn’t work for me but it has a neat list of areas to look for kernel symbols.

I can’t find any kernel symbol leaks in these directories/files but it lists the kernel images and I don’t know how to check those for symbols.

Why are the kernel images readable by all users anyway? Shouldn’t it be restricted to root?

1 Like

Linus Torvalds has also said interesting things about these leaks.

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.