Le compte traditionnellement nommé root possède l'UID 0 et une large autorité dans son contexte de sécurité. Travaillez normalement sans privilèges et ne les élevez que pour un objectif administratif précis et compris.
Gestion des Utilisateurs · Leçon 2
root
Découvrez comment su, sudo et la politique sudoers donnent un accès contrôlé aux identités privilégiées.
Ouvrir un shell comme un autre utilisateur avec su
su, pour substitute user, lance un shell ou une commande avec l'identité d'un autre compte. Sans nom, la cible est root :
$ su
PAM et la politique locale contrôlent l'authentification. Le système peut demander le mot de passe cible, restreindre su ou garder le mot de passe root verrouillé.
Un simple su préserve davantage l'environnement courant. su - USER, ou su --login USER, initialise un shell de connexion plus proche d'une nouvelle session cible :
$ su - operator
Quittez ce sous-shell lorsque le travail est terminé.
Quelle commande demande un shell de connexion comme operator ?
Exécuter une commande précise avec sudo
sudo COMMAND demande l'autorisation d'exécuter une commande comme cible, souvent root. -u USER choisit une autre cible :
$ sudo -u postgres id
La politique contrôle l'appelant, l'hôte, la cible, la commande et d'autres conditions. L'authentification peut utiliser le mot de passe de l'appelant, un autre mécanisme ou aucune invite. Préférez une commande administrative étroitement définie à un shell privilégié durable.
Que demande sudo -u postgres id ?
Éviter les shells privilégiés persistants
su -, sudo -s ou sudo -i peuvent créer un shell privilégié. Toute commande ultérieure conserve alors un fort impact jusqu'à la sortie : erreurs de chemin, scripts non examinés et développements du shell deviennent plus dangereux.
La journalisation dépend de la configuration. L'enregistrement du lancement d'un shell ne fournit pas automatiquement l'historique complet de toutes les commandes saisies ; historique shell, audit système et enregistrement d'E/S sudo sont distincts.
Pourquoi un shell root durable est-il plus risqué que l'élévation d'une commande comprise ?
Examiner les autorisations sudo
$ sudo -l
Examinez les chemins de commandes, utilisateurs cibles permis et restrictions d'arguments. Une règle large ne constitue pas une permission pour un travail sans rapport.
Quelle commande liste les privilèges sudo de l'utilisateur appelant ?
Modifier sûrement la politique sudoers
La politique par défaut lit souvent /etc/sudoers et des fichiers de /etc/sudoers.d/. Utilisez visudo, qui verrouille et valide la syntaxe :
$ sudo visudo
Pour un fichier complémentaire, indiquez son chemin exact :
$ sudo visudo -f /etc/sudoers.d/application-admins
N'utilisez ni redirection ordinaire ni flux d'édition non validé. Une erreur de syntaxe ou de permissions peut supprimer l'accès administratif. Gardez une voie de récupération vérifiée lors d'un changement distant.
Quel outil faut-il employer pour modifier et vérifier la politique sudoers principale ?
Pour vous exercer :
- Configurer les comptes et privilèges sudo sous Linux - Sécurisez root et accordez des droits administratifs.
Leçon terminée
Vous avez terminé root
Vous savez distinguer changement d'identité et délégation contrôlée de commandes.
Employer
su - USERseulement pour un shell de connexion cible.Demander une cible sudo avec
-u USER.Réduire le temps passé dans un shell privilégié.
Examiner les règles avec
sudo -l.Modifier sudoers uniquement avec
visudo.
Conservez votre progression
Créez un compte gratuit pour enregistrer cette leçon et continuer sur n'importe quel appareil.
Créer un compte gratuit