Revision as of 03:00, 15 November 2023

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

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 can only be used for services that work locally.

Feedback

Benefit to Fedora

Fedora services will get a significant security boost by default by avoiding or mitigatating 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

Default services should have no adverse impact and 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.

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

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

....

@@ Line 13: / Line 13: @@
 * Name: [[User:Sundaram| Rahul Sundaram]]
 * Email: metherid@gmail.com
 <!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
 * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
 == Current status ==
@@ Line 61: / Line 59: @@
 Fedora services will get a significant security boost by default by avoiding or mitigatating security vulnerabilities in these services.
-<!--
-     When a Change has multiple benefits, it's better to list them all.
-     Consider these Change pages from previous editions as inspiration:
-     https://fedoraproject.org/wiki/Changes/Annobin (low-level and technical, invisible to users)
-     https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo (low-level, but visible to advanced users)
-     https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration (primarily a UX change)
-     https://fedoraproject.org/wiki/Changes/NoMoreAlpha (an improvement to distro processes)
-     https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
--->
 == Scope ==
 * Proposal owners:
-<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
+  Pull requests to enable various security features to services available by default and other high profile services.
-* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
+* Other developers: Review PRs as needed
 * Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.
+* Policies and guidelines: N/A
-The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
+* Trademark approval: N/A
-* Policies and guidelines: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. Please submit a pull request with the proposed changes before submitting your Change proposal. -->
-* Trademark approval: N/A (not needed for this Change)
-<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
-* Alignment with Community Initiatives:
-<!-- Does your proposal align with the current Fedora Community Initiatives: https://docs.fedoraproject.org/en-US/project/initiatives/ ? It's okay if it doesn't, but it's something to consider -->
 == Upgrade/compatibility impact ==
-<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
+Packages will automatically get additional security features enabled by default transparently.
-<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 == How To Test ==
-<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.
-Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.
-A good "how to test" should answer these four questions:
-. What special hardware / data / etc. is needed (if any)?
-. How do I prepare my system to test this change? What packages
-need to be installed, config files edited, etc.?
-. What specific actions do I perform to check that the change is
-working like it's supposed to?
-. What are the expected results of those actions?
--->
-<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+Default services should have no adverse impact and 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.
 == User Experience ==

Search

Changes/SystemdSecurityHardening: Difference between revisions