M2SI Services
Linux

Ubuntu 26.04 et sudo-rs : auditer sudoers et les automatisations avant migration

Une méthode de preflight pour détecter les règles sudoers, usages LDAP et automatisations incompatibles avec sudo-rs avant une migration vers Ubuntu 26.04.

29 août 202610 min de lectureUbuntu 26.04

sudo fait partie des composants que l’on remarque rarement tant qu’ils fonctionnent. Pourtant, une incompatibilité de règles sudoers ou de scripts d’administration peut rapidement devenir un incident majeur : perte d’accès administratif, automatisation bloquée ou politique de privilèges appliquée différemment de ce qui était prévu.

Depuis Ubuntu 25.10, sudo-rs est le fournisseur sudo par défaut. Ubuntu 26.04 LTS conserve ce choix. L’implémentation historique de sudo maintenue par Todd C. Miller reste disponible sous le nom sudo.ws, tandis que le package sudo-ldap a été supprimé. Canonical recommande d’utiliser LDAP via PAM pour l’authentification, ce qui est différent du stockage des règles sudoers dans LDAP.

Sudo-rs vise les usages courants de sudo mais son upstream précise qu’il ne reproduit pas toutes les fonctionnalités de l’implémentation historique. L’objectif de cet article est donc de construire un preflight de compatibilité avant migration : identifier l’implémentation active, inventorier les règles et usages sensibles, tester les comptes représentatifs et conserver une voie de secours.

Contexte et problème

Une politique sudo réelle ne se limite souvent pas à quelques lignes user ALL=(ALL) .... Elle peut combiner :

  • /etc/sudoers ;
  • fichiers sous /etc/sudoers.d/ ;
  • groupes locaux ou issus d’un annuaire ;
  • Defaults globaux ou ciblés ;
  • commandes avec arguments et wildcards ;
  • variables d’environnement ;
  • sudoedit ;
  • journalisation spécifique ;
  • règles centralisées dans LDAP ;
  • scripts d’automatisation qui dépendent d’options de ligne de commande précises.

Sudo-rs utilise la syntaxe sudoers pour les usages courants, mais upstream documente plusieurs différences. Certaines options sont ignorées avec un comportement fixe, certaines fonctionnalités ne sont pas prises en charge, et certaines règles historiques doivent être réévaluées.

La bonne question n’est donc pas « sudo répond-il ? », mais :

Les politiques réellement utilisées
              +
les commandes d'administration
              +
les automatisations
              ↓
se comportent-elles comme prévu avec sudo-rs ?

Ce qui change avec sudo-rs

Ubuntu documente trois changements importants :

  1. sudo-rs est le fournisseur par défaut depuis Ubuntu 25.10 ;
  2. l’implémentation historique est exposée sous les binaires suffixés .ws ;
  3. sudo-ldap a été supprimé au profit d’une authentification LDAP via PAM.

Le troisième point mérite une distinction nette. Authentifier un utilisateur par LDAP via PAM ne signifie pas stocker la politique sudo dans LDAP. Upstream sudo-rs indique que le backend sudoers.ldap n’est pas pris en charge. Un parc qui utilise LDAP comme source centrale des règles sudo doit donc traiter cette dépendance comme un point de migration à part entière.

Sudo-rs documente également, parmi ses différences avec sudo historique :

  • authentification via PAM ;
  • absence de sudo -E ;
  • absence d’INTERCEPT ;
  • absence du stockage de politique via sudoers.ldap ;
  • absence de support sendmail ;
  • logfile non pris en charge, la journalisation passant par syslog ;
  • fichier sudoers devant être en UTF-8 valide ;
  • restrictions plus fortes sur certains wildcards dans les arguments ;
  • certaines options Defaults ignorées ou forcées à une valeur déterminée.

Ces différences ne signifient pas qu’une configuration classique échouera. Elles définissent les zones à auditer en priorité.

Prérequis de sécurité

Une erreur sudo peut vous couper de l’administration. Avant de tester une modification :

  • travaillez sur une VM ou un clone représentatif ;
  • conservez une session root ou une console de secours ouverte ;
  • assurez-vous de connaître le mécanisme de récupération de la machine ;
  • sauvegardez /etc/sudoers et /etc/sudoers.d/ ;
  • identifiez au moins deux comptes ou groupes administratifs représentatifs ;
  • inventoriez les tâches automatisées qui exécutent sudo.

Ne remplacez jamais le fournisseur sudo sur un serveur distant en fermant votre seule session privilégiée avant validation.

Mise en pratique

1. Identifier le fournisseur et les versions

Commencez par observer le binaire réellement appelé :

command -v sudo
readlink -f "$(command -v sudo)"
sudo --version

