Exécuter avec le principe du moindre privilège et discipliner sudo

La plupart des failles de sécurité dans l’automatisation ne sont pas dues à des exploits complexes, mais au fait que les scripts s’exécutent avec davantage de privilèges que nécessaire. Une tâche cron exécutée en tant que root qui doit seulement faire tourner un fichier journal est un accident imminent.

Le principe du moindre privilège affirme que chaque processus doit fonctionner uniquement avec les permissions nécessaires à sa tâche — et aucune de plus. Dans les scripts Bash, cela signifie :

• S’exécuter avec un utilisateur non privilégié chaque fois que possible
• Élever les privilèges vers root uniquement pour les commandes précises qui l’exigent
• Abandonner les privilèges dès que le travail privilégié est terminé
• Ne jamais stocker ni hériter d’identifiants au-delà de leur portée

Cette leçon présente les techniques concrètes : limitation de la portée de sudo, abandon de privilèges avec su, contrôles de validation de l’UID et renforcement de sudoers — afin de construire un modèle discipliné de gestion des privilèges pour les scripts de production.

Avant tout bloc de code qui nécessite réellement root, votre script doit vérifier qu’il s’exécute avec l’UID effectif attendu. Ne partez jamais du principe que c’est le cas ; vérifiez-le toujours.

$EUID est une variable spéciale de Bash qui contient l’identifiant utilisateur effectif du processus actuel. Root a toujours l’EUID 0. Le vérifier au début d’un script — ou autour d’un bloc privilégié — empêche une exécution accidentelle sous la mauvaise identité.

Utilisez ce modèle de contrôle :

Certains scripts ont légitimement besoin de root. Dans ce cas, le contrôle est inversé : échouez immédiatement si root est absent, plutôt que de laisser le script atteindre un appel système privilégié et produire une erreur de permission déroutante en cours d’exécution.

Associer la sortie anticipée à un message d’utilisation utile rend les scripts explicites :

L’erreur la plus courante consiste à placer sudo au début d’un script, puis à tout exécuter en tant que root. Appliquez plutôt sudo uniquement à la commande précise qui en a besoin — tout le reste s’exécute avec votre utilisateur normal.

Cela limite l’étendue des dommages : si un attaquant injecte du code dans votre script, il ne peut exécuter avec les permissions root que les parties précédées de sudo.

Comparez les deux modèles ci-dessous. Le second est nettement plus sûr :

L’appel à sudo somecommand dans un script n’est sûr que si le fichier sudoers est configuré pour autoriser exactement cette commande — et rien de plus. Évitez les règles telles que ALL=(ALL) NOPASSWD: ALL pour les comptes de service.

Limitez plutôt les règles à des commandes précises avec des arguments précis, en utilisant la syntaxe sûre pour visudo. Champs essentiels d’une règle sudoers :

• Utilisateur — qui peut invoquer sudo
• Hôte — sur quelle machine (utilisez ALL pour la portabilité)
• RunAs — quelle identité adopter (presque toujours root)
• Commande — chemin absolu complet, éventuellement accompagné d’arguments littéraux

Exemples de règles strictes pour un compte de service de déploiement (deployer) :

Lorsqu’un script démarre en tant que root (par exemple, s’il est lancé par une initialisation système ou une tâche cron exécutée en tant que root), mais que la plupart des opérations devraient être effectuées avec un utilisateur non privilégié, abandonnez explicitement les privilèges plutôt que d’exécuter tout le script en tant que root.

Deux outils permettent de le faire :

• su -s /bin/bash -c 'command' username — lance un shell sous l’identité de username et exécute la commande
• runuser -u username -- command args — recommandé sous Linux pour changer d’utilisateur dans les scripts appartenant à root ; plus propre que su

Le modèle ci-dessous présente un encapsuleur de déploiement appartenant à root qui passe à l’utilisateur app pour la logique applicative proprement dite :

Vous n’avez pas toujours besoin d’ouvrir une session shell complète. sudo -u username command exécute une commande unique avec l’utilisateur indiqué, puis revient à l’identité appelante. C’est utile pour modifier des fichiers appartenant à un compte de service sans accorder à ce compte un accès interactif.

Associez cela à une règle sudoers qui autorise exactement cette combinaison utilisateur/commande :

