Notions de sécurité

Avant de régler le durcissement d’un hôte, il faut comprendre ce que protège le module darkone.system.security et comment il décide d’activer une protection. Cette page rassemble toutes les notions utiles pour paramétrer la sécurité en confiance.

Le durcissement suit le référentiel ANSSI BP-028 🡕 (GNU/Linux). Chaque recommandation porte un code (R30, C4…) et s’active automatiquement selon le niveau et la catégorie de la machine.

Deux pages complémentaires

Cette page explique les concepts. Le catalogue des règles liste ce qui s’active à chaque niveau, et la page Sécurité et durcissement décrit la mise en œuvre au quotidien.

Une philosophie : le durcissement progressif

La sécurité n’est pas un interrupteur, c’est un curseur. On part d’un socle sûr pour tous, puis on renforce là où le risque le justifie. Trois principes guident chaque règle.

Principe	Idée	Exemple dans DNF
Défense en profondeur	Empiler les barrières, aucune n’est seule	Pare-feu, isolation des services, chiffrement
Moindre privilège	Donner juste ce qu’il faut, rien de plus	sudo ciblé, services sans droits root
Surface d’attaque réduite	Moins de code exposé, moins de failles	Services obsolètes coupés, ports surveillés

Les cinq leviers d’activation

Une règle s’applique si, et seulement si, toutes ces conditions sont réunies. Ce sont les seuls réglages à connaître.

Levier	Rôle
enable	Active le module (activé par défaut sur tous les hôtes)
level	Le niveau visé : plus il est haut, plus de règles s’activent
category	Le type de machine : ajoute les règles propres au poste ou au serveur
excludes	Des étiquettes qui coupent un groupe de règles incompatibles
exceptions	Une règle précise contournée, avec justification obligatoire

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

Comment une règle se décide

Règle active si : le module est activé et le niveau courant atteint la sévérité de la règle et la catégorie correspond et aucune étiquette d’exclusion ne s’applique et aucune exception n’est posée.

Les quatre niveaux

Les niveaux sont cumulatifs : chaque palier ajoute ses règles à celles des paliers inférieurs. On monte progressivement, en testant chaque hôte.

Niveau	Pour quoi	Coût / contraintes
minimal	Socle commun, tout système (défaut)	Quasi nul, transparent
intermediary	Recommandé pour presque tous les systèmes	Faible, quelques ajustements
reinforced	Systèmes sensibles ou multi-utilisateurs	Réel : isolation, MAC, auditd
high	Compétences et budget dédiés	Élevé : recompilation du noyau

Les trois catégories

La catégorie sélectionne des sous-ensembles de règles selon l’usage de la machine. Elle est indépendante du niveau.

Catégorie	Machine visée	Ajoute notamment
base	Universelle, toujours appliquée	Toutes les règles communes
client	Poste de travail (écran, USB, session)	USBGuard, verrouillage de session
server	Serveur (services exposés)	Isolation réseau, supervision des services

État actuel : catégorie base partout

Aujourd’hui, tous les hôtes tournent en minimal / base par défaut. Le rattachement automatique d’une catégorie à chaque profil (poste → client, serveur → server) n’est pas encore câblé. La catégorie conseillée par profil reste à fixer à la main pour l’instant.

Le glossaire des notions ANSSI

Les protections du module reposent sur des mécanismes Linux standards. Voici ceux qu’il faut connaître pour lire le catalogue des règles.

Amorçage et matériel

Notion	À quoi ça sert
Secure Boot 🡕	N’autorise au démarrage que du code signé (anti-rootkit)
LUKS2 🡕	Chiffre le disque : vol de machine = données illisibles
IOMMU 🡕	Isole les accès mémoire des périphériques (anti-DMA)
Mot de passe du chargeur	Empêche de modifier le démarrage sans authentification

Noyau

Notion	À quoi ça sert
sysctl 🡕	Réglages noyau qui ferment des comportements risqués
LSM 🡕	Modules de sécurité greffés dans le noyau
Lockdown 🡕	Verrouille les accès directs au noyau (mémoire, kexec)
Yama 🡕	Restreint ptrace (un process ne peut pas en espionner un autre)
Modules signés	Refuse de charger un pilote noyau non signé
linux_hardened 🡕	Noyau précompilé avec des protections renforcées

Comptes et authentification

Notion	À quoi ça sert
PAM 🡕	La chaîne qui valide chaque authentification
yescrypt 🡕	Algorithme moderne de stockage des mots de passe
pam_faillock	Bloque le compte après plusieurs échecs (anti force brute)
Comptes non mutables	Les comptes sont déclarés en config, pas créés à la volée
Moindre privilège sudo	Droits d’administration ciblés, tracés, sans négation

Services et confinement

Notion	À quoi ça sert
MAC 🡕	Contrôle d’accès obligatoire (AppArmor) : un service ne sort pas de son bac à sable
Isolation systemd	ProtectSystem, namespaces, capacités réduites par service
Capabilities	Donner un droit précis (ex. ouvrir un port) sans tout root
setuid minimal	Réduire les binaires qui s’exécutent en root

Réseau

Notion	À quoi ça sert
nftables 🡕	Le moteur de pare-feu (DNF est en refus par défaut)
Filtrage sortant (egress)	Bloque ce que la machine a le droit de contacter
DNSSEC 🡕 / DoT 🡕	Résolution DNS authentifiée et chiffrée
NTS 🡕	Synchronisation de l’heure authentifiée
Surface réseau réduite	Surveille et limite les ports en écoute

Journalisation et intégrité

Notion	À quoi ça sert
Journaux persistants scellés	Traces inviolables, conservées au redémarrage
auditd 🡕	Enregistre les appels système sensibles
Scellement / HIDS	Vérifie qu’aucun fichier système n’a été altéré

Les étiquettes d’exclusion

Certaines règles cassent un usage légitime. On les neutralise par étiquette dans excludes, sans descendre le niveau global.

Étiquette	Ignore
kernel-recompile	Le durcissement noyau à la compilation (R15 à R27, C1)
no-ipv6	La désactivation d’IPv6 (R13, R22)
no-mac	Le contrôle d’accès obligatoire (R37, R45)
no-auditd	auditd (R73)
needs-jit	Le W^X strict (Java, .NET, V8, WebAssembly)
needs-hibernation	La coupure de l’hibernation (ordinateurs portables)
needs-usb-hotplug	USBGuard (postes à branchements USB fréquents)

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

Les exceptions justifiées

Pour contourner une règle précise sans toucher au reste, on pose une exception avec une justification (obligatoire, tracée dans la configuration).

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

Exception structurelle : SELinux

Les règles R46 à R49 (SELinux) sont exceptées d’office : SELinux n’est pas supporté sur NixOS. AppArmor (R45) joue le rôle de MAC.

Les effets de bord à anticiper

Monter un niveau peut gêner un usage courant. Les principaux pièges :

À tester avant la production

• noexec /tmp, désactivation IPv6, modules non signés peuvent casser des applications ou des périphériques.
• Le filtrage sortant (egress) coupe les téléchargements directs : prévoir un relais ou une liste blanche.
• Le verrouillage auditd (-e 2) rend la configuration immuable : un changement de règles exige un redémarrage.

Chaque fichier de règle documente ses effets de bord dans des commentaires sideEffects. Le catalogue des règles en donne la vue d’ensemble par niveau.

Voir aussi

• Catalogue des règles de sécurité : ce qui s’active à chaque niveau et catégorie
• Sécurité et durcissement : la mise en œuvre au quotidien
• Référence des modules de sécurité : toutes les options exposées par le code