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.
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.
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.
- net.ipv4.conf.all.rp_filter=1 :
Please remove. Whonix is not configured to act as a router so this setting is unnecessary. It could also break VPN traffic.
2 Likes
Added it.
Just removed it. Thanks
1 Like
Merged.
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.
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.
4 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.
3 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?
3 Likes
Yes, please, most welcome.
2 Likes