Building a hardened personal Linux OS with only proven tools, and why I ultimately abandoned cryptographic rootfs protection
An independent developer built RoamSwitch OS, a hardened Linux distribution using proven security tools like AppArmor and fapolicyd. The project aimed to embed hardening at the OS level but ultimately rejected cryptographic rootfs protection due to technical and practical constraints.
In the world of Linux security, an independent developer has taken a bold step: building a hardened operating system from the ground up. The result is RoamSwitch OS, a custom distribution that layers proven security tools directly into the OS rather than adding them on top as a user‑space application. The project began with the goal of tightening every layer of the system, from the kernel to the user environment, and ended with a pragmatic decision to abandon cryptographic root‑filesystem protection.
Why Build an OS Instead of an App?
RoamSwitch, the defensive security app that originally ran on top of existing Linux distributions, offers firewall control, port monitoring, and ransomware detection. However, as a user‑land application it can only reach so far. Misconfigurations baked into the operating system or weak kernel defaults are outside its scope. By creating a hardened OS, the developer could embed hardening from the kernel upward, ensuring that defaults and configurations are secure from the start.
Core Design Principles
RoamSwitch OS is built on Arch Linux, packaged as a bootable ISO via archiso. The developer deliberately avoided reinventing the wheel, choosing to layer hardening on top of a standard Arch install rather than creating a new distribution from scratch. The plan was to use well‑tested tools—AppArmor, fapolicyd, auditd, Falco/Tetragon, Landlock, AIDE, and TPM2—to provide a comprehensive security stack.
One major design decision was to reject an immutable, image‑based OS model like Fedora Silverblue or ChromeOS. An immutable OS would require regenerating a single root‑filesystem image and updating the bootloader every time a package changed—an engineering effort far beyond the project’s scope. Instead, the developer kept the rolling‑release nature of Arch, allowing frequent updates without the overhead of rebuilding a monolithic image.
Implementation Details
The OS is implemented as a Rust workspace containing about 39 crates. Each crate produces a binary that implements a specific defensive feature. Most of these binaries run as systemd services that start at boot, while others are triggered by timers for periodic tasks such as firmware checks or compliance scans.
Modules communicate through shared state in /var/lib/roamswitch/, including a unified incident timeline stored in os_hardening_incident_timeline.json. This file is appended to by multiple modules—such as exfil‑guard, mitm‑guard, honeytokens, and forensic‑sweep—providing a single source of truth for security events. The ransomware‑rollback module monitors this timeline and triggers a snapshot when it detects a critical event, ensuring that the system can recover from ransomware attacks.
Key Security Features
- Forensic Sweep: Monitors persistence surfaces like cron, systemd units, and shell rc files for unauthorized changes.
- Honeytokens: Deploys decoy credential files and fake listeners that log any access, enabling early detection of malicious activity.
- fapolicyd‑mgr: Implements application allowlisting based on pacman‑managed file hashes, providing a practical substitute for IMA appraisal.
- Exfil‑Guard: Correlates bursts of sensitive file access with outbound network activity, using netlink diagnostics to track byte counts.
- Mitm‑Guard: Detects ARP cache poisoning and DHCP spoofing with a sandboxed, passive bettercap child process.
- Privacy‑Guard: Randomizes MAC addresses and checks DNS resolution to prevent traffic analysis.
- Wireless‑Guard: Detects Wi‑Fi evil‑twin attacks by comparing baseline scans with current network conditions.
- Ransomware‑Rollback: Watches for rename/rewrite bursts, unfamiliar file extensions, and entropy spikes, then takes an automatic btrfs/LVM snapshot.
Why Cryptographic Rootfs Protection Was Abandoned
Two Linux mechanisms—dm‑verity and IMA appraisal—were considered for cryptographic root‑filesystem integrity. dm‑verity operates at the block level and requires a static, immutable image, which conflicts with Arch’s rolling‑release model. IMA appraisal, which stores signed hashes in extended attributes, was not enabled in either the standard or hardened Arch kernels. Enabling it would have required building and maintaining a custom kernel, a task that contradicted the project’s principle of using existing, proven tools.
Instead, the project relies on application allowlisting (fapolicyd‑mgr) and file‑hash monitoring (AIDE) to detect unauthorized binaries. AIDE is scoped to critical directories like /etc, /usr/bin, and /usr/lib/systemd to keep checks fast, while the timeline seal uses TPM2 to cryptographically sign the incident log, providing tamper evidence for a narrow, high‑value target.
What Actually Stops Ransomware?
For ransomware that encrypts user files, the key defense lies in behavior detection rather than cryptographic integrity. Honeytokens catch any process that touches decoy files, ransomware‑rollback reacts to sudden bursts of file modifications, and exfil‑guard intercepts the “steal first, encrypt second” pattern before encryption begins. These mechanisms do not rely on entropy spikes, making them effective even against intermittent encryption tactics that only modify parts of a file.
In summary, RoamSwitch OS demonstrates that a hardened Linux distribution can be built by composing existing security tools. While cryptographic root‑filesystem protection was ultimately set aside due to practical constraints, the OS still offers robust, behavior‑based defenses against modern ransomware and other threats.
Why it matters
By embedding hardening at the OS level, developers can ensure secure defaults and reduce the attack surface before an application even runs, offering stronger protection against sophisticated threats like ransomware.
Key points
- RoamSwitch OS layers proven security tools on Arch Linux without reinventing the wheel.
- It uses a Rust workspace with 39 modules, each running as systemd services or timers.
- Key features include forensic sweep, honeytokens, application allowlisting, and ransomware rollback.
- Cryptographic rootfs protection was rejected due to dm‑verity’s immutability and IMA’s absence in Arch kernels.
- Behavior‑based detection (honeytokens, rollback, exfil‑guard) effectively counters ransomware, even intermittent encryption.
Frequently asked questions
Is RoamSwitch OS ready for production use?
No. It is still a research and showcase project, tested on real hardware and QEMU, but it lacks third‑party penetration testing and legal review.
Why not use an immutable OS like Fedora Silverblue?
An immutable OS would require regenerating a single root‑filesystem image for every package update, which conflicts with Arch’s rolling‑release model and would be too costly for this project.
Can I use RoamSwitch OS on my existing system?
The OS is distributed as a bootable ISO; it can be installed on a machine, but it is not yet designed for seamless upgrades or integration with existing setups.
