February 12, 2020 6:09 AM, [email protected] wrote: > On 2020-02-11 11:39, unman wrote: > >> On Tue, Feb 11, 2020 at 01:34:15AM -0800, [email protected] wrote: >>> I've been reading a blog from the renowned Daniel Aleksandersen at >>> https://www.ctrl.blog/entry/systemd-service-hardening.html >>> >>> The output from a Debian-10 based Appvm looks a little scary!! Should I >>> be concerned? >>> >>> user@tmp3:~$ systemd-analyze security >>> UNIT EXPOSURE PREDICATE HAPPY >>> ModemManager.service 5.6 MEDIUM ???? >>> NetworkManager.service 7.6 EXPOSED ???? >>> avahi-daemon.service 9.5 UNSAFE ???? >>> cron.service 9.5 UNSAFE ???? >>> cups-browsed.service 9.5 UNSAFE ???? >>> cups.service 9.5 UNSAFE ???? >>> dbus.service 9.5 UNSAFE ???? >>> dm-event.service 9.5 UNSAFE ???? >>> emergency.service 9.5 UNSAFE ???? >>> exim4.service 9.5 UNSAFE ???? >>> [email protected] 9.5 UNSAFE ???? >>> haveged.service 5.6 MEDIUM ???? >>> lvm2-lvmpolld.service 9.5 UNSAFE ???? >>> polkit.service 9.5 UNSAFE ???? >>> qubes-db.service 9.5 UNSAFE ???? >>> qubes-firewall.service 9.5 UNSAFE ???? >>> qubes-gui-agent.service 9.5 UNSAFE ???? >>> qubes-meminfo-writer.service 9.5 UNSAFE ???? >>> qubes-qrexec-agent.service 9.5 UNSAFE ???? >>> qubes-sync-time.service 9.5 UNSAFE ???? >>> qubes-updates-proxy.service 9.5 UNSAFE ???? >>> rc-local.service 9.5 UNSAFE ???? >>> >>> rescue.service 9.5 UNSAFE ???? >>> rsyslog.service 9.5 UNSAFE ???? >>> rtkit-daemon.service 6.9 MEDIUM ???? >>> [email protected] 9.5 UNSAFE ???? >>> systemd-ask-password-console.service 9.3 UNSAFE ???? >>> systemd-ask-password-wall.service 9.3 UNSAFE ???? >>> systemd-fsckd.service 9.5 UNSAFE ???? >>> systemd-initctl.service 9.3 UNSAFE ???? >>> systemd-journald.service 4.3 OK ???? >>> systemd-logind.service 4.1 OK ???? >>> systemd-networkd.service 2.8 OK ???? >>> systemd-timesyncd.service 2.0 OK ???? >>> systemd-udevd.service 8.3 EXPOSED ???? >>> tinyproxy.service 8.7 EXPOSED ???? >>> udisks2.service 9.5 UNSAFE ???? >>> [email protected] 9.1 UNSAFE ???? >>> wpa_supplicant.service 9.5 UNSAFE ???? >>> xendriverdomain.service 9.5 UNSAFE ???? >> >> It does look scary. >> The output from a Fedora based qube looks much the same.. >> You should run the analysis against each service and see where you think >> they could be hardened. Post back your conclusions here. >> Also, I see that you have many services that need not be there - some >> of these will be disabled by Qubes- some you do not need in every qube >> (cups-browsed, exim4, tinyproxy etc). >> You need to review what services you are running, and disable those you >> do not want. My list in an ordinary qube looks rather different from >> yours. Those are steps you should be taking in any case. >> Also, bear in mind that the analysis doesn't take in to account any >> security features in the programs themselves, or other mitigations. >> So you need to do a good deal more work before reaching any conclusions >> about your system. >> Look forward to hearing from you >> unman > > As I read it, your suggesting that the output is influence by User > preferences as opposed to default system settings? To test that theory, > I loaded a vanilla version of Qubes 4.0.3 onto a spare box and ran the > command systemd-analyze security against the virgin Debian-10 Template. > The output is identical to the one I originally posted. As you inferred, > the output from Fedora Template is similar.
I'm curious how this compares to a vanilla (non-Qubes) Fedora or debian install. In general most packages' default service files use very few if any systemd security features on most distros. I think that's more of a DIY thing. > I'm not sure if you'll agree, but my conclusion from this experiment is > that the Qubes Team have some work to do in hardening Qubes? Like you > say,"I see that you have many services that need not be there"; so my > question is, why are they present in a vanilla version of Qubes? > My impression of the official Qubes developers' stance on this is "security by isolation," i.e. Xen is the only component they actually consider secure. This is the rationale for passwordless sudo for example. In practice, I can agree, it's difficult enough to develop and maintain an OS as sophisticated as Qubes in the first place, let alone if they had to also harden guest OSes at various levels. In principle, I say fair enough, I suppose it's not really Qubes' concern what goes on within VMs. Qubes just polices the border. You might be interested in Chris's Qubes hardening tools, however I don't know it uses the systemd security features at all so it may not improve systemd's report. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8984e8aec137542e444624f8b9b9206b%40disroot.org.
