Kernel Hardening - security-misc

Poettering closed it and said to go to util-linux again.


I mirrored answers by util-linux and systemd:

1 Like

The util-linux dev responded and is working on fstab.d.

GitHub - util-linux/util-linux at topic/fstab.d

This is great. We can add the mount options to fstab.d in security-misc or another package once this is finished.



  • kernel.yama.ptrace_scope :
    Great but might break some programs running
    under WINE. Please add this to the comments so we can answer user support

Added it.

Just removed it. Thanks

1 Like


1 Like
1 Like

Anything useful for should add here?

1 Like

They all seem to be enabled by default or have been enabled with my patches.

Has there been any news about fstab.d? We should probably look into systemd .mount files for hidepid until fstab.d is a thing.

1 Like

Anything missing here?

/proc/$pid/maps protection

Present in 2.6.22; requires sysctl toggle (kernel.maps_protect = 1). Became non-optional in 2.6.27

This was removed?

Nothing specific yet.

A systemd unit file drop-in config snippet?
Patches welcome.

1 Like

All seem to be enabled by default, enabled by security-misc, not available anymore, useless or counter-productive. Most options are just performance tuning.

Also, unrelated but does Whonix disable core dumps? One of the options there reminded me of them.

Seems like it. The commit is confusing though.

sysctl stopped being relevant because commit moved security checks from ->show time to ->start time (mm_for_maps()).

Does this mean it can be enabled elsewhere?

Yes, I have no experience in those files though and my last attempts didn’t work.


Not that I know. We have only this:

1 Like

Coredumps not enabled in Debian by default. I learned this while reading up on ways to make Whonix forensic resistant while in Live Mode.


Netflix CVEs published for TCP stack DDoS. It’s mitigated by tweaking a couple of sysctl settings:

Offtopic, but interesting fact mentioned in a thread discussing this. IMHO we shouldn’t fix what ain’t broke but it makes an interesting point.

It is much preferred to use “iptables -I INPUT” instead of “iptables -A INPUT”. Depending on rules in your chain, -A could possibly cause much cpu load if the rule is heavily processed.

At HN it is suggested to use “-t raw -I PREROUTING”, which could be of benefit especially with heavy traffic.


DDoS attacks aren’t that big of a problem on desktop OSes. It’d be more of an annoyance than anything.

Some of those settings may break things. For example, disabling MTU probing will break obfs4 bridges.

Would disabling SACK impact anything? It seems that it’s commonly exploited so disabling it may be a good idea.

1 Like

Good catch.

I guess disabling SACK also can negatively affect performance when using VPN over Tor since it helps on high latency connections.

No need to mess with these settings when a kernel fix will take care of them anyway and they are DDoS and not RCE bugs.


I doubt most people would setup VPN over Tor so disabling this might not be much of a problem.

SACK seems to be commonly exploited. Disabling it may prevent many other bugs and not just the ones found recently and may reduce potential attack surface. The way it seems to me is, SACK is fundamentally flawed and not necessary in most use cases.


Indeed. It can be used to induce pressure on Onion services, eating up their CPU which may make some sidechannel attacks easier.

Let’s disable it for now and I’ll give feedback on VPN performance if it is affected.


Should I create a pull request to disable it?


Yes, please, most welcome.