Puis inventoriez les packages liés :

dpkg-query -W -f='${Package}\t${Version}\n' 'sudo*' 2>/dev/null

Vérifiez également la présence éventuelle des outils historiques :

command -v sudo.ws
command -v visudo.ws

L’absence de ces binaires ne doit pas être contournée par une installation improvisée sur production. Le but est d’abord de connaître l’état réel du système.

2. Sauvegarder et valider la configuration existante

Sur le clone :

sudo cp -a /etc/sudoers /etc/sudoers.pre-sudo-rs
sudo cp -a /etc/sudoers.d /etc/sudoers.d.pre-sudo-rs

Validez ensuite la syntaxe avec l’outil installé :

sudo visudo -c

Le résultat attendu est une validation sans erreur de parsing. Cette étape ne prouve toutefois pas que toutes les fonctionnalités utilisées auront le même comportement avec un autre fournisseur.

3. Rechercher les dépendances connues

Effectuez des recherches non destructives dans les fichiers sudoers :

sudo grep -RniE 'INTERCEPT|logfile|timestamp_type|env_reset|visiblepw|sudoedit|NOPASSWD|PASSWD' \
  /etc/sudoers /etc/sudoers.d 2>/dev/null

Recherchez aussi les commandes contenant des wildcards :

sudo grep -RniE '[*?]' /etc/sudoers /etc/sudoers.d 2>/dev/null

Chaque résultat doit être relu dans son contexte. Sudo-rs accepte certains wildcards, mais upstream impose des restrictions supplémentaires dans les positions d’arguments afin d’éviter des règles ambiguës ou dangereuses.

Cherchez ensuite si la politique sudo peut provenir d’un annuaire :

grep -nE '^[[:space:]]*sudoers:' /etc/nsswitch.conf 2>/dev/null
grep -RniE 'sudoers_base|sudoRole' /etc/ldap.conf /etc/sssd 2>/dev/null

Ces commandes ne lisent volontairement pas les fichiers de secrets LDAP. L’objectif est d’identifier si la politique sudo elle-même provient d’un annuaire. Ne confondez pas ce cas avec un utilisateur qui s’authentifie simplement via LDAP/SSSD/PAM.

4. Auditer les scripts et pipelines

Cherchez les options sudo explicitement utilisées dans vos scripts locaux :

grep -RniE '\bsudo([[:space:]]|$)' /usr/local /opt 2>/dev/null

Portez une attention particulière à :

sudo -E
sudoedit
sudo -u <user>
sudo -g <group>
sudo -i
sudo -n

sudo -E est explicitement cité comme non pris en charge par sudo-rs upstream. Si une automatisation dépend de la conservation intégrale de l’environnement appelant, elle doit être revue plutôt que simplement contournée.

Ubuntu indique en revanche que sa version sudo-rs introduite avec 25.10 comprend notamment le support de sudoedit, de NOEXEC et du changement de profil AppArmor. Il faut tout de même valider le scénario exact utilisé par votre parc.

5. Vérifier la politique réellement accordée

Pour le compte courant :

sudo -l

Conservez la sortie obtenue avant la migration dans le lab. Elle constitue une référence utile pour comparer les commandes autorisées et interdites.

Réalisez ensuite des tests représentatifs avec des commandes sans effet destructif. Par exemple, si une règle autorise la consultation d’un service :

sudo systemctl status <SERVICE> --no-pager

Ne testez pas une autorisation en remplaçant <SERVICE> par une commande qui arrête ou reconfigure réellement la production.

Pour chaque profil administratif important, vérifiez :

  • commande autorisée effectivement autorisée ;
  • commande non autorisée effectivement refusée ;
  • demande de mot de passe conforme à la politique ;
  • changement d’utilisateur attendu ;
  • variables d’environnement indispensables ;
  • logs d’audit générés comme prévu.

6. Contrôler la journalisation

Sudo-rs indique que la directive sudoers logfile n’est pas supportée et que sa journalisation est effectuée via syslog.

Si votre SI collecte historiquement un fichier tel que /var/log/sudo.log, cette dépendance doit être identifiée avant migration.

Examinez les événements avec les outils adaptés à Ubuntu, par exemple :

journalctl -b | grep -i sudo

Dans une infrastructure centralisée, vérifiez ensuite que rsyslog, le forwarding de journald ou l’agent de collecte transmet toujours les événements nécessaires au SIEM.

Le succès d’une commande sudo n’est pas une validation complète si l’audit de sécurité disparaît silencieusement.

7. Traiter LDAP comme un cas de migration distinct

Si les utilisateurs sont authentifiés via LDAP mais que les règles sont locales dans /etc/sudoers, la situation est différente d’un backend sudoers.ldap.

