Arch Linux is a good distribution, with a high amount of packages passing build reproducibility tests, providing transparency in trusting that the distributed binaries match the software source code. Also, maintainers keep good security practices and compile their packages with proper mitigations enforced by compiler flags, they also do a pretty good job at keeping packages closer to upstream software. This project aims to achieve Full Verified Boot while using Arch Linux.
Full Verified Boot is implemented using UEFI Secure Boot, TPM 2.0, and dm-verity. Kernel and initramfs are combined according to the Unified Kernel Image (UKI) specification. As well as the bootloader, the image combining kernel and initramfs is cryptographically validated by UEFI Secure Boot on every boot, ensuring the integrity and authenticity of the early boot chain. The immutable, read-only root partition is cryptographically validated by dm-verity at each boot, providing integrity and authenticity guarantees for the whole root partition. Any modification to the bootloader, the Unified Kernel Image or the root partition breaks an otherwise successful boot, enforcing a strict chain of trust. TPM 2.0 acts as a hardware root of trust, where user data decryption keys are only accessible if firmware and Secure Boot configurations match a known-good PCR-based measurement. The user data partition (/data) is the only writable and persistent area on disk. In the future, policies will strictly prevent execution from there. As a result, the entire executable surface of the system is cryptographically validated.
Regarding application security, aside from a Wayland compositor/window manager and some basic utilities, the only primary user-facing application is Chromium, and it has a strong sandboxing architecture by default and advanced, modern exploit mitigations, see. For example, Chromium uses PartitionAlloc as its secure memory allocator and deploys modern exploit mitigations such as Control Flow Integrity, shadow stacks, and memory tagging (on supported hardware). Beyond the browser's own great sandbox, the OS also ensures that Chromium is further restricted by AppArmor. Besides Chromium, some system services with higher attack surfaces, such as wpa_supplicant, are also confined by systemd's sandboxed services and AppArmor. Chromium will also be further hardened by patches from Trivalent and Vanadium (except patches specific to Android/GrapheneOS), and by running in JITless mode. In the future, Chromium's WebAssembly capabilities (even jitlessly) could even make it a secure, sandboxed runtime for C/C++/Rust/Go software compiled to WebAssembly, a growing trend.
In order to provide a flexible yet isolated working environment, virtual machines can be used with crosvm, a Rust-written VMM, on top of the KVM hypervisor. This VM provides local SSH access for development tasks using tools such as tmux, neovim, etc. This way, inside the VM, there's freedom and flexibility.
The kernel includes the hardening patches from the linux-hardened project. Additional hardening is also applied by sysctl flags and kernel boot parameters. Recommendations from the Kernel Self-Protection Project (KSPP), GrapheneOS, PaX/grsec, and the kernel-hardening-checker are also applied as possible.
USB and peripheral attack surface is minimized by configuring the kernel's USB subsystem to deny new USB device connections by default (this sysctl toggle is a feature of linux-hardened), mitigating malicious USB-based exploitation. A minimal SUID binary can be called to toggle this restriction (for a few seconds) via sysctl when the user needs. IOMMU enforcement is also enabled to protect against DMA attacks. Some known "DMA-prone" kernel modules (like thunderbolt) are removed too. A simple auto-reboot mechanism is also implemented to reboot the computer when it remains on the lock screen for too long without being unlocked, as a measure to put the user data partition back at rest, encrypted.
A stateful firewall is configured by default using iptables. The firewall permits only outgoing connections and drops incoming packets from connections initiated by remote hosts. This ensures that only locally initiated outbound traffic can establish new network connections, substantially reducing exposure to remote attacks. Unrelated to this, but additionally, the IPv6 implementation is disabled in the kernel to reduce attack surface, since IPv6 does not yet completely replace IPv4; it is better to keep only one implementation enabled, IPv4.
Secure DNS is configured system-wide using dnscrypt-proxy. Additionally, Chromium's own secure DNS resolver is configured to use DNS over HTTPS (DoH) using the AdGuardDNS DoH endpoint, which is reasonably privacy-respecting and blocks known ads and malicious domains. ECH/ESNI is also used by Chromium's DNS resolver in order to prevent certain ways of domain name leakage through unencrypted SNI. Finally, for secure network time syncing, the NTP/NTS client is ntpd-rs, a Rust-written project. Instead of the standard NTP protocol, NTS is used for secure and authenticated time syncing.