Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / Securing systemd Services

Securing systemd Services

Publication Date: 12 Dec 2024
WHAT?

systemd service files are most often used to operate one or more systemd services, such as starting, stopping or viewing the status of the service. Besides this, the service files can limit the privileges of the service they control.

WHY?

Using security options of systemd service files increases the security of the service they control. This adds another security layer of the whole operating system.

EFFORT

It takes less than 15 minutes to understand how systemd can control the security level of systemd services.

REQUIREMENTS

  • Good knowledge of the systemd environment

  • root privileges

1 Secure systemd services

 

Linux increases its security by separating privileges between individual components of the operating system. System services already have a default level of security. For example, their processes run under their own user ID, which limits the changes they can perform on the system.

The default level of privilege separation provides only a basic protection. Services can still perform as many changes as normal local users, though not as many as root. A higher level of system security requires limiting what services can perform and prevents them from certain privileges that normal users are allowed to use.

1.1 How does securing services with systemd work?

 

There are several methods to secure processes and applications that you can use simultaneously. For example, confining with SELinux or AppArmor is recommended. systemd can apply additional restrictions to local services by using technologies included in the kernel. These restrictions are activated by adding specific options to the systemd service definition and restarting the service.

1.2 Benefits of securing services

 

Securing systemd services increases the security of the whole operating system and protects sensitive data contained on its file system.

2 Analyzing the security level

 

systemd can apply additional restrictions to local services by using technologies included in the kernel. These restrictions are activated by adding specific options to the systemd service definition and restarting the service.

Use the systemd-analyze security command to analyze security settings of specified systemd service units. If unit names are not specified, the command inspects security settings of all currently loaded service units. We recommend running the command after a specific systemd unit file is updated. The command calculates an overall “exposure level” that is an estimation in the range 0.0 to 10.0, showing how exposed a service is security-wise. High values indicate little loose security provisions, while low exposure levels indicate tight security restrictions. 

> systemd-analyze security systemd-logind.service
NAME                DESCRIPTION                              EXPOSURE
✗ PrivateNetwork=     Service has access to the host's network      0.5
✗ User=/DynamicUser=  Service runs as root user                     0.4
✗ DeviceAllow=        Service has no device ACL                     0.2
✓ IPAddressDeny=      Service blocks all IP address ranges
...
→ Overall exposure level for systemd-logind.service: 4.1 OK 🙂

3 Techniques of securing

 

This topic introduces commonly used techniques that systemd offers to protect services. To apply the changes, add the required option to the service definition file and restart the specific service.

PrivateNetwork=yes

This option isolates the service and its processes from networking. This prevents external network requests from reaching the protected service. Be aware that certain services require the network to be operational.

PrivateTmp=yes

This option provides the service with a private /tmp isolated from the host system's /tmp. The shared host /tmp directory is a major source of security problems, such as symlink attacks and DoS /tmp temporary files.

InaccessibleDirectories=/home

This option makes the specified directories inaccessible to the service. This option narrows the range of directories that can be read or modified by the service, for example, to secure users' private files.

ReadOnlyDirectories=/var

This option makes the specified directories inaccessible for writing to the service. The example configuration makes the whole tree below /var read-only. This option prevents the service from damaging the system files.

CapabilityBoundingSet=CAP_CHOWN CAP_KILL

This option restricts the kernel capabilities that a service can retain. In the example above, only the CAP_CHOWN and CAP_KILL capabilities are retained by the service, and the service and any processes it creates cannot obtain any other capabilities, not even via setuid binaries.

Tip
Tip

To easily identify which processes on your system retain which capabilities, use the pscap tool from the libcap-ng-utils package.

Tip
Tip

The ~ prefix inverts the meaning of the option—instead of listing all capabilities that the service retains, you may list the ones it does not retain: 

...
    [Service]
    CapabilityBoundingSet=~CAP_SYS_PTRACE
    ...
LimitNPROC=1, LimitFSIZE=0

You can use resource limits to apply security limits on services. Two of them can disable specific operating system features: RLIMIT_NPROC=1 disables precess forking, while RLIMIT_FSIZE=0 disables creating non-empty files on the file system.

DeviceAllow=/dev/null rw

This option limits access to /dev/null, disallowing access to any other device nodes.

4 For more information