Dans le premier cas, validez la chaîne PAM et les groupes nécessaires.

Dans le second, ne basculez pas tant qu’un nouveau modèle de distribution de la politique n’est pas défini : fichiers gérés par configuration management, mécanisme pris en charge par l’environnement ou maintien temporaire du fournisseur historique lorsque la politique de support le permet.

Il ne faut surtout pas supprimer le backend LDAP et recréer manuellement quelques règles locales sans avoir inventorié les rôles réellement distribués.

Construire le go/no-go

Le serveur est candidat à la migration lorsque :

fournisseur identifié
        +
sudoers syntaxiquement valide
        +
aucune fonctionnalité critique non supportée
        +
comptes représentatifs testés
        +
automatisations testées
        +
journalisation validée
        +
voie de secours disponible
        ↓
       GO

Un backend sudoers.ldap encore nécessaire, un sudo -E critique non refactoré, une politique wildcard incompatible ou une perte de logs doit produire un NO-GO jusqu’à correction.

Bonnes pratiques

Ne modifiez jamais directement /etc/sudoers avec un éditeur ordinaire sur production. Utilisez visudo et des fichiers sous /etc/sudoers.d/ lorsque cela correspond à votre gestion de configuration.

Conservez des règles les plus spécifiques possibles. Une migration n’est pas une raison pour élargir temporairement les privilèges avec ALL afin de « faire fonctionner » les scripts.

Séparez également le changement de fournisseur sudo d’autres changements IAM ou annuaire lorsque c’est possible. Un changement à la fois facilite le diagnostic et le rollback.

Enfin, versionnez les règles gérées par automatisation et comparez les sorties sudo -l des profils importants avant et après changement.

Sécurité

Sudo est une frontière de privilèges. Une incompatibilité ne doit jamais être corrigée en ajoutant massivement NOPASSWD, en désactivant PAM ou en transformant une règle précise en accès root général.

Gardez une console de récupération et une session privilégiée indépendante pendant les tests. Vérifiez également les événements dans votre SIEM ou système de logs central.

Sudo-rs met l’accent sur une implémentation memory-safe en Rust, mais ce choix d’implémentation ne dispense pas de valider la politique et les intégrations. La sécurité dépend toujours de la qualité des règles sudoers, de PAM, de la gestion des identités et des opérations autorisées.

Coûts

Le changement de fournisseur sudo n’implique pas de licence supplémentaire sur Ubuntu. Les coûts sont principalement opérationnels : environnement de test, adaptation des scripts, migration éventuelle de la politique LDAP et validation des collecteurs de logs.

Limites et rollback

Les fonctionnalités de sudo-rs évoluent. Vérifiez les différences documentées par la version réellement fournie par Ubuntu au moment de la migration.

Si un blocage apparaît, ne devinez pas une commande de changement de fournisseur. Ubuntu conserve le fournisseur historique sous sudo.ws et documente la configuration du fournisseur sudo. Utilisez la procédure Ubuntu correspondant aux packages réellement installés pour revenir temporairement au fournisseur historique si nécessaire.

Restaurez les sauvegardes sudoers uniquement si leur contenu correspond encore au fournisseur et à l’état de packages utilisés. Commencez par comparer :

sudo diff -ruN /etc/sudoers.d.pre-sudo-rs /etc/sudoers.d
sudo diff -u /etc/sudoers.pre-sudo-rs /etc/sudoers

Ces commandes sont en lecture seule. Toute restauration effective doit être suivie de :

sudo visudo -c

et d’un nouveau test depuis une seconde session administrative avant de fermer la session de secours.

Références officielles

  • Ubuntu 26.04 LTS summary — Canonical : https://documentation.ubuntu.com/release-notes/26.04/summary-for-lts-users/
  • Ubuntu 25.10 release notes — Canonical : https://documentation.ubuntu.com/release-notes/25.10/
  • sudo-rs upstream — Trifecta Tech Foundation : https://github.com/trifectatechfoundation/sudo-rs
  • sudo-rs FAQ — Trifecta Tech Foundation : https://github.com/trifectatechfoundation/sudo-rs/blob/main/FAQ.md

Conclusion

Le passage à sudo-rs sous Ubuntu 26.04 ne doit pas être traité comme un simple changement de binaire. Pour les usages classiques, la transition peut être transparente ; pour les environnements avancés, les différences de fonctionnalités deviennent des critères de go/no-go.

Inventoriez les règles, repérez LDAP, les wildcards et les options particulières, testez les comptes et automatisations représentatifs, puis validez la journalisation et le mécanisme de secours. C’est cette preuve de compatibilité — et non le simple retour de sudo --version — qui permet de considérer la migration comme prête.