systemd avancé : units et targets

Prérequis : cours DevOps 1.2 (bases systemd) ; utilisateurs et services.

Pourquoi

Le cours DevOps posait les bases ; ici l'exploitation avancée : dépendances fines, targets, sandboxing, instances multiples. C'est ce qui sépare « ça tourne » de « c'est opéré ».

Concepts

• Types d'units : .service (processus), .timer (planifié), .socket (activation à la connexion !), .target (état/regroupement, ex. multi-user.target), .mount/.automount.
• Dépendances : After/Before (ordre), Requires (fort : échec = échec), Wants (faible : essaie). After sans Requires n'assure PAS le démarrage de l'autre !
• Activation par socket : le service démarre à la première connexion (économie) + file d'attente tenue par systemd. Idéal pour services rares.
• Sandboxing : ProtectSystem=strict, ProtectHome=true, PrivateTmp=true, NoNewPrivileges=true, ReadWritePaths= : l'app compromise ne voit presque rien. Progressif : systemd-analyze security mon-app note de 0 à 10 !

Exemple : durcir pas à pas

[Service]
User=monapp
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
NoNewPrivileges=true
ReadWritePaths=/opt/monapp /var/log/monapp

Tester après chaque ligne (certaines apps ont besoin de /proc, /dev/log… : ReadWritePaths/BindPaths pour ajuster).

Cas réel

App compromise via upload (RCE) : avec sandboxing strict, l'attaquant voit un FS vide + pas de home + pas de nouveaux privilèges → impasse, juste des logs. Sans : clés SSH lues, rebond interne. Même faille, deux destins.

Pièges

• After seul en croyant exiger : ordonne sans exiger. Requires/Wants pour exiger.
• Sandboxing maximal d'un coup : app qui ne démarre plus, cause obscure. Progressif + systemd-analyze security comme guide.
• Restart=always + sandbox qui tue au démarrage : boucle de restart qui noie les logs. Stabiliser d'abord, durcir ensuite.

À retenir

After ordonne / Requires exige, socket pour le rare, sandbox progressif noté par systemd-analyze.