How to address results of `systemd-analyze security`?

Question

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        
getty@tty1.service                         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            
user@1000.service                          9.3 UNSAFE        
user@123.service                           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

I wouldn't worry about it. Have you experienced any security issues? — WinEunuuchs2Unix, Oct 20 '19 at 19:21
Mine is about the same. Unless you are doing unsafe things, think our bigger worry is other companies we have to give our information to, and then find out the next week, they leave all our info on an open database that anyone can read and copy. Usually in the news once or twice a week. — crip659, Oct 20 '19 at 20:51

score 8 · Accepted Answer · answered Oct 20 '19 at 19:30

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 (":").

score 0 · Answer 2 · answered Mar 11 '24 at 00:52

systemd-analyze security SERVICE will show you details for a single service, with the relevant settings which you can find more info on in man 5 systemd.exec. If you build your own service it is probably a good idea to review the results to understand the potential risks of your service being compromised, encountering malformed data, and programming errors. Some settings can even make your service easier to maintain: DynamicUser sets up a user for the service at runtime, so you don't have to.

How to address results of `systemd-analyze security`?

2 Answers2