Fedora Atomic Tests

fedora_atomic_tests.md

"Atomic" describes how the system is built and updated, and it's the main reason Kinoite is harder to break or tamper with than a traditional install.

What "atomic" means

On regular Fedora or Ubuntu, updates change packages one at a time on the live system. If the update is interrupted, or a package misbehaves, you can end up with a half-updated, inconsistent system.

Kinoite works differently. The core OS (everything under /usr) is a single versioned image, managed by rpm-ostree. An update builds a complete new image alongside the current one, and you switch to it on the next boot. The change is all-or-nothing, which is what "atomic" means: you're either on the old version or the new one, never something in between.

This has several practical consequences:

• The system is read-only. /usr is mounted read-only, so malware (or a careless command) can't quietly modify system binaries, even with some elevated access.
• Rollback is built in. The previous image stays on disk. If an update causes problems, you pick the old entry in the boot menu or run rpm-ostree rollback.
• Apps are kept separate from the OS. Desktop apps come as Flatpaks, which are sandboxed, and command-line development work happens in containers via Toolbox. Your base system stays clean and identical to what Fedora tested.
• Your changes live elsewhere. /etc (configuration) and /var (data, including /home) are writable and carried forward between images.

Kinoite and Silverblue are now grouped under the name "Fedora Atomic Desktops."

How to check it's more secure

You can't really measure "more secure" with a single test, but you can verify that each protection is actually working. Here's what to check.

Confirm the read-only system

sudo touch /usr/test

This should fail with "Read-only file system." Then check your deployments:

rpm-ostree status

This lists your current image and the previous one you can roll back to.

Confirm SELinux is enforcing

getenforce
sestatus

getenforce should say Enforcing. SELinux is a big part of Fedora's security advantage, so if it's set to permissive, fix that first.

Check Secure Boot and disk encryption

mokutil --sb-state
lsblk -f

mokutil should report SecureBoot enabled. In the lsblk output, look for crypto_LUKS on your main partition, which means disk encryption is on.

Check the firewall zone

This one needs attention. Fedora's desktop default zone is fairly permissive.

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --list-all

If it says FedoraWorkstation, that zone allows incoming connections on ports 1025–65535 so local-network features just work. For a tighter setup, switch to the public zone, which only allows a few services:

sudo firewall-cmd --set-default-zone=public

If something like KDE Connect stops working afterward, you can open just the ports it needs.

See what's listening on the network

sudo ss -tulpn

Ideally you'll see very little beyond localhost addresses.

Review Flatpak sandbox permissions

In System Settings, look under Flatpak Permissions (or install Flatseal). Check that apps don't have broader access than they need, such as full home-folder or filesystem access.

Score service sandboxing

systemd-analyze security

This rates each system service's sandboxing from "OK" to "UNSAFE." It's useful for seeing where exposure remains, though many services score poorly on every distro.

Run a Lynis audit

On Kinoite you'd normally avoid layering packages into the base image, so run Lynis straight from its source instead:

git clone https://github.com/CISOfy/lynis
cd lynis
sudo ./lynis audit system

It gives a hardening index and a list of suggestions. Don't run it inside a Toolbox, because that would audit the container rather than your actual system. Treat the score as a to-do list rather than a direct comparison with other distros, since Lynis doesn't fully account for things like the read-only root or Flatpak sandboxing.

Turn on automatic updates

A secure system is only as good as its patch level. Discover can update automatically (Settings → Updates), or you can have rpm-ostree stage updates in the background. Edit /etc/rpm-ostreed.conf so it contains:

[Daemon]
AutomaticUpdatePolicy=stage

Then enable the timer:

sudo systemctl enable --now rpm-ostreed-automatic.timer

Updates will download and stage quietly, and apply on your next reboot.