systemd-analyze security

Nice.

BTW running:

systemd-analyze security

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?

See also:

https://www.freedesktop.org/software/systemd/man/systemd-analyze.html

PS Pity about the shitty forum software that has borked our logins via v3 onion again. @mig5 … you’re our only hope :wink:

PPS @0brand you still about? We should get the wiki thing happening again (bit short on time myself)

2 Likes

Welcome back! :slight_smile:

See also:

Apply systemd sandboxing by default to some services

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…

https://forums.whonix.org/t/onion-forum-broken/8870

2 Likes

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.

Not all things in the list are enabled anyway.

1 Like