Update Hardening
parent
b7aefb4f0f
commit
32be7bddb1
31
Hardening.md
31
Hardening.md
@ -2,6 +2,10 @@
|
||||
|
||||
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](https://cisecurity.org). 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](https://learn.cisecurity.org/benchmarks) serves as a guiding policy for configuration changes that distinguish HalogenOS from a typical Gentoo installation. Additionally, their [Docker Benchmark v1.8.0](https://learn.cisecurity.org/benchmarks) 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.
|
||||
@ -33,7 +37,7 @@ If the hardware running HalogenOS is properly manufactured and configured, it sh
|
||||
- Secure Boot with encrypted, locally generated keys
|
||||
- dm-verity enabled for system partition
|
||||
- squashfs based system images
|
||||
- LUKS encryption enabled for user partition
|
||||
- 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
|
||||
@ -45,13 +49,27 @@ Various controls on the kernel's networking stack, filesystem stack, and on some
|
||||
|
||||
- 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
|
||||
- Integrity of symlinks to system partition enforced by the kernel
|
||||
- sshd not included
|
||||
- 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
|
||||
|
||||
@ -70,6 +88,7 @@ Applications are run in sandboxes by default so they do not make undesired modif
|
||||
- Distrobox with gvisor for container work
|
||||
- Hardened Docker configuration
|
||||
- BubbleWrap for arbitrary binary sandboxing
|
||||
- KVM, libvirt, and Qemu for virtualization
|
||||
|
||||
## Applications
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user