Kernel Hardening - security-misc

The text really helped. Well written. Applied a syntax fix on top.

1 Like

A post was split to a new topic: kernel recompilation for better hardening

There is no ‘on’ option for amd_iommu. Is there some way to check if these settings are valid/recognized without testing them? Maybe someone familiar with the kernel on Debian bug tracker?


Weird. The Arch Wiki and a few other places say to use amd_iommu=on. Maybe the kernel docs are wrong?


Well I’m not going to argue with Arch documentation :wink:


The files should be removed. By default, /boot/* contains kernel symbols which could be useful to an attacker. Setting kernel.kptr_restrict=2 hides these from /proc/kallsyms but an attacker can just look at the files to get the symbols anyway.

These could possibly be purged during the build or at boot with a systemd service.

Tails also removes these. files are only used for debugging or malware.

It may be useful to disable the SysRq key too. It allows anyone to use certain commands that the kernel will do regardless of what it’s currently doing. It can be disabled with sysctl using kernel.sysrq=0. I am not too sure about this one though.

See QA/Sysrq - Fedora Project Wiki. It doesn’t look too good.


35 posts were merged into an existing topic: SysRq (Magic SysRq key)

Sounds all great!

Could you please add a script to:

The deletion logic should be in the script not in a systemd unit file directly. Reason:


comment added here:
Remove and restrict the SysRq key. by madaidan · Pull Request #13 · Kicksecure/security-misc · GitHub

1 Like

A post was split to a new topic: lynis - security auditing tool for Unix based systems

Back to hidepid.

I would not hold my breath for [feature request] /etc/fstab.d · Issue #790 · util-linux/util-linux · GitHub to materialize. The ticket was not even reopened yet.

Let’s not touch /etc/fstab for stability reasons.

In /etc/fstab.d · Issue #12506 · systemd/systemd · GitHub poettering wrote [sniped by me]:

if I were you I’d just write a generator that looks at /etc/fstab and creates drop-ins for the .mount units systemd-fstab-generator generates that override the Option= line. i.e. let systemd-fstab-generator do its thing as it currently does (meaning: translating fstab into native systemd .mount unit files), but then have your own generator that tweak some of these mount units with additional generated drop-ins as you need.

Can you make head or tail of it?
We don’t have to make it as complicated as having our own generator. Hardcoding the few option we need in drop-in config files would suffice.

Btw there are files in /run/systemd/generator/ which are # Automatically generated by systemd-fstab-generator if that helps.

Alternatively we had:

theory #1:
theory #2:
theory #3:

Could you work on this please?

1 Like

It sounds very complicated and hard to do.

Those seem to be systemd .mount files. I think systemd generates .mount files out of /etc/fstab and uses them to mount the filesystems.

I can try. The past attempts didn’t work though.

1 Like

Mounting /proc with .mount files doesn’t seem possible.

host systemd[1]: proc.mount: Cannot create mount unit for API file system /proc. Refusing.

Theory #1 seems to be the best solution right now. I’ll test it now.

1 Like

Theory #1 works great! Create a systemd service with:

Description=Mounts /proc with hidepid=2

ExecStart=/bin/mount -o remount,nosuid,nodev,noexec,hidepid=2 /proc


I can add systemd sandboxing if needed (likely not).

1 Like

Should security-misc also disable coredumps? For distros that have them enabled by default.

It wouldn’t be needed on Whonix as Debian disables them by default and Whonix doesn’t re-enable them but it may be useful for other distros that are using security-misc.

1 Like

Awesome! Will test soon.

madaidan via Whonix Forum:

I can add systemd sandboxing if needed (likely not).

I am wondering if systemd sandboxing can do more harm than good here.

What’s the threat model? /proc containing at early boot something
malicious, which would upon using mount with remount options, result
in exploiting a vulnerability in mount, then leading to root compromise?

On the other hand, any (distribution) upgrade of kernel, mount or any
dependent libraries requiring any new seccomp could lead to remount fail
“in the middle”, hence end up with an unbootable system?

1 Like

madaidan via Whonix Forum:

Should security-misc also disable coredumps? For distros that have them enabled by default.

Yes, that would be good.

As per

security-misc will in future be available in Qubes Debian and Fedora
templates. Perhaps even in Qubes dom0. I.e. Fedora packaging upcoming.

And as per Whonix Packages for Debian Hosts and Whonix Host Enhancements
packages by Whonix can potentially be installed on any derivative of
Debian. If/when security-misc gets ever uploaded to,
it will flow down to any derivative based on Debian.

1 Like

I just think we should sandbox as much as possible, especially root processes. A compromised systemd service could pretty easily be turned into a rootkit.

That’s unlikely as I doubt mount will be updated much and this is what testers versions are for. Any major kernel update will likely be part of the testers only version of Whonix. I could remove the syscall filter so it’d be even more unlikely for it to break.

Ok, I’ll add it now.

1 Like