Configuration

SystemCallFilter setting

Define if systemd units are allowed to use specific syscalls or groups with the unit setting SystemCallFilter.

Summary

Why and when to use SystemCallFilter The setting SystemCallFilter aims to prevent misuse of syscalls that are not needed for normal functioning of a process. This powerful filtering restricts the abilities of a process, but requires understanding of processes by the system administrator. See the overview of Linux syscalls for more details. Configuration This setting takes a space-separated list and may be specified multiple times. Allow-listing By default the list contains the entries of allowed system call names.

MemoryDenyWriteExecute setting

Block the ability for systemd units to create or alter memory segments to become writable and executable as well with the unit setting MemoryDenyWriteExecute.

Summary

Why and when to use MemoryDenyWriteExecute The setting MemoryDenyWriteExecute will block the creation or alteration of a memory segment to become writable and executable as well. By enabling this limitation, it will increase the bar software exploits to change running code dynamically. Usage [Service] MemoryDenyWriteExecute=yes InaccessiblePaths=/dev/shm SystemCallFilter=~memfd_create Caveats To prevent circumvention of this setting, access to /dev/shm and the syscall memfd_create should be blocked as well. Generic advice For most common services this option can be implemented and will increase the security of a service.

InaccessiblePaths setting

Block systemd units to access specified paths with the unit setting InaccessiblePaths.

Summary

Why and when to use InaccessiblePaths The setting InaccessiblePaths defines paths that should never be accessible. Instead of using the principles of an allow list, it is an explicit deny list. Values Define the paths that are granted write access. [Service] InaccessiblePaths=/dev/shm When a path is prefixed with a minus (-), it is ignored if it does not exist When a path is prefixed with a plus (+), the path is considered relative to root of directory (e.

ReadWritePaths setting

Grant systemd units to specified paths to read from and write to new or existing files with the unit setting ReadWritePaths.

Summary

Why and when to use ReadWritePaths The setting ReadWritePaths grants read and write permissions to defined paths. It can be used in combination with other settings like ‘ProtectSystem=strict’ to make the full file system read-only, and then open up a few paths that are required for a service to run correctly. Values Define the paths that are granted write access. [Service] ProtectSystem=strict ReadWritePaths=/run /var/log/nginx When a path is prefixed with a minus (-), it is ignored if it does not exist When a path is prefixed with a plus (+), the path is considered relative to root of directory (e.

ProcSubset setting

Restrict systemd units to access information from the /proc directory with the unit setting ProcSubset.

Summary

Why and when to use ProcSubset The setting ProcSubset controls the “subset” mount option of /proc for the unit. Caveats This function does not if the “subnet” option for procfs is not supported. Generic advice The Linux kernel shares information from various kernel APIs via /proc. When activating this setting, these kernel APIs are also made unavailable, which might break common software, unless it is a trivial process. So this option is to be used with care.

ProtectProc setting

Restrict systemd units to access information from the /proc directory with the unit setting ProtectProc.

Summary

Why and when to use ProtectProc The setting ProtectProc aims to protect information that normally can be retrieved from /proc. Settings The value default, which is also the default, will not restrict access. Value invisible will hide information, where ptraceable restrict the set to only processes that be monitored with the system call ptrace(). The value noaccess is the most strict option. Caveats This setting will not have effect if the kernel does not support the hidepid mount option per individual mount point.

ProtectHome setting

Restrict systemd units to access data in home directories with the unit setting ProtectHome.

Summary

Why and when to use ProtectHome The setting ProtectHome aims to protect home directories. These three paths are included: /home /root /run/user Settings The default no will not restrict access to the home directories. Using yes will active full protection, not allowing access. The value read-only will make the paths read-only, so no data can be written to it. With tmpfs a temporary file system is being used, also read-only, yet it hides the actual home directories.

ProtectKernelLogs setting

Restrict systemd units to read or write to the kernel log ring buffer with the unit setting ProtectKernelLogs.

Summary

Background The Linux kernel exposes its kernel log ring buffer to userspace via /dev/kmsg and /proc/kmsg. When this setting is defined as yes, the capability CAP_SYS_MODULE will be removed from the capability bounding set. This means that all processes in the unit will no longer have access to the kernel log ring buffer. Generic advice For most common services access to the kernel log ring buffer is not need, therefore safe to disable (ProtectKernelLogs=yes).

ProtectKernelModules setting

Restrict systemd units to load kernel modules with the ProtectKernelModules unit setting.

Summary

Explanation Kernel modules can provide additional functionality when using a modular Linux kernel, which is applicable to most systems. When this setting is set to yes, it tries to prevent the unit from loading kernel modules. This is achieved by removing the CAP_SYS_MODULE from the capability bounding set. Generic advice Most units do not need the permission to load kernel modules, so typically a unit can be configured with ProtectKernelModules=true.

/etc/ssh/ssh_config

The configuration file /etc/ssh/ssh_config contains settings related to the OpenSSH client. Learn more about this file its configuration.

Summary

The file /etc/ssh/ssh_config is the main configuration file of the OpenSSH server daemon (sshd). Purpose It defines the system-wide settings for the SSH client. It can be overriden by storing settings in ~/.ssh/config that takes precedence. Configuration To learn more about the available configuration settings, have a look at the section OpenSSH client configuration.

/etc/ssh/sshd_config

The configuration file /etc/ssh/sshd_config contains settings related to the OpenSSH server daemon. Learn more about this file its configuration.

Summary

The file /etc/ssh/sshd_config is the main configuration file of the OpenSSH server daemon (sshd). Purpose It defines the primary set of settings, with the option of being overridden by configuration files from /etc/ssh/sshd_config.d/*.conf. Configuration To learn more about the available configuration settings, have a look at the section OpenSSH server configuration.