« Previous 1 2
Harden services with systemd
A Hard Nut to Crack
Capabilities
Finally, you can limit the capabilities that will be available to the process. These are rights that can be granted to unprivileged processes in small chunks, which makes it unnecessary to give a process completely unrestricted superuser rights just because it needs a single special right.
You can take a fairly restrictive approach here and define
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_DAC_READ_SEARCH
which excludes, for example, the assignment of CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, or CAP_SYS_PTRACE to the process and deducts many points. The exposure value now drops to 5.7 (Figure 4). The rating now confirms a MEDIUM
level of security, and for the first time the emoji now looks neutral and no longer unhappy about the situation.
Figure 4: For the first time, the emoji is not dissatisfied: You have achieved a medium level of security.
Conclusions
Quite a few options are yet left to provide additional security. A good compilation of all systemd options suitable for hardening services and that open up a wide field for further optimizations is provided in a description on GitHub [1]. With systemd-analyze as a measuring tool, you can track your progress in each case.
Infos
- Hardening options for systemd services: https://gist.github.com/ageis/f5595e59b1cddb1513d1b425a323db04
« Previous 1 2
Buy this article as PDF
(incl. VAT)
Buy ADMIN Magazine
US / Canada
UK / Australia
Related content
-
Logging with systemd
In most cases, log messages are managed by a Syslog server. The Fedora project wants to take a new approach in future releases. This change is to come from systemd’s journal.
-
The achievements of and plans for systemd
We talked to systemd maintainer Lennart Poettering about the sense and purpose of some systemd features. -
Systemd network management and container handling
Version 219 of the controversial systemd init system introduces a number of comprehensive changes. We take a closer look at the innovations in network management and container handling. -
networkd and nspawn in systemd
Version 219 of the controversial init system, systemd, comes with a few major changes. We look at the new features in network management and container handling. -
To syslog or not to syslog
In most cases, log messages are managed by a Syslog server. The Fedora project wants to take a new approach in future releases. This change is to come from systemd's journal.