Une surface d’attaque subtile concerne les variables d’environnement héritées par une session sudo. Par défaut, sudo réinitialise l’environnement, mais des configurations incorrectes de env_keep ou des remplacements de env_reset peuvent transmettre aux commandes privilégiées des variables contrôlées par l’attaquant, telles que LD_PRELOAD, PATH ou PYTHONPATH.

Bonnes pratiques :

• Utilisez toujours des chemins absolus dans les scripts exécutés sous sudo — ne vous reposez jamais sur $PATH
• Ne transmettez que les variables dont vous avez explicitement besoin : sudo env VAR=value /path/to/cmd
• Dans sudoers, évitez env_keep += PATH ou env_keep += LD_*
• Utilisez sudo -E uniquement lorsque vous contrôlez et approuvez entièrement l’environnement appelant

Même lorsqu’une règle sudoers autorise un script précis, ce script peut recevoir des arguments arbitraires si la règle ne les restreint pas également. Voici un piège courant :

deployer ALL=(root) NOPASSWD: /opt/scripts/manage.sh

Cela autorise sudo /opt/scripts/manage.sh restart — mais aussi sudo /opt/scripts/manage.sh --arbitrary-flag. Si manage.sh transmet aveuglément les arguments à des sous-commandes privilégiées, vous avez un problème.

Défendez-vous en profondeur : validez les arguments à l’intérieur du script privilégié ainsi que dans sudoers :

Lorsqu’un script doit détenir brièvement un fichier, un identifiant d’authentification ou une ressource nécessitant des privilèges, utilisez trap de Bash afin de garantir le nettoyage, même en cas d’erreur ou de signal. Cela empêche toute fuite de privilèges — par exemple, un binaire setuid temporaire ou un socket appartenant à root qui resterait après l’arrêt brutal du script.

Le modèle ci-dessous crée un fichier temporaire en tant que root, l’utilise, puis le supprime — ce que garantit un piège sur EXIT :

Le principe du moindre privilège est plus facile à appliquer lorsque chaque événement d’élévation est journalisé avec son contexte : qui a exécuté quoi, quand et pourquoi. Combinez deux niveaux :

1. sudo lui-même — /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL) enregistre automatiquement chaque invocation de sudo
2. Journal d’audit au niveau du script — écrivez une entrée structurée au début de chaque fonction privilégiée afin que l’intention soit enregistrée parallèlement au journal système

L’utilisation d’une fonction de journalisation structurée simple permet de conserver des pistes d’audit cohérentes et faciles à traiter avec grep :

Testez votre compréhension de l’exécution selon le principe du moindre privilège dans les scripts Bash.

Dans cette leçon, vous avez maîtrisé les techniques permettant d’exécuter des scripts Bash avec le minimum de privilèges requis à chaque étape. Voici un résumé concis des principes essentiels :

• Protégez-vous avec $EUID — échouez immédiatement si le script s’exécute avec la mauvaise identité, qu’il faille refuser root ou l’exiger
• Limitez la portée de sudo aux commandes individuelles — n’élevez jamais les privilèges de tout un script ; appliquez sudo uniquement aux lignes qui en ont réellement besoin
• Rédigez des règles sudoers strictes — indiquez les chemins absolus complets et les arguments littéraux ; évitez les caractères génériques et ALL
• Abaissez les privilèges avec runuser ou sudo -u — lorsqu’un script démarré par root doit passer la main à un utilisateur non privilégié, utilisez l’outil approprié plutôt que d’exécuter tout le script en tant que root
• Utilisez des chemins absolus — ne vous fiez jamais à $PATH dans du code privilégié ; indiquez explicitement les chemins des binaires pour empêcher leur détournement
• Validez les arguments dans les scripts privilégiés — les règles sudoers constituent la première ligne de défense, mais pas la seule ; utilisez des listes d’autorisation
• Interceptez les erreurs et nettoyez — utilisez trap cleanup EXIT pour garantir la destruction des ressources privilégiées temporaires, même en cas d’erreur
• Journalisez chaque élévation — des entrées d’audit structurées, associées au journal système sudo intégré, assurent la traçabilité de chaque action privilégiée

Appliquées systématiquement, ces pratiques réduisent la surface d’attaque de votre automatisation, qui passe de root-en-permanence à root-uniquement-lorsque-c’est-prouvé-nécessaire — la marque d’un Bash renforcé, prêt pour la production.