in a terminal looks horrible in Whonix-WS and Whonix-GW (Qubes), with basically 80-90% of services listed as UNSAFE or EXPOSED.
This command doesn’t consider security-enforced policies like SELinux or AppArmor though, so possibly/probably a lot of false positives, particularly for non-Qubes-Whonix thanks to @madaidan AppArmor hardening.
But I do wonder if there are some easy wins in the long scary lists i.e. can anything be disabled entirely (if not really a necessary service), or maybe there are some systemd security directives that can be used?
I don’t think it is useful to look at that as a whole and without context.
Context: compare with other distributions
as a whole: It lists services which aren’t even active. For some services it doesn’t make sense to add systemd hardening. That would only lead to higher system instability / more bugs. For some services it would be up to upstream to add systemd hardening. Each service needs to be looked at individually for attack surface and possible containment.
I wonder what systemd would say “add systemd hardening to systemd-fsckd.service / rescue.service”. Might not make sense.
Maybe it would make sense to contain for example qubes-updates-proxy.service but that’s upstream. I cannot add systemd hardening to every upstream which Whonix relies on. Probably enough work to keep 10 people full time busy…
Most services with larger attack surface (e.g. sdwdate, onion-grater etc.) are sandboxed well. There’s plenty of services there that don’t really need sandboxing.
If we really wanted to, I could maintain a bunch of drop-in config folders containing sandboxing for these.
SELinux/AppArmor can’t do the same as systemd sandboxing. AppArmor can’t do namespaces or seccomp for example so they aren’t really false positives.