/image%2F8357444%2F20250531%2Fob_e5372f_safitexpers.jpeg)
/image%2F7127247%2F20260208%2Fob_1cb4dd_1fec8552-4d07-4df4-9056-32455469926c.png)
🛡️ sudo vs su : Le Guide Complet d'Élévation de Privilèges Linux 2026
1980 ────► `sudo` introduit et évolue
2004 ────► Ubuntu désactive root par défaut
2024+ ────► `run0` arrive avec systemd
2025 ────► CVE sudo (32462, 32463)
2026 ────► Guide SafeITExperts complet
Série Administration Linux 2026
Par SafeITExperts
Cet article explore en profondeur les deux commandes fondamentales d'élévation de privilèges sous Linux : sudo et su. Nous analysons leur historique, leurs différences conceptuelles, les pièges courants, les aspects sécurité, et les alternatives modernes.
💡 Objectif : Fournir une compréhension complète desudoetsupour faire des choix éclairés selon votre contexte d'utilisation (personnel, professionnel, partagé).
📋 Table des matières
📚 1) Introduction & Historique
Vous ouvrez un terminal pour installer un paquet, modifier un fichier dans /etc, ou redémarrer un service système. Deux réflexes reviennent : taper sudo … ou passer en root avec su -. Les deux finissent par exécuter des commandes avec les droits root, mais pas dans le même cadre.
1.1 Un très court historique
| Année | Événement clé | Idée principale |
|---|---|---|
| 1971 | su apparaît dans les premières versions d'Unix | Changer d'utilisateur si je connais son mot de passe |
| Années 80 | sudo est introduit et évolue | Ne plus partager le mot de passe root, mais déléguer des commandes |
| 2004 | Ubuntu désactive root par défaut | sudo devient la norme pour l'admin "grand public" |
| 2024+ | run0 arrive avec des versions récentes de systemd | Alternative moderne basée sur systemd + Polkit |
L'important :
su= modèle ancien : "je deviens root si j'ai sa clé"sudo= modèle moderne : "je demande à faire X, on vérifie si j'ai le droit, et c'est tracé"run0= nouvelle approche : systemd + Polkit, sans binaire SUID dédié
📊 2) su vs sudo : les bases
On peut résumer su - et sudo par une analogie simple :
Vous prenez la clé du directeur et entrez dans son bureau. Tant que vous n'êtes pas sorti, vous êtes lui.
- Secret : Mot de passe root, souvent partagé
- Durée : Session root persistante jusqu'à
exit - Audit : Log flou : "root a fait X"
Vous restez à votre bureau, vous envoyez une demande "redémarre nginx", elle est exécutée pour vous et consignée.
- Secret : Mot de passe utilisateur, unique et personnel
- Durée : Par défaut : commande par commande
- Audit : Log précis : "user a exécuté X via sudo à telle heure"
2.2 Tableau comparatif technique
| Critère | su - (Switch User, login root) | sudo (SuperUser DO) |
|---|---|---|
| Action | Ouvre une session root complète | Exécute une commande (ou un shell) avec privilèges root |
| Authentification | Mot de passe root | Mot de passe utilisateur (ou autre mécanisme SSO) |
| Durée | Tant que la session n'est pas fermée (exit) | En principe limitée à la commande, ou durée configurable |
| Granularité | Tout ou rien (root total) | Finesse via /etc/sudoers (par commande, groupe, host…) |
| Audit | Moins précis (root) | Très précis (qui, quoi, quand) |
| Environnement | HOME=/root, PATH root (shell login) | Conserve en partie l'environnement utilisateur (HOME, etc.) |
Conclusion de cette section :su - et sudo donnent tous les deux accès au pouvoir root. Ce qui change : comment on y accède, combien de temps on y reste, et ce qui est enregistré.
⚠️ 3) Démos & pièges courants
3.1 Qui suis‑je ? Où suis‑je ? Quel PATH ?
Pour bien comprendre, rien ne vaut quelques tests simples :
echo "HOME=$HOME"
echo "PATH=$PATH"
Puis comparez avec ces trois commandes :
echo "USER=$(whoami)"
echo "HOME=$HOME"
echo "PATH=$PATH"
exit
echo "USER=$(whoami)"
echo "HOME=$HOME"
echo "PATH=$PATH"
exit
echo "USER=$(whoami)"
echo "HOME=$HOME"
echo "PATH=$PATH"
exit
✅ Ce que vous devriez voir :
su -etsudo -idonnent un environnement root "propre" (HOME=/root, PATH système)su(sans-) peut conserver HOME/PATH utilisateur : si un binaire ou script malveillant se cache dans~/bin, vous pouvez l'exécuter en root sans le vouloir
3.2 Piège 1 : les redirections avec sudo
# -> Permission denied
Pourquoi ? Parce que le shell interprète >avant sudo. C'est votre utilisateur qui tente d'écrire dans /etc, pas sudo.
✅ Solutions correctes :
sudo sh -c 'echo "DNS=8.8.8.8" > /etc/resolv.conf'
su -c 'echo "DNS=8.8.8.8" > /etc/resolv.conf'
Note : Dans la commande su -c "<commande>", le -c signifie "command" et doit être suivi de la commande à exécuter entre guillemets.
3.3 Piège 2 : applications graphiques avec sudo
sudo kate /etc/monfichier.conf
Peut créer/modifier des fichiers dans ~/.config ou d'autres dossiers de votre HOME avec root comme propriétaire → votre session utilisateur peut ensuite ne plus fonctionner correctement.
✅ Bon réflexe :
- Pour les fichiers texte :
sudoedit /etc/monfichier.conf - Pour les GUI : passer par des outils basés sur Polkit (ex. boîtes de dialogue d'authentification des environnements graphiques)
3.4 Piège 3 (optionnel mais réel) : sudo "lent"
Si sudo met 2–10 s à répondre, ce n'est généralement pas un bug de sudo, mais :
- reverse DNS / résolution réseau lente (vérifier
/etc/hosts,/etc/resolv.conf) - intégration LDAP/AD/PAM mal configurée
- règles sudoers avec
Defaults timestamp_timeouttrop court ou mécanisme de cache problématique
time sudo -v
# et vérifier /var/log/auth.log
👉 C'est un symptôme d'environnement, pas un défaut conceptuel de sudo.
🔄 4) Variantes & usages
susu | Change d'utilisateur, garde beaucoup d'env |
su - / su -l | Login shell complet sous root |
su -c "<commande>" | Exécute la <commande> puis revient |
⚠️ Pour de l'admin système, si vous utilisez su, utilisez su -, pas su seul.
sudosudo <commande> | Exécute une commande en root |
sudo -i | Shell root façon login (su - sous contrôle sudo) |
sudo -s | Shell root mais conserve davantage l'env |
sudo -E <commande> | Préserve l'env (LANG, etc.) |
sudoedit fichier | Édite un fichier avec une mécanique sécurisée |
sudo -n <commande> | Mode non‑interactif (échec si mot de passe requis) |
sudo su : le mauvais réflexe
sudo -i # ✅ Clair, traçable, même résultat
La seule raison d'utiliser sudo su serait si vous devez changer vers un utilisateur non-root après être devenu root, ce qui est un cas très rare.
4.3 Tableau "quoi utiliser quand"
| Situation | Recommandation | Pourquoi ? |
|---|---|---|
| Une commande admin unique | sudo <commande> | Moindre privilège, simple, auditable |
| Mise à jour système | sudo apt update (exemple) | Standard multi‑distribution |
| Suite d'actions admin | sudo -i puis exit | Shell root propre + logs sudo |
sudo cassé/non dispo | su - | Plan B, nécessite mot de passe root |
| Script automatisé | sudo -n <commande> | Pas de blocage interactif |
Modifier un fichier dans /etc | sudoedit fichier | Moins de risque qu'un éditeur GUI root |
🐧 5) Selon les distributions
Les outils sont les mêmes, mais la politique par défaut change.
Politique : root verrouillé, sudo préconfiguré
Effet : Admin via sudo. su - nécessite d'abord de définir un mot de passe root.
Politique : Choix à l'installation
Effet : Si root a un mot de passe → su - dispo ; sinon → modèle proche Ubuntu (sudo-only).
Politique : sudo encouragé, su encore possible
Effet : Modèle "sudo-first" pour l'audit.
Politique : sudo/doas non imposés
Effet : L'admin choisit et configure son modèle.
ℹ️ Retenir que ce n'est pas Linux qui impose su ou sudo, mais la politique de la distribution et de l'admin (root activé ou non, sudoers, wheel, Polkit, etc.).
🔒 6) Sécurité & alternatives
6.1 Audit : l'avantage structurel de sudo
jean : TTY=pts/0 ;
COMMAND=/usr/bin/systemctl restart nginx
On sait qui a demandé quoi, quand et comment.
(to root) root on pts/1
On sait seulement que quelqu'un est devenu root.
En environnement réglementé (PCI‑DSS, ISO 27001, etc.), cette différence est décisive.
6.2 Complexité de sudo (en bref)
| Aspect | Détail (ordre de grandeur) | Impact sécurité |
|---|---|---|
| Langage | Principalement C | Sensible aux bugs mémoire |
| Taille code | > 200 000 lignes de C, ~300 000 lignes au total | Grande surface potentielle de bug |
| Fonctionnalités | sudoers, plugins, modes, options avancées | Puissant, mais complexe à maîtriser |
ℹ️ À retenir : sudo est un gros morceau de logiciel. Plus il fait de choses, plus la configuration et les mises à jour doivent être traitées sérieusement.
6.3 CVE 2025 : deux rappels utiles
⚠️ CVE 2025 et sudo (rappel)
Deux vulnérabilités importantes ont été découvertes en 2025 :
- Concerne l'option
-h/--hostdans certaines configurations - Peut permettre de contourner des restrictions liées à l'hôte
- Affecte certaines configurations avancées de sudo
- Concerne l'option
-R/--chroot - Vulnérabilité suffisamment sérieuse pour être activement exploitée
- Fait l'objet d'alertes de sécurité dédiées
👉 Message à en tirer :sudo reste un standard, mais c'est un binaire d'élévation critique : patch rapide obligatoire, et configuration selon le moindre privilège.
6.4 sudoers & visudo : puissance et casse potentielle
⚠️ Jamais éditer /etc/sudoers avec un éditeur lambda.
Toujours utiliser :
visudo vérifie la syntaxe avant de sauvegarder ; une erreur peut sinon bloquer tout accès sudo et vous laisser sans accès root si le compte root est verrouillé.
6.5 Alternatives modernes : doas, run0
doas- Inspiré d'OpenBSD
- Fichier de config très simple (
/etc/doas.conf) - Moins riche que sudo, mais plus minimaliste
- Intéressant pour certains cas
run0 (systemd)- Arrive avec des versions récentes de systemd (autour de v256)
- Exécute des commandes privilégiées via systemd + Polkit
- Sans binaire SUID dédié pour cet usage
- Modèle différent pour l'élévation "type sudo"
❓ 7) FAQ et checklist
Cliquez pour retourner
La différence se situe sur :
- la façon dont vous êtes devenu root
- la durée pendant laquelle vous êtes resté root
- la traçabilité de l'action
Cliquez pour retourner
- si le but est d'entrer dans un shell root,
sudo -iest plus clair sudo sumélange les modèles sans valeur ajoutée- ça complique la lecture des logs
Cliquez pour retourner
- Sur machine perso, un mot de passe root fort et réservé à vous n'est pas un problème en soi.
- En environnement multi‑admin, l'enjeu est surtout de ne pas partager ce mot de passe : on privilégie alors sudo (ou équivalent) + comptes individuels.
Cliquez pour retourner
- Passer en mode recovery ou utiliser un compte root encore accessible (
su -si possible) - Corriger le fichier avec
visudo
D'où l'importance de toujours passer par visudo pour éviter d'en arriver là.
✅ Checklist mentale finale
Une commande ou plusieurs ? → sudo <commande> ou sudo -i
sudo cassé ? → su - (plan B)
Éditer un fichier système ? → sudoedit, pas sudo nano/gvim
Modifier sudoers ? → toujoursvisudo
Environnement professionnel ? → privilégier sudo pour la traçabilité
Après sudo -i ou su - → exit immédiatement après les actions
🏁 8) Conclusion
Avantages : Simple, ancien, puissant
Inconvénients : Tout ou rien, peu traçable
Cas d'usage : Secours, dépannage, mode "admin old school"
Avantages : Plus fin, traçable, configurable
Inconvénients : Plus complexe
Cas d'usage : Environnement partagé, audit requis
doas : Minimaliste, configuration simple
run0 : Moderne, systemd + Polkit
Cas d'usage : Nouvelles approches, sécurité renforcée
Idée centrale :su - et sudo ne sont pas des "concurrents" au sens manichéen, ce sont deux modèles d'élévation différents.
Pour un usage moderne, surtout en environnement partagé : on privilégie sudo (ou des alternatives conçues avec les mêmes objectifs : doas, run0), on garde su - comme outil de secours et pour certains contextes précis.
En maîtrisant ces quelques règles,sudo,su,doasourun0deviennent des outils assumés et maîtrisés, pas des réflexes magiques potentiellement dangereux.
📚 9) Sources et références
Red Hat – Différences entre sudo et su
Présentation détaillée de su et sudo, implications sécurité, audit et bonnes pratiques en environnement entreprise.
SUSE – Configurer les privilèges super‑utilisateur avec sudo
Documentation officielle sur la configuration de sudo (/etc/sudoers, visudo), l'usage recommandé et l'intégration dans la politique de sécurité.
Debian – Compte root, sudo et modèles d'administration
Documentation Debian sur le compte root, le choix à l'installation (root activé ou non) et les conséquences pratiques sur su et sudo.
OpenBSD & Debian – doas, alternative minimale à sudo
Références pour comprendre la philosophie de doas (minimalisme, configuration simple) et voir des exemples concrets de règles.
systemd – Annonce de systemd v256 et introduction de run0
Article présentant run0 comme alternative moderne à sudo, basée sur systemd et Polkit.
CVE 2025 – Vulnérabilités récentes de sudo
Avis de sécurité décrivant les vulnérabilités liées aux options -h/--host et -R/--chroot, avec détails techniques et mitigations.
📖 10) Lectures recommandées SafeITExperts
Ces articles SafeITExperts complètent parfaitement ce guide sur sudo et su en abordant le matériel, l'architecture système, la sécurité et les parts de marché des OS.
Le Choix de PC Portables pour Linux et la Sécurité (2026)
Guide d'achat orienté compatibilité Linux et exigences de sécurité (chiffrement, firmware, support, etc.).
OS Desktop Décembre 2025 : Parts de Marché par Région
Analyse chiffrée des parts de marché des OS desktop par région, utile pour contextualiser l'usage réel de Linux sur le poste client.
Systemd 2025 : Architecture Hiérarchique et Sécurité Linux
Plongeon dans l'architecture systemd, les unités, la hiérarchie des services et l'impact sur la sécurité moderne de Linux (dont run0).
Ordinateur volé : guide sécurité 2025 (Linux, Windows, ChromeOS, macOS)
Procédures à suivre en cas de vol ou perte de machine : chiffrement, comptes, mots de passe, services en ligne, réaction d'urgence.
Systèmes d'Installation Immuables : Révolution Architecturale
Présentation des OS immuables (Silverblue, MicroOS, etc.), de leurs modèles de mise à jour et implications sécurité/admin.
Carte Mère 2025 : Guide des Composants et Choix
Guide complet sur les cartes mères modernes (chipsets, VRM, BIOS/UEFI, compatibilité Linux), pour choisir une base matérielle saine et durable.