Changes/SystemdSecurityHardening

Enable systemd service hardening for default and high profile services

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

Improve security by enabling some of the high level systemd security hardening settings that isolate and sandbox default and high profile services.

Owner

• Name: Rahul Sundaram
• Email: metherid@gmail.com

• Targeted release: Fedora 40
• Last updated: 2023-11-15
• [<will be assigned by the Wrangler> devel thread]
• FESCo issue: <will be assigned by the Wrangler>
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

systemd provides a number of settings that can harden security for services. We are selecting a few high level toggles to enable by default. These need to be configured on a per service basis.

• PrivateTmp=yes
• ProtectSystem=yes/full/strict
• ProtectHome=yes
• PrivateDevices=yes
• ProtectKernelTunables=yes
• ProtectKernelModules=yes
• ProtectControlGroups=yes
• NoNewPrivileges=yes
• PrivateNetwork=yes

We will enable as many of these as feasible for the services but not every toggle is going to be applicable to every service. For example, ProtectHome=yes wouldn't work for any of the systemd user services, but ProtectHome=read-only might and PrivateNetwork=yes can only be used for services that work purely locally. Ideally we cover all the default services as well as some of the most commonly used services such as Nginx or PostgreSQL.

Benefit to Fedora

Fedora services will get a significant security boost by default by avoiding or mitigating security vulnerabilities in these services.

Scope

• Proposal owners: Pull requests to enable various security features to services available by default and other high profile services.
• Other developers: Review PRs as needed
• Release engineering: #Releng issue number
• Policies and guidelines: N/A
• Trademark approval: N/A

Upgrade/compatibility impact

Packages will automatically get additional security features enabled by default transparently.

How To Test

You can use tools like systemd-analyze security and systemctl cat to verify that the security features are enabled by default. Default services should have no adverse impact and users shouldn't have to do anything beyond using the software as intended and report any regressions. High profile services not installed by default that gain these security features would benefit from more targeting testing to spot any unintended consequences especially for niche or advanced functionality.

User Experience

This should be a fully transparent change for users.

Dependencies

None. We are merely enabling some long supported systemd features by default for default and high profile services.

Contingency Plan

• Contingency mechanism: These settings can be enabled/disabled at a per service level. No wholesale reverts is necessary. If we don't finish the work for all the services, we can follow through in future releases.
• Contingency deadline: N/A
• Blocks release? No

Documentation

• https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html
• https://www.redhat.com/sysadmin/systemd-secure-services
• https://www.redhat.com/sysadmin/mastering-systemd

N/A (not a System Wide Change)

Release Notes

systemd security hardening features are enabled for default services and following high profile services.

• Postgres
• Apache Httpd
• Nginx
• MariaDB

....