Why don't distros flip more of these switches? Are there cons of being more aggressive with these settings? It's really a lot for many people to tinker with.
Why don't distros flip more of these switches? Are there cons of being more aggressive with these settings? It's really a lot for many people to tinker with.
> Are there cons of being more aggressive with these settings?
well, the con is you might unknowingly break some setups. take NetworkManager: after tightening it down, did you check both IPv4 and IPv6 connectivity? did you check that both the `dns=systemd-resolved` and `dns=default` modes of operation (i.e. who manages /etc/resolv.conf) work? did you check its ModemManager integrations, that it can still manage cellular connections? did you check that the openvpn and cisco anyconnect plugins still work? what about the NetworkManager-dispatcher hooks?
> Why don't distros flip more of these switches?
besides the bit of "how many distro maintainers actually understand the thing they're maintaining well enough to know which switches can be flipped without breaking more than 0.01% of user setups", there's the bit of "should these flags be owned by the distro, or by the upstream package?" if the distro manages these, they'll get more regressions on the next upstream release. if the upstream sets these, they can't be as aggressive without breaking one or two of their downstreams.
This question is sorta similar to "Why don't distros enable restrictive MAC policies by default"
Maintainers _could_ take the time to lock down sshd and limit the damage it can do if exploited, but there are costs associated with that:
You could extend this argument and say that distros shouldn't bother with _any_ security features, but part of the job of a distro maintainer is to strike a balance here, and similar to SELinux / AppArmor / whatever, most mainstream desktop distro maintainers probably don't think the juice is worth the squeeze.Because they/we don't have sufficient integration tests to verify that the core system services are working after tightening down each parameter.
From https://news.ycombinator.com/item?id=29995566 :
> Which distro has the best out-of-the-box output for?:
desbma/shh generates SyscallFilter and other systems unit rules from straces similar to how audit2allow generates SELinux policies by grepping for AVC denials in permissive mode (given kernel parameters `enforcing=0 selinux=1`), but should strace be installed in production?:desbma/shh: https://github.com/desbma/shh
I don't know but I would imagine the settings are sometimes new. Not everyone is a systemd nerd, and even if they were you may actually break stuff for old versions of systemd if you try to turn them on.
We could also ask why nobody seems to use SELinux or AppArmor, or any other random security feature. Most distros have these things available but most developers and users are not familiar, don't truly need it, etc.