systemd service sandboxing/hardening; worth it for standalone computer?

English Install/Boot/Login
1

The command:

systemd-analyze security

shows many .service files on my computer with an exposure of 9+ and an ‘unsafe’ rating. Here’s an example from a Tumbleweed VM, installed in as ‘stock’ a configuration as possible:

$ systemd-analyze security

UNIT                                  EXPOSURE PREDICATE HAPPY
ModemManager.service                       5.8 MEDIUM    ������    
NetworkManager.service                     8.0 EXPOSED   ������    
after-local.service                        9.6 UNSAFE    ������    
alsa-state.service                         9.6 UNSAFE    ������    
auditd.service                             9.5 UNSAFE    ������    
avahi-daemon.service                       9.6 UNSAFE    ������    
btrfs-balance.service                      9.6 UNSAFE    ������    
btrfs-defrag.service                       9.6 UNSAFE    ������    
btrfs-scrub.service                        9.6 UNSAFE    ������    
btrfs-trim.service                         9.6 UNSAFE    ������    
chronyd.service                            8.9 EXPOSED   ������    
cron.service                               9.6 UNSAFE    ������    
cups.service                               9.6 UNSAFE    ������    
dbus.service                               9.6 UNSAFE    ������    
display-manager.service                    9.6 UNSAFE    ������    
dm-event.service                           9.5 UNSAFE    ������    
emergency.service                          9.5 UNSAFE    ������    
firewalld.service                          9.6 UNSAFE    ������    
getty@tty1.service                         9.6 UNSAFE    ������    
getty@tty7.service                         9.6 UNSAFE    ������    
gpm.service                                9.6 UNSAFE    ������    
haveged.service                            6.7 MEDIUM    ������    
irqbalance.service                         6.1 MEDIUM    ������    
mariadb.service                            6.4 MEDIUM    ������    
mcelog.service                             9.6 UNSAFE    ������    
nscd.service                               9.6 UNSAFE    ������    
pcscd.service                              9.6 UNSAFE    ������    
plymouth-start.service                     9.5 UNSAFE    ������    
polkit.service                             9.6 UNSAFE    ������    
postfix.service                            9.6 UNSAFE    ������    
rc-local.service                           9.6 UNSAFE    ������    
rescue.service                             9.5 UNSAFE    ������    
rtkit-daemon.service                       7.0 MEDIUM    ������    
serial-getty@hvc0.service                  9.6 UNSAFE    ������    
serial-getty@ttyAMA0.service               9.6 UNSAFE    ������    
serial-getty@ttyS0.service                 9.6 UNSAFE    ������    
serial-getty@ttyS1.service                 9.6 UNSAFE    ������    
serial-getty@ttyS2.service                 9.6 UNSAFE    ������    
smartd.service                             9.6 UNSAFE    ������    
systemd-ask-password-console.service       9.3 UNSAFE    ������    
systemd-ask-password-plymouth.service      9.5 UNSAFE    ������    
systemd-initctl.service                    9.3 UNSAFE    ������    
systemd-journald.service                   4.2 OK        ������    
systemd-logind.service                     2.8 OK        ������    
systemd-rfkill.service                     9.3 UNSAFE    ������    
systemd-timesyncd.service                  2.1 OK        ������    
systemd-udevd.service                      6.7 MEDIUM    ������    
udisks2.service                            9.6 UNSAFE    ������    
upower.service                             2.3 OK        ������    
user@1000.service                          9.4 UNSAFE    ������    
vboxadd-service.service                    9.6 UNSAFE    ������    
vgauthd.service                            9.6 UNSAFE    ������    
vmblock-fuse.service                       9.6 UNSAFE    ������    
vmtoolsd.service                           9.5 UNSAFE    ������

Digging online turned up some guides for tweaking .service file configuration; however, one guide warned that the tweaks introduce restrictions never intended for the OS, and have to be thoroughly tested before being left in place.

Do any of you more experienced Linux users restrict service files in this way? Do you think the effort is worthwhile for a non-networked, standalone computer that surfs the web and little else? Is it worth the effort to sandbox some .service files, and not others?

Thanks in advance for your feedback. I’ll proceed if the effort is worthwhile, but thought I should ask first.

2

I tried that in Leap 15.2, and “systemd-analyze security” is not implemented there.

So I check in Tumbleweed, and get a similar report to what you see.

Next, I looked at the man page, and found this:

“The exposure level determined this way should not be misunderstood: a high exposure level neither means that there is no effective sandboxing applied by the service code itself, nor that the service is actually vulnerable to remote or local attacks.”

It looks to me as if this is a work-in-progress with systemd, and not any reason to be alarmed.

3

Hi
You also need to look at each individual service to see what is what… eg;


systemd-analyze security --no-pager systemd-logind.service

or user level services

systemd-analyze security --no-pager --user pulseaudio.service
4

Thanks for the replies, nrickert and malcolmlewis. You’re both much more knowledgeable than me, so my main takeaway is that two expert users don’t think that sandboxing these services is necessary (at least for a user like me). I’m inclined to leave well enough alone.

FWIW: I thought to run this test after installing the Lynis security auditing tool.

5

systemd probably needs to define “exposure” somewhere.
Sounds like what you quoted might mean something similar to what in network security is referred to as the “attack surface” which means that there is exposure but the exposure can be mitigated.

BTW - If your machine can surf the Internet, it’s networked. And as such your machine is exposed (not necessarily vulnerable which requires a more sophisticated examination) to malicious malware and activity.

If you have any interest in computer security, there are numerous guides and references that can give you a start… Regarding network threats specifically, people normally look at firewalls and user permissions first, then file permissions and then the various ways of managing file permissions by things like policy, access control lists, and templates like what you’ll find in SElinux and AppArmor. Security is incredibly complex, and a User can dive as deep as you want and always find more that can be explored.

So no, your machine cannot be considered safe like a truly non-networked machine which might be sitting by its lonesome self in a room with no ethernet, WiFi or other means of communicating with another machine.

TSU