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é

La pile PAM, en pratique

Toute authentification du système passe par PAM, et R67 y greffe l’anti‑force‑brute. Comprendre la mécanique évite deux erreurs coûteuses : croire qu’une règle posée agit, et se verrouiller hors d’une machine.

Une pile PAM se lit de haut en bas, en quatre étapes indépendantes :

Étape	Question posée
auth	Le demandeur prouve‑t‑il son identité ?
account	Ce compte a‑t‑il le droit d’ouvrir une session maintenant ?
password	Sous quelles règles change‑t‑on le mot de passe ?
session	Que met‑on en place autour de la session ?

Dans chaque étape, NixOS ordonne les règles par un rang numérique. C’est ce rang, et lui seul, qui décide de ce qui agit : une règle placée après pam_deny est lue trop tard pour refuser quoi que ce soit.

Où pam_faillock se place

pam_faillock ne fonctionne qu’à trois règles, jamais une seule :

Règle	Étape	Rôle
preauth	auth, juste avant pam_unix	refuse d’emblée un compte déjà verrouillé
authfail	auth, juste après pam_unix	compte l’échec qui vient d’avoir lieu
account	account, en tête	bloque un compte verrouillé, quel que soit le moyen d’authentification

Les deux règles auth encadrent le pam_unix de la pile. Or ce rang varie d’un service à l’autre : 11700 sur su et sudo, 13100 sur login. DNF le calcule donc pour chaque service au lieu de le figer, sans quoi les deux règles atterrissent après pam_deny sur toutes les piles sauf une.

Les services couverts, et les deux exclus

sshd et l’écran GNOME sont volontairement hors pile

sshd en est exclu parce que DNF interdit l’authentification par mot de passe sur SSH : pam_faillock n’y compterait jamais rien, et sa règle account ne saurait qu’y refuser une session de secours par clé pour un verrou acquis à la console. L’accès de maintenance doit rester ouvert en toutes circonstances.

gdm-password en est exclu parce qu’il inclut la pile login en substack, laquelle porte déjà les trois règles : une seconde série compterait chaque échec deux fois, et le compte se verrouillerait au deuxième essai au lieu du troisième.

Restent login, su et sudo, les trois piles où un mot de passe est réellement soumis. Le compte nix, qui porte le déploiement, n’a aucun credential mot de passe : il ne peut pas être verrouillé, et reste donc le chemin de retour quand un compte humain l’est.

Lire la pile rendue, pas le module

Le rang effectif d’une règle ne se devine pas. Il se lit sur la configuration construite :

nix build .#nixosConfigurations.<hote>.config.system.build.etc
grep -E '^(auth|account)' result/etc/pam.d/sudo

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