From Fedora Project Wiki
(Initial page)
 
Line 1: Line 1:
= Enabling composefs by default for Fedora Atomic Desktops and Fedora CoreOS =
= Enabling composefs by default for Atomic Desktops, CoreOS and IoT (ToBeConfirmed) =


{{Change_Proposal_Banner}}
{{Change_Proposal_Banner}}

Revision as of 16:05, 10 June 2024

Enabling composefs by default for Atomic Desktops, CoreOS and IoT (ToBeConfirmed)

Important.png
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

We want to enable composefs by default for Fedora Atomic Desktops and Fedora CoreOS. This makes the root mount of the system (/) a truly read only filesystem, increasing the system integrity and robustness. This is the first step toward a full *at runtime* verification of filesystem integrity.

This change will be enabled only for the Bootable Container images of Fedora Atomic Desktops and not the classic ostree ones.

Owner

Current status

  • Targeted release: Fedora Linux 41
  • Last updated: 2024-06-10
  • [Announced]
  • [<will be assigned by the Wrangler> Discussion 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

Ostree based systems currently have /usr mounted as read-only and managed by ostree/rpm-ostree. The integrity of the content of /usr is only validated by ostree/rpm-ostree during updates and deployment operations, but not at "runtime". If a file is corrupted on disk (maliciously or not), it will only be detected if a full check is performed using ostree fsck.

On those systems, the runtime root (/) of the system is currently mounted as read-write but with the immutable bit set (chattr +i /) to prevent accidental modifications.

composefs is a new project that combines several existing filesystems (overlayfs, EROFS) to provide a very flexible mechanism to support read-only mountable filesystem trees, stacking on top of an underlying "lower" Linux filesystem.

Using composefs, it will no longer be possible to mutate the underlaying file content that is part of the system (/usr) nor the layout of the root directory. It will result in I/O errors at the kernel level.

The content is /etc and /var will remain writtable as it is today.

This change is part of the Fedora Bootable Containers Initiative. The bootc container images already enable composefs thus this change is to align existing variants to the new Bootable Containers defaults.

It is tracked in:

This is the first step toward a full boot chain integrity, that will requiring signing the composefs metadata during composes and using Unified Kernel Images (UKI). See: https://gitlab.com/fedora/bootc/tracker/-/issues/14

Feedback

Nothing specific so far.

We have the following "known issues":


Benefit to Fedora

This will increase the robustness of image based Fedora systems and prepare them for future increased security guarantees.

This will align the existing image based variants of Fedora (Atomic Desktops, CoreOS, IoT) to the work that is done as part of the Bootable Containers Initiative.


Scope

  • Proposal owners:
    • Enable composefs in Atomic Desktops (bootable containers only)
    • Enable composefs in CoreOS
    • Enable composefs in IoT (To Be Confirmed)
  • Other developers:
    • Applications doing disk-full checks on / will have to be updated to look at other places as / will be small (a few MB) and full (100% used).
  • Release engineering: N/A (not needed for this Change)
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy 2028:
    • Aligns with the goal: "Immutable variants are the majority of Fedora Linux in use"

Upgrade/compatibility impact

To be fleshed out


Early Testing (Optional)

Do you require 'QA Blueprint' support? N

How To Test

  • Make sure that you do not rely on Dual Boot support
  • Make sure that you bootloader is recent enough to support BLS configs
  • Remove ostree-grub2 from the upcoming deployment: rpm-ostree override remove ostree-grub2
  • Enable composefs: sudo ostree config set ex-integrity.composefs yes
  • Update your system to a new version: rpm-ostree update
    • Or do a manual (re)deploy of the current version: sudo ostree admin deploy fedora/39/x86_64/silverblue
  • Reboot into the new deployment


User Experience

The main visible change will be that the root filesystem (/) is now small and full (a few MB, 100% used). The real root is mounted in /sysroot and most of the data is stored in /var.


Dependencies

For the Atomic Desktops, this change depends on:

CoreOS and IoT (To Be Confirmed) already do not depends on ostree-grub2.


Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) Undo the change. It's a single line change in a configuration file.
  • Contingency deadline: Beta Freeze / Release Freeze
  • Blocks release? No

Documentation

To be written.


Release Notes

To be written once the change is accepted.


Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/ComposefsAtomicCoreOSIoT&oldid=712333"