F40 Change Proposal: Move /var/run selinux-policy entries to /run (Self-Contained)

Move /var/run selinux-policy entries to /run

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.

Wiki
Announced

:link: Summary

Actual path for system runtime files moved from /var/run to /run some 10 years ago [1], but the policy has been managed since then in a way that keeps the old entries and have updates still with the incorrect path while the real path is handled by file equivalency feature. This can confuse sysadmins not to be sure which path should be actually used and can also effect in userspace tools not working properly [2].

[1] Features/UsrMove - Fedora Project Wiki

[2] 2241366 – Restorecon not working correctly

:link: Owner

:link: Detailed Description

The change actually means just replacing “/run = /var/run” file-context equivalency rules with “/var/run = /run”. While the change as such is quite simple, it can have effect on other components using their own selinux policy with file-context entries.

:link: Feedback

:link: Benefit to Fedora

Removing technical debt which originated 10 years ago. More straightforward handling of file-context entries in the /run filesystem.

:link: Scope

  • Proposal owners:

    • Add all relevant patches to upstream repository
    • Ensure the system boots with the targeted policy
    • Ensure the system boots with the mls policy
    • Ensure updates from older releases work, more specifically with custom selinux packages installed.
  • Other developers:

    • Developers of custom selinux policies need to confirm system updates work.
  • Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)

  • Policies and guidelines: No update required.

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with Objectives:

:link: Upgrade/compatibility impact

Users can be affected by this change if they use a local policy with file-context entries in /run which occurs quite rarely, but is possible.

:link: How To Test

  • Install a new system and check for error messages and audit records.
  • Update an existing system and check if all updates completed without an error.
  • Optionally, install and boot the selinux-policy-mls package.
  • Check for errors reported by dnf or rpm.

:link: User Experience

There should be no visible change for end users.

The change should be transparent, without any further action needed on the system. System admins may need to take an action based on compatibility with the changes.

:link: Dependencies

Components with a custom selinux policy: container-selinux pcp cockpit

:link: Contingency Plan

  • Contingency mechanism: Revert all changes in case of serious problems with updates.
  • Contingency deadline: 2024-02-06 (Branch Fedora Linux 40 from Rawhide)
  • Blocks release? No
  • Blocks product? No

:link: Documentation

To be added later.

:link: Release Notes

I wasn’t aware of that issue. 100% for the proposal if the release engineering impact check doesn’t suggest anything else. Some documentation for users with customized policies might be helpful, too.

Does it make sense to do dedicated testing on the Spins and the immutable desktops before introducing this? Or is ensured that they work in this respect the same way as Fedora Workstation? We have seen already differing issues among GUIs/desktops when it comes to SELinux especially with confined user accounts.

I tend to assume that /run usage does not differ among most desktops (except user mounting of devices maybe?), but immutable desktops on the other hand differ in their use of some directories - not sure if this applies here?

I believe spins will behave the same, but immutable systems may differ.

This change proposal has now been submitted to FESCo with ticket #3142 for voting.

To find out more, please visit our Changes Policy documentation.

As far as I know, this should not impact Fedora Atomic Desktops, CoreOS or IoT.