How to address results of `systemd-analyze security`?
I'm confused by these results. How do I go about fixing these alerts? Is this normal for a home computer with Ubuntu? Thanks.
me@ubuntu:~$ systemd-analyze security
UNIT EXPOSURE PREDICATE HAPPY
ModemManager.service 5.6 MEDIUM 😐
NetworkManager.service 7.7 EXPOSED 🙁
accounts-daemon.service 9.6 UNSAFE 😨
acpid.service 9.6 UNSAFE 😨
alsa-state.service 9.6 UNSAFE 😨
anacron.service 9.6 UNSAFE 😨
apport.service 9.6 UNSAFE 😨
avahi-daemon.service 9.6 UNSAFE 😨
bolt.service 5.1 MEDIUM 😐
colord.service 8.8 EXPOSED 🙁
cron.service 9.6 UNSAFE 😨
cups-browsed.service 9.6 UNSAFE 😨
cups.service 9.6 UNSAFE 😨
dbus.service 9.6 UNSAFE 😨
dmesg.service 9.6 UNSAFE 😨
emergency.service 9.5 UNSAFE 😨
gdm.service 9.7 UNSAFE 😨
[email protected] 9.6 UNSAFE 😨
glances.service 9.6 UNSAFE 😨
grub-common.service 9.6 UNSAFE 😨
hddtemp.service 9.6 UNSAFE 😨
irqbalance.service 6.0 MEDIUM 😐
kerneloops.service 9.1 UNSAFE 😨
networkd-dispatcher.service 9.6 UNSAFE 😨
nvidia-persistenced.service 9.6 UNSAFE 😨
ondemand.service 9.6 UNSAFE 😨
packagekit.service 9.6 UNSAFE 😨
plymouth-start.service 9.5 UNSAFE 😨
polkit.service 9.6 UNSAFE 😨
rc-local.service 9.6 UNSAFE 😨
rescue.service 9.5 UNSAFE 😨
rsync.service 9.6 UNSAFE 😨
rsyslog.service 9.6 UNSAFE 😨
rtkit-daemon.service 7.0 MEDIUM 😐
snapd.service 9.6 UNSAFE 😨
spice-vdagentd.service 9.2 UNSAFE 😨
strongswan.service 9.6 UNSAFE 😨
switcheroo-control.service 9.6 UNSAFE 😨
systemd-ask-password-console.service 9.3 UNSAFE 😨
systemd-ask-password-plymouth.service 9.5 UNSAFE 😨
systemd-ask-password-wall.service 9.4 UNSAFE 😨
systemd-fsckd.service 9.5 UNSAFE 😨
systemd-initctl.service 9.3 UNSAFE 😨
systemd-journald.service 4.2 OK 🙂
systemd-logind.service 2.8 OK 🙂
systemd-networkd.service 2.8 OK 🙂
systemd-resolved.service 2.1 OK 🙂
systemd-rfkill.service 9.3 UNSAFE 😨
systemd-timesyncd.service 2.0 OK 🙂
systemd-udevd.service 8.1 EXPOSED 🙁
thermald.service 9.6 UNSAFE 😨
udisks2.service 9.6 UNSAFE 😨
unattended-upgrades.service 9.6 UNSAFE 😨
upower.service 2.0 OK 🙂
[email protected] 9.3 UNSAFE 😨
[email protected] 9.3 UNSAFE 😨
uuidd.service 4.3 OK 🙂
vboxweb.service 9.6 UNSAFE 😨
virtualbox-guest-utils.service 9.6 UNSAFE 😨
virtualbox.service 9.6 UNSAFE 😨
whoopsie.service 9.6 UNSAFE 😨
wpa_supplicant.service 9.6 UNSAFE 😨
systemd-analyze security looks at the sandbox features built into systemd. It does not check the service itself. So it is safe to ignore these but if you do want to address these see freedesktop systemd on how for sandbox options:
Sandboxing
The following sandboxing options are an effective way to limit the exposure of the system towards the unit's processes. It is recommended to turn on as many of these options for each unit as is possible without negatively affecting the process' ability to operate. Note that many of these sandboxing features are gracefully turned off on systems where the underlying security mechanism is not available. For example,
ProtectSystem=has no effect if the kernel is built without file system namespacing or if the service manager runs in a container manager that makes file system namespacing unavailable to its payload. Similar,RestrictRealtime=has no effect on systems that lack support for SECCOMP system call filtering, or in containers where support for this is turned off.Also note that some sandboxing functionality is generally not available in user services (i.e. services run by the per-user service manager). Specifically, the various settings requiring file system namespacing support (such as
ProtectSystem=) are not available, as the underlying kernel functionality is only accessible to privileged processes.
There is a long list of options you can set to enforce the unit to adhere to a more strict policy each with a lengthy explanation on what it does.
A few:
ProtectSystem=
Takes a boolean argument or the special values "full" or "strict". If true, mounts the /usr and /boot directories read-only for processes invoked by this unit. If set to "full", the /etc directory is mounted read-only, too. If set to "strict" the entire file system hierarchy is mounted read-only, except for the API file system subtrees /dev, /proc and /sys (protect these directories using PrivateDevices=, ProtectKernelTunables=, ProtectControlGroups=). This setting ensures that any modification of the vendor-supplied operating system (and optionally its configuration, and local mounts) is prohibited for the service. It is recommended to enable this setting for all long-running services, unless they are involved with system updates or need to modify the operating system in other ways. If this option is used, ReadWritePaths= may be used to exclude specific directories from being made read-only. This setting is implied if DynamicUser= is set. This setting cannot ensure protection in all cases. In general it has the same limitations as ReadOnlyPaths=, see below. Defaults to off.
ProtectHome=
Takes a boolean argument or the special values "read-only" or "tmpfs". If true, the directories /home, /root, and /run/user are made inaccessible and empty for processes invoked by this unit. If set to "read-only", the three directories are made read-only instead. If set to "tmpfs", temporary file systems are mounted on the three directories in read-only mode. The value "tmpfs" is useful to hide home directories not relevant to the processes invoked by the unit, while still allowing necessary directories to be made visible when listed in BindPaths= or BindReadOnlyPaths=.
Setting this to "yes" is mostly equivalent to set the three directories in InaccessiblePaths=. Similarly, "read-only" is mostly equivalent to ReadOnlyPaths=, and "tmpfs" is mostly equivalent to TemporaryFileSystem= with ":ro".
It is recommended to enable this setting for all long-running services (in particular network-facing ones), to ensure they cannot get access to private user data, unless the services actually require access to the user's private data. This setting is implied if DynamicUser= is set. This setting cannot ensure protection in all cases. In general it has the same limitations as ReadOnlyPaths=, see below.
This option is only available for system services and is not supported for services running in per-user instances of the service manager.
RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory=
These options take a whitespace-separated list of directory names. The specified directory names must be relative, and may not include "..". If set, one or more directories by the specified names will be created (including their parents) below the locations defined in the following table, when the unit is started. Also, the corresponding environment variable is defined with the full path of directories. If multiple directories are set, then in the environment variable the paths are concatenated with colon (":").