Security concepts

Before configuring the hardening of a host, you need to understand what is protected by the darkone.system.security module and how it decides to enable a protection. This page gathers all the useful concepts for configuring security with confidence.

Hardening follows the ANSSI BP-028 🡕 (GNU/Linux) standard. Each recommendation bears a code (R30, C4…) and is activated automatically according to the machine’s level and category.

A philosophy: progressive hardening

Security is not a switch, it’s a slider. Start from a safe foundation for everyone, then harden where the risk justifies it. Three principles guide every rule.

Principle	Idea	Example in DNF
Defense in depth	Stack barriers, none alone	Firewall, service isolation, encryption
Least privilege	Give just what’s needed, nothing more	Targeted `sudo`, services without root rights
Reduced attack surface	Less exposed code, fewer flaws	Outdated services disabled, ports monitored

The five activation levers

A rule applies if, and only if, all of these conditions are met. These are the only settings you need to know.

Lever	Role
`enable`	Activates the module (enabled by default on all hosts)
`level`	The targeted level: the higher it is, the more rules are activated
`category`	The machine type: adds rules specific to workstation or server
`excludes`	Labels that disable a group of incompatible rules
`exceptions`	A specific rule overridden, with mandatory justification

darkone.system.security = {
  enable   = true;
  level    = "intermediary";   # minimal | intermediary | reinforced | high
  category = "server";         # base | client | server
};

The four levels

Levels are cumulative: each tier adds its rules to those of lower tiers. You go up gradually, testing each host.

Level	What for	Cost / constraints
`minimal`	Common base, any system (default)	Nearly none, transparent
`intermediary`	Recommended for almost all systems	Low, a few adjustments
`reinforced`	Sensitive or multi-user systems	Real: isolation, MAC, auditd
`high`	Dedicated skills and budget	High: kernel recompilation

The three categories

The category selects subsets of rules according to the machine’s usage. It is independent of the level.

Category	Targeted machine	Notably adds
`base`	Universal, always applied	All common rules
`client`	Workstation (screen, USB, session)	USBGuard, session locking
`server`	Server (exposed services)	Network isolation, service monitoring

Glossary of ANSSI concepts

The module’s protections rely on standard Linux mechanisms. Here are the ones you need to know to read the rules catalog.

Boot and hardware

Concept	What it does
Secure Boot 🡕	Only allows signed code at boot (anti-rootkit)
LUKS2 🡕	Encrypts the disk: stolen machine = unreadable data
IOMMU 🡕	Isolates device memory access (anti-DMA)
Bootloader password	Prevents modifying the boot process without authentication

Kernel

Concept	What it does
sysctl 🡕	Kernel settings that close risky behaviors
LSM 🡕	Security modules hooked into the kernel
Lockdown 🡕	Locks direct kernel access (memory, kexec)
Yama 🡕	Restricts `ptrace` (a process cannot spy on another)
Signed modules	Refuses to load an unsigned kernel driver
linux_hardened 🡕	Precompiled kernel with enhanced protections

Accounts and authentication

Concept	What it does
PAM 🡕	The chain that validates each authentication
yescrypt 🡕	Modern password storage algorithm
`pam_faillock`	Locks the account after several failures (anti brute force)
Immutable accounts	Accounts are declared in config, not created on the fly
Least privilege `sudo`	Targeted, traced admin rights, without negation

Services and confinement

Concept	What it does
MAC 🡕	Mandatory Access Control (AppArmor): a service does not leave its sandbox
systemd isolation	`ProtectSystem`, namespaces, reduced capabilities per service
Capabilities	Grant a specific right (e.g. open a port) without full root
Minimal `setuid`	Reduce binaries that run as root

Network

Concept	What it does
nftables 🡕	The firewall engine (DNF is deny-by-default)
Egress filtering	Blocks what the machine is allowed to contact
DNSSEC 🡕 / DoT 🡕	Authenticated and encrypted DNS resolution
NTS 🡕	Authenticated time synchronization
Reduced network surface	Monitors and limits listening ports

Logging and integrity

Concept	What it does
Sealed persistent logs	Tamper-proof traces, preserved across reboots
auditd 🡕	Records sensitive system calls
Sealing / HIDS	Verifies that no system file has been altered

Exclusion labels

Some rules break legitimate usage. They are neutralized by label in excludes, without lowering the global level.

Label	Ignores
`kernel-recompile`	Kernel hardening at compilation (R15 to R27, C1)
`no-ipv6`	IPv6 disabling (R13, R22)
`no-mac`	Mandatory access control (R37, R45)
`no-auditd`	auditd (R73)
`needs-jit`	Strict W^X (Java, .NET, V8, WebAssembly)
`needs-hibernation`	Disabling hibernation (laptops)
`needs-usb-hotplug`	USBGuard (workstations with frequent USB connections)

darkone.system.security.excludes = [ "needs-jit" "no-ipv6" ];

Justified exceptions

To bypass one specific rule without affecting the rest, set an exception with a justification (mandatory, tracked in configuration).

darkone.system.security.exceptions = {
  R9.rationale = "Conteneurs rootless requis en développement.";
};

Side effects to anticipate

Raising a level may hinder common usage. Main pitfalls:

Each rule file documents its side effects in sideEffects comments. The rule catalog provides an overview by level.