System Hardening

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

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

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
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
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
nosuid set for non-system partitions
noexec set for /tmp
Root logon disabled
No superuser access on production builds
System files on non-system partitions only accessible by root
sshd disabled

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
Updates performed over HTTPS

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

Applications

The default applications have been selected with security as a first priority.

GNOME desktop environment
Wayland display compositor
Trivalent browser