System Hardening

A number of different methods are employed to make HalogenOS more resistant to exploits and tampering, and are explained below.

Compliance

HalogenOS is developed to conform to best-practice baselines such as those offered by the Center for Internet Security. While the CIS does not offer benchmarks for Gentoo or Gentoo-based distributions, many of the controls described in these benchmarks can be applied to other distributions with some modifications. The Debian Linux 12 Benchmark v1.1.0 serves as a guiding policy for configuration changes that distinguish HalogenOS from a typical Gentoo installation. Additionally, their Docker Benchmark v1.8.0 is followed as closely as possible, since Docker is included as system software.

Build Settings

These are configurations performed during the compilation stage. All the settings here apply strictly to binaries which ship within the HalogenOS image, not to binaries downloaded via Flatpak or Distrobox.

Gentoo hardened compiler & flags
SELinux support included
X11 and systemd support disabled
Musl libc used instead of GNU libc (glibc)

Kernel

The kernel has been configured to utilize several security features that limit what APIs processes can use and which side channels might be available to leak information.

Kernel Self Protection Project enabled
Signed kernel module loading only
Quiet boot parameter
Common CPU vulnerabilities mitigated when possible
Lockdown mode set to confidentiality
SELinux enabled
Unnecessary modules blacklisted
Memory re-initialization on alloc() and free()

Full Verified Boot

If the hardware running HalogenOS is properly manufactured and configured, it should provide a reasonably strong guarantee that software on the system is in a known good state. For more information, go read the full article on Verified Boot.

Checks & reports on hardware/firmware security
Unified Kernel Image boot
Secure Boot with encrypted, locally generated keys
dm-verity enabled for system partition
squashfs based system images
LUKS encryption enabled for user partition, locally generated keys
TPM2 based automatic unlocking
Automatic repair in case of tampering
User alerted if hardware security baseline changes
Kernel-based file integrity for volatile files

Configuration

Various controls on the kernel's networking stack, filesystem stack, and on some userland components like malloc further reduce attack surface.

Hardened sysctl values
hardened_malloc used by default
Root logon disabled
No superuser access on production builds
System files on mutable partitions are only accessible by root
Integrity of symlinks from mutable partitions to the system partition enforced by the kernel
sshd support disabled in all compiled code
Restrictive umask configured
Faillock enabled for 15 minutes after 3 failed attempts
System version omitted from issue/banner/motd

Partition Table

The partition table is carefully designed to prevent resource exhaustion, setuid exploits, information leakage, and other exploits.

Immutable system partition running from a squashfs image
Optional vendor overlay partition for signed system overlays
Separate /home and /var partitions
nosuid and nodev set for non-root partitions
noexec set for world-writable directories like /tmp
Mutable partitions are encrypted and hence unmodifiable outside the running system
/tmp mounted as in-memory tempfs
User home directories individually encrypted

Updates

System updates are fully verified as well. In a secure build, signatures are required and the system will not install an unsigned or improperly signed update or overlay.

Signed image updates
Signed system overlays
OTA updates performed strictly over HTTPS
Failed or tampered updates cause failover to known-good system slot

Sandboxing

Applications are run in sandboxes by default so they do not make undesired modifications or read files without authorization.

Flatpak centered package management
Distrobox with gvisor for container work
Hardened Docker configuration
BubbleWrap for arbitrary binary sandboxing
KVM, libvirt, and Qemu for virtualization

Applications

The default applications have been selected with security as a first priority. Also, smaller implementations are preferred to minimize the trusted computing base (TCB) of the system.

KDE desktop environment
Wayland display compositor
Trivalent browser
OpenRC init system