On 2020-02-12 01:09, [email protected] wrote:
APL external email warning: Verify sender
[email protected] before clicking
links or attachments
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 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?
I ran the report on my fedora-30, but then scripted up a test to see
what services listed in this report were actually running.
atd.service - Deferred execution scheduler
cups.service - CUPS Scheduler
[email protected] - Getty on tty1
haveged.service - Entropy Daemon based on the HAVEGE algorithm
polkit.service - Authorization Manager
qubes-db.service - Qubes DB agent
qubes-gui-agent.service - Qubes GUI Agent
qubes-meminfo-writer.service - Qubes memory information reporter
qubes-qrexec-agent.service - Qubes remote exec agent
[email protected] - Serial Getty on hvc0
[email protected] - User Manager for UID 1000
xendriverdomain.service - Xen driver domain device daemon
This list does not look so scary to me, since these services actually
serve a purpose for which they were written. My question is why are the
required services being marked as "UNSAFE" and how to improve the
ratings on the required services. Without knowing why they received such
a bad rating under this utility seems to be the much more the important
question.
A service that is not running does not pose much of an attack surface
unless the adversary can launch that service. If the adversary can
launch that service you have much *bigger* problem than the service
running. At that point you are already p0ned.
What I would choose to do, if I were that worried about non-running
services, is to instrument them so that I get notified if one service
somehow gets launched. Kind of like a hackers honey pot with notification.
I will be running this utility on each individual running service to see
what I can do to improve upon their configuration, but I am not going to
loose much sleep over the ones that are not even configured to run.
--
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/723b6c1f-6ee5-8072-68cb-619f6d61cef3%40jhuapl.edu.
