[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Kernel Hardening

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

2 Likes

I mirrored answers by util-linux and systemd:

1 Like

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

https://github.com/karelzak/util-linux/tree/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.

2 Likes

Notes:

  • 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
    tickets.
2 Likes

Added it.

Just removed it. Thanks

1 Like

Merged.

1 Like
1 Like

Anything useful for should add here?

https://wiki.debian.org/Hardening#Kernel_Space

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?

http://kb.ictbanking.net/article.php?id=346

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

2 Likes

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.

2 Likes

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.

3 Likes

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.

2 Likes

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.

2 Likes

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.

2 Likes

Should I create a pull request to disable it?

2 Likes

Yes, please, most welcome.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]