Paradoxalement, la commande sudo n'empêche pas d'exécuter une session administrateur au sein d'une session utilisateur standard. Parce qu'avec son aide, vous pouvez exécuter la même commande su :
$sudo su
Et c'est même dans Ubuntu, où il n'y a pas de compte root ; plus précisément, il n'y a pas de mot de passe par défaut. Mais utiliser sudo le rend inutile même pour la commande su. Mais il n'est pas interdit de définir un mot de passe superutilisateur - après tout, pour ce faire, il suffit de donner la commande
$ mot de passe sudo
afin d'utiliser su de la manière habituelle à l'avenir. Et même, si vous le souhaitez, connectez-vous en tant que root lors de votre inscription dans le système.
Cependant, ici aussi, la commande sudo propose une méthode « idéologiquement correcte », et même pas une seule. Ce sont les options -s et -i, qui prolongent, bien que de manière légèrement différente, l'action de la commande sudo pour une durée indéfinie, jusqu'à ce que la « session secondaire » soit terminée avec la commande exit.
L'option -s, lors de l'ouverture d'une session root secondaire, préserve toutes les variables d'environnement de l'utilisateur d'origine. Cependant, si vous y ajoutez l'option -H, alors ces variables seront relues à partir des fichiers de profil du répertoire personnel de l'administrateur, c'est-à-dire /root, comme lors du démarrage d'une instance de shell interactive. Cependant, le répertoire qui était courant au moment où la commande a été saisie ne changera pas, pas plus que l'apparence de l'invite de ligne de commande.
L'option -i reproduit complètement l'environnement racine, en lançant son shell de commande en tant que shell de connexion. Bien entendu, dans ce cas, le répertoire courant devient /root et l'invite de ligne de commande prend la forme décrite dans la variable correspondante dans le fichier de profil du shell de l'administrateur (dans bash - PS1).
En pratique, la différence entre les deux formes d'obtention de droits d'administrateur permanents n'est pas grande, surtout dans bash. Mais dans zsh, avec les paramètres appropriés des fichiers de profil, vous pouvez, si vous le souhaitez, obtenir un environnement sensiblement différent dans chacun de ces cas. Certes, la question de savoir dans quelle mesure l'utilisateur en a besoin est une grande question. Mais le fait que lors de l'utilisation des options -H, être en mode administratif permanent n'apparaisse en aucune façon extérieurement est semé d'erreurs. Et rend l'utilisation de l'option -i préférable dans la plupart des cas.
À propos, les capacités de sudo ne se limitent pas à l'exécution de commandes en tant qu'administrateur : en spécifiant l'option -u username, elles peuvent être exécutées au nom de l'utilisateur dont le login est spécifié comme valeur. Cela peut être utile lors de l'affichage ou de la copie des fichiers point et des répertoires point d'un autre utilisateur, qui ne sont souvent lisibles et modifiables que par le propriétaire.
D'ailleurs, la commande sudo peut être exécutée de manière à demander le mot de passe de l'utilisateur sous le nom duquel la commande sera exécutée (par exemple, un administrateur), et non celui qui requiert son autorité. Il existe une option -targetpw pour cela. Et pour rendre permanente l'exigence du mot de passe root, il suffit de définir, par exemple, un alias comme
Alias sudo-targetpw
Exiger que le mot de passe root soit saisi lors de l'exécution de sudo est le comportement par défaut dans certaines distributions, par exemple, comme on dit, dans Suse.
La commande sudo a beaucoup plus d'options - j'ai répertorié ci-dessus uniquement celles que je devais utiliser. Le reste est facile à rechercher dans man sudo. Parmi ceux qui ne sont pas répertoriés, je mentionnerai également l'option -b, qui demande d'exécuter la commande « supervision » en arrière-plan. Cela peut être utile lors de l'exécution d'actions à long terme, par exemple lors de la copie d'images USB sur une clé USB avec la commande dd.
Comme nous venons de le voir, la commande sudo donne à l'utilisateur des pouvoirs presque illimités pour toute action à l'échelle du système, ainsi que pour manipuler les données utilisateur d'autres personnes. À cet égard, posons-nous les questions suivantes :
- si un utilisateur peut obtenir des droits d'administrateur via la commande sudo, et
- peut-il effectuer toutes les démarches administratives en l'utilisant ?
Si nous parlons de la famille Ubuntu, dans laquelle ce mécanisme a été utilisé pour la première fois « hors des sentiers battus », alors « hors des sentiers battus », la réponse à la première question sera négative, à la seconde - positive. En général, cela dépend des paramètres du programme sudo, qui sont décrits dans le fichier /etc/sudoers. Et vous pouvez y définir des règles qui permettent uniquement à certains utilisateurs d'exécuter certaines commandes. En résumé cela ressemble à ceci :
Nom d'utilisateur hôte = commande
Ici, comme vous pouvez le deviner, username est le nom de l'utilisateur pour lequel cette règle est définie, host est le nom de la machine à partir de laquelle il peut recourir à cette règle, command est une commande spécifique, dont cet utilisateur est l'utilisateur. autorisé à partir de cette machine. La commande doit être donnée avec un chemin absolu complet (c'est-à-dire /sbin/fdisk, pas fdisk). Le champ de description de la commande peut inclure plusieurs valeurs séparées par des virgules, par exemple :
Nom d'utilisateur ALL = /sbin/fdisk,/bin/mount
Dans Ubuntu, les règles par défaut pour l'accès des utilisateurs aux privilèges administratifs sont décrites comme suit :
# Spécification des privilèges utilisateur root ALL=(ALL) ALL # Les membres du groupe admin peuvent obtenir les privilèges root %admin ALL=(ALL) ALL
Autrement dit, l'utilisateur root, comme prévu, peut exécuter n'importe quelle commande à partir de n'importe quel hôte. Mais seuls les utilisateurs membres du groupe admin (analogue au groupe wheel dont il a été question) peuvent obtenir ses droits. Un utilisateur créé lors d'une installation normale devient automatiquement membre de ce groupe - et dispose donc de tous les droits d'administration sans aucun réglage supplémentaire. Toutefois, les autres utilisateurs dont les comptes seront créés ultérieurement sont privés de ce privilège. À moins, bien sûr, qu’ils soient spécifiquement inclus dans le groupe administrateur.
Dans d'autres distributions qui n'utilisent pas sudo par défaut, vous devrez modifier son fichier de configuration - le même /etc/sudoers mentionné ci-dessus.
Le fichier /etc/sudoers est un fichier texte normal et, par conséquent, il peut être modifié dans n'importe quel éditeur de texte (ou, par exemple, en utilisant ed ou sed). Cependant, il existe un certain risque de gâcher quelque chose (à cause de fautes de frappe ordinaires), voire de bloquer complètement votre accès aux privilèges de superutilisateur. Bien entendu, ces situations peuvent être corrigées, par exemple en redémarrant en mode mono-utilisateur. Cependant, il vaut mieux ne pas les frapper. Et par conséquent, un moyen plus fiable de modifier /etc/sudoers serait d'utiliser un utilitaire spécialement conçu à cet effet - visudo.
L'utilitaire visudo ne fait rien de surnaturel - il ouvre simplement /etc/sudoers dans un éditeur de texte décrit par la variable superutilisateur EDITOR (si elle n'est pas définie, ce sera à nouveau le vi classique - d'où le nom) et vous permet de l'éditer de la manière habituelle, puis quittez l'éditeur en enregistrant les résultats en utilisant ses moyens standard. Cependant, avant cela, l'exactitude du résultat de l'édition est vérifiée. Et si une violation de la syntaxe acceptée pour /etc/sudoers est détectée, un avertissement correspondant est émis. Après quoi vous pouvez revenir à l'édition, refuser les modifications apportées, ou encore les accepter (bien entendu, sous votre responsabilité personnelle).
L'utilitaire visudo ne garantit pas un succès d'édition à 100 %. Puisqu’il vérifie uniquement la cohérence de la syntaxe, mais pas « l’exactitude des règles elles-mêmes ». Autrement dit, si une erreur est commise lors de la spécification du chemin d'accès à la commande requise pour une règle donnée, cette commande via sudo ne fonctionnera pas.
Cependant, en réalité, cela semble généralement beaucoup plus simple et pas du tout effrayant. Ainsi, dans Fedora 11, dans l'exemple de configuration /etc/sudoers, il me suffisait de décommenter la ligne
%roue TOUT=(TOUS) TOUS
pour donner à l'utilisateur du groupe spécifié (et je m'y suis inclus à l'avance, comme décrit dans) tous les droits accordés à l'administrateur. En même temps, vous pourriez vous donner la possibilité d'utiliser sudo sans mot de passe. Cela nécessiterait de décommenter la ligne
# %wheel ALL=(TOUS) NOPASSWD : TOUS
Mais je me suis limité à faire durer le mot de passe plus longtemps en ajoutant (la ligne initialement manquante
Valeurs par défaut timestamp_timeout=10
où la valeur du délai d'attente est spécifiée en minutes. Au fait, si vous le changez à zéro -
Valeurs par défaut timestamp_timeout=0
alors le mot de passe sera demandé à chaque fois que vous utiliserez la commande sudo.
Vous pouvez au contraire désactiver le timeout de l'action sudo en lui attribuant une valeur négative :
Valeurs par défaut timestamp_timeout=-1
Dans ce cas, le mot de passe ne vous sera demandé qu'au premier appel de cette commande.
Un examen plus attentif du fichier /etc/sudoers révélera facilement des opportunités d'accorder à certains utilisateurs ou groupes uniquement un ensemble limité de droits. Cependant, c’est là que commencent les subtilités de la véritable administration. J'ai simplement privé mon double-expérimentateur d'accès à toute action administrative afin de stopper toutes ses tentatives dans ce domaine. Cependant, même cela ne me permet pas toujours de faire face à lui - tout comme Timur Shaov est incapable de faire face à son héros lyrique.
La commande sudo est très importante pour gérer les droits d'accès dans le système d'exploitation Linux. Grâce à cette petite commande, vous pouvez accorder à d'autres utilisateurs l'autorisation d'effectuer certaines actions au nom de l'administrateur, sans leur donner le mot de passe de superutilisateur lui-même. De plus, vous n'avez pas besoin d'être toujours sous un compte superutilisateur pour effectuer occasionnellement des actions administratives.
Il semblerait qu'une si petite équipe, avec un minimum de capacités et une utilisation la plus simple possible, mais en réalité, elle peut faire bien plus. Dans cet article, nous verrons comment sudo est configuré sous Linux pour contrôler l'accès aux fonctions du système et aux capacités des utilisateurs.
Avant de passer à la configuration de l'accès à l'utilitaire sudo, regardons son fonctionnement. Il existe deux façons d'obtenir les droits d'administrateur sous Linux. Vous pouvez passer à l'utilisateur root à l'aide de la commande su, ou vous pouvez transmettre la commande souhaitée en paramètre à l'utilitaire sudo, qui l'exécutera avec les droits d'administrateur. De plus, la deuxième méthode est préférable, car vous n'oublierez pas ce que vous utilisez et ne ferez rien d'inutile.
Le nom de l'équipe signifie utilisateur remplaçant faire ou le super utilisateur le fait. L'utilitaire vous permet d'exécuter des programmes en tant qu'autre utilisateur, mais le plus souvent en tant qu'utilisateur root. L'utilitaire a été développé en 1980 par Bob Cogshell et Cliff Spencer. Pendant cette période, de nombreux développeurs ont changé et de nombreuses fonctionnalités ont été ajoutées.
sudo fonctionne grâce au drapeau d'accès SUID. Si cet indicateur est défini pour un programme, alors il est exécuté non pas au nom de l'utilisateur qui l'a lancé, mais au nom du propriétaire, étant donné que le fichier appartient à sudo, alors l'utilitaire est exécuté en tant que root. Il lit ensuite ses paramètres, demande le mot de passe de l'utilisateur et décide si l'utilisateur peut être autorisé à exécuter des commandes en tant qu'administrateur. Si oui, alors la commande passée en paramètre est exécutée.
Maintenant que vous connaissez la théorie, voyons comment configurer sudo sous Linux.
Configuration de sudo sous Linux
Tous les paramètres sudo se trouvent dans le fichier /etc/sudores. Ici, vous pouvez configurer de nombreux paramètres, en commençant par qui sera autorisé à exécuter des commandes au nom du superutilisateur et en terminant par la limitation de l'ensemble des commandes disponibles.
Pour ouvrir un fichier pour le modifier, tapez la commande suivante en tant que superutilisateur :
Vous pouvez également spécifier l'éditeur de texte dans lequel vous souhaitez éditer le fichier de configuration :
EDITEUR=nano visudo
Nous examinerons ensuite les paramètres les plus intéressants que vous pouvez définir dans ce fichier. Mais d’abord, regardons la syntaxe de base des fichiers. Il se compose de deux types de chaînes, ce sont des alias qui permettent de créer des listes d'utilisateurs et des drapeaux, ainsi que les règles elles-mêmes, qui précisent comment la commande sudo se comportera. La syntaxe de l'alias ressemble à ceci :
tapez nom_alias = élément1, élément2, élément3
Le type spécifie quel type d'Alice doit être créé, le nom est le nom qui sera utilisé et la liste des éléments spécifie les éléments qui seront implicites en faisant référence à ce nom.
La description des autorisations utilisateur a une syntaxe légèrement différente :
hôte utilisateur = (autre_utilisateur : groupe)équipes
L'utilisateur précise l'utilisateur ou le groupe pour lequel nous créons la règle, l'hôte est l'ordinateur pour lequel cette règle s'appliquera. Un autre utilisateur - sous le couvert de quel utilisateur le premier peut exécuter des commandes et le dernier peut exécuter des commandes autorisées. Un alias peut être utilisé à la place de n'importe lequel des paramètres. Et maintenant, configuration de sudo dans Debian et d'autres distributions.
Réglages principaux
L'alias Defaults vous permet de définir les paramètres standard pour le fonctionnement de l'utilitaire, que nous examinerons dans cette section. Un tel alias commence par le mot Defaults, suivi du nom du drapeau. S'il y a un symbole ! devant le nom, cela signifie que le drapeau doit être activé ; sinon, désactivez-le :
Désactivez l'introduction la première fois que vous l'utilisez :
Valeurs par défaut ! Conférence
Le superutilisateur ne peut pas faire sudo :
Valeurs par défaut !root_sudo
Maintenant, si vous essayez d'exécuter sudo sudo, rien ne fonctionnera :
Modifiez le répertoire personnel de l'utilisateur cible, en laissant le dossier de l'utilisateur actuel comme répertoire personnel par défaut :
Valeurs par défaut set_home
Enregistrez la liste des groupes de l'utilisateur actuel :
Valeurs par défaut !preserve_groups
Demander le mot de passe superutilisateur au lieu du mot de passe utilisateur :
Définissez le nombre de tentatives de mot de passe avant la fermeture de sudo, la valeur par défaut est 3 :
Valeurs par défaut passwd_tries=5
Le nombre de minutes qui s'écouleront avant que sudo ne demande à nouveau un mot de passe est par défaut de 5. Si vous définissez la valeur sur 0, il demandera toujours un mot de passe, quelle que soit la durée d'utilisation de l'utilitaire :
Valeurs par défaut timestamp_timeout=10
Le paramètre suivant spécifie le nombre de minutes pendant lesquelles sudo attendra qu'un mot de passe soit retapé s'il est mal saisi :
Valeurs par défaut passwd_timeout=10
Vous pouvez modifier le message qui s'affiche lorsque vous êtes invité à saisir un mot de passe :
Passprompt par défaut="Votre mot de passe :"
Vous pouvez spécifier un autre utilisateur, non root, à partir duquel toutes les commandes seront exécutées, pour cet usage :
Valeurs par défaut runas_default="user"
Vous pouvez enregistrer toutes les tentatives de connexion à sudo :
Fichier journal par défaut =/var/log/sudo
Ensuite, nous essayons de vérifier le fonctionnement du journal :
sudo cat /var/log/sudo
Ce sont tous les paramètres sudo les plus intéressants dont vous pourriez avoir besoin. Nous verrons ensuite comment définir les droits d'accès sudo pour les utilisateurs.
Configuration des utilisateurs sudo
Nous avons déjà évoqué ci-dessus la syntaxe de mise en place des actions pour les utilisateurs, ici tout est plus compliqué qu'avec les alias, mais vous pouvez le comprendre. Par exemple, permettons à n'importe quel utilisateur d'utiliser sudo, depuis n'importe quel hôte, et d'exécuter n'importe quelle commande :
TOUS TOUT = (TOUS) TOUS
Une telle équipe est très dangereuse, elle permet à tout le monde et à tout. Le premier ALL est d'autoriser tous les utilisateurs, le deuxième ALL est pour tous les hôtes, le troisième ALL est d'autoriser la connexion en tant qu'utilisateur et le quatrième est d'autoriser l'exécution de n'importe quelle commande. Mais une autre construction est beaucoup plus souvent utilisée :
%roue TOUT = (TOUS) TOUT
Cela signifie la même chose que le précédent, sauf qu'ici nous n'autorisons pas tous les utilisateurs à utiliser sudo, mais uniquement ceux qui sont membres du groupe wheel.
%wheel ALL = (racine) ALL
Ici, nous avons déjà limité le choix possible des utilisateurs au seul utilisateur root. Vous pouvez également préciser le groupe d'utilisateurs au nom duquel il peut exécuter des commandes :
%wheel ALL = (root:admins) TOUS
Cela signifie que vous pouvez exécuter la commande en tant que root ou en tant qu'utilisateur du groupe admins. Nous pouvons également spécifier des commandes que l'utilisateur peut exécuter. Par exemple:
%wheel ALL = (racine) /bin/mount, /bin/umount
L'utilisateur ne peut exécuter les commandes mount et umount qu'en tant que superutilisateur. Rendons maintenant les choses encore plus intéressantes, l'utilisateur peut exécuter mount et umount sans mot de passe, et toutes les autres commandes avec un mot de passe :
%wheel ALL = (racine) ALL
%wheel ALL = (racine) NOPASSWD : /bin/mount, /bin/umount
Vous pouvez également limiter les utilisateurs par hôte, par exemple, nous autorisons l'utilisation de sudo uniquement depuis l'hôte1 :
%wheel host1 = (racine) TOUS
Reste à réfléchir à la manière d'utiliser les alias. Les alias peuvent être des types suivants :
- Alias_utilisateur- alias des utilisateurs qui utiliseront sudo ;
- Runas_Alias- alias des utilisateurs pour le compte desquels les commandes seront exécutées ;
- Alias_hôte- pseudonyme de l'hôte ;
- Cmnd_Alias- alias de commande ;
Par exemple, créons quatre alias et utilisons-les dans notre règle :
User_Alias Utilisateurs = user1,user2,user3
Runas_Alias Admins = root,admin
Host_Alias Hôtes = hôte1,hôte2
Cmd_Alias Cmds = /bin/mount,/bin/umount
Utilisateurs hôtes = (administrateurs) Cmds
Cela signifie que les utilisateurs de la liste Utilisateurs pourront exécuter des commandes Cmds au nom des utilisateurs Amdins sur les hôtes Hosts.
Il reste encore quelques mots à dire sur les drapeaux. L'indicateur NOPASSWD vous indique de ne pas demander de mot de passe lors de l'exécution de cette règle. Par exemple, pour permettre à tous les utilisateurs d'exécuter la commande mount avec sudo sans mot de passe :
ALL ALL = (racine) NOPASSWD : /bin/mount
Vous pouvez également empêcher l'exécution de cette commande particulière en utilisant l'indicateur NOEXEC :
TOUS TOUS = (racine) NOEXEC /bin/mount
Vous pouvez vérifier si le fichier /etc/sudores a été correctement configuré et voir toutes les règles créées à l'aide de la commande :
Tous les indicateurs et paramètres installés sont affichés ici, ainsi que les autorisations de cet utilisateur.
conclusions
Dans cet article, nous avons vu comment configurer sudo sous Linux. Comme vous pouvez le constater, malgré le fait qu'il s'agisse d'un utilitaire très simple, il cache de nombreux paramètres utiles que vous pouvez utiliser sur votre système. Si vous avez des questions, posez-les dans les commentaires !
La séparation des droits d'accès est l'un des paradigmes de sécurité les plus importants mis en œuvre dans les systèmes d'exploitation Linux et de type Unix. Les utilisateurs réguliers travaillent avec des droits limités ; Cela réduit leur impact sur leur propre environnement et sur le système d'exploitation dans son ensemble.
L'utilisateur root dispose des privilèges de superutilisateur. Ce compte administrateur n'a pas les restrictions présentes sur les comptes d'utilisateurs réguliers. D'autres utilisateurs peuvent être en mesure d'exécuter des commandes en tant que root dans un certain nombre de cas spécifiques.
Ce guide vous montre comment transférer correctement et en toute sécurité les privilèges root sur votre système.
Note Remarque : ce didacticiel a été réalisé sur un serveur Ubuntu 12.04, mais la plupart des distributions Linux modernes se comporteront de la même manière.
Pour terminer le didacticiel, vous devez d'abord terminer la configuration initiale du serveur :
Connectez-vous au serveur en tant qu'utilisateur non root.
Comment obtenir les droits root
Il existe trois manières principales d'obtenir les privilèges de superutilisateur, dont la difficulté varie.
Connectez-vous en tant que root
Le moyen le plus simple est bien sûr de vous connecter en tant que root.
Si vous vous connectez via SSH, fournissez l'adresse IP ou le nom d'hôte :
ssh racine@adresse_IP_ou_domaine
Lorsque vous y êtes invité, entrez votre mot de passe root.
commande su
Il n'est pas recommandé d'utiliser constamment le compte root, car, disposant de droits d'accès absolus, vous pouvez accidentellement causer des dommages irréparables au système.
Par conséquent, le système dispose de la commande su, qui permet à un utilisateur ordinaire d'obtenir les droits root à tout moment.
Note: La commande su est l'abréviation de utilisateur remplaçant.
Donc pour rooter il suffit de taper :
Le système demandera le mot de passe de l'utilisateur root, après quoi il ouvrira l'accès à la session shell de l'utilisateur root.
Après avoir terminé toutes les tâches nécessitant les droits root, vous pouvez revenir à la session précédente :
commande sudo
La dernière façon d'obtenir les privilèges root consiste à utiliser la commande sudo.
La commande sudo permet d'exécuter des commandes spécifiques en tant que root sans avoir à ouvrir une nouvelle session.
sudo command_to_execute
Note: Contrairement à su, la commande sudo ne demande pas le mot de passe root, mais plutôt le mot de passe de l'utilisateur appelant la commande.
Pour des raisons de sécurité, la commande sudo n'est pas disponible par défaut, son accès doit être configuré. Si vous avez suivi le guide de configuration initiale du serveur, vous savez déjà comment procéder.
Qu’est-ce que Visudo ?
La commande sudo est configurée à l'aide du fichier /etc/sudoers.
Important! Ne modifiez jamais ce fichier à l’aide d’un éditeur de texte classique ! Pour ce faire, vous devez utiliser Visudo.
Une syntaxe incorrecte ajoutée à ce fichier peut complètement rompre la répartition des droits entre les utilisateurs. Par conséquent, la commande visudo est utilisée pour travailler avec ce fichier.
La commande visudo ouvre un fichier dans un éditeur de texte classique, mais vérifie sa syntaxe lors de l'enregistrement du fichier. Cela évite les erreurs de configuration.
Généralement, visudo ouvre le fichier /etc/sudoers dans l'éditeur vi. Sur un système Ubuntu, visudo utilise nano.
Pour configurer la commande visudo pour utiliser vi sur un système Ubuntu, exécutez la commande :
sudo update-alternatives --config éditeur
Il existe 3 choix pour l'éditeur alternatif (fournissant /usr/bin/editor).
Statut de priorité du chemin de sélection
————————————————————
* 0 /bin/nano 40 mode automatique
1 /bin/nano 40 mode manuel
2 /usr/bin/vim.basic 30 mode manuel
3 /usr/bin/vim.tiny 10 mode manuel
Sélectionnez le numéro correspondant à l'éditeur de texte que vous souhaitez utiliser.
Sur CentOS, cette valeur peut être modifiée en ajoutant la ligne suivante à ~/.bashrc :
export EDITOR=/chemin/vers/éditeur
Pour mettre à jour vos paramètres, saisissez :
Pour ouvrir /etc/sudoers, saisissez :
Modification du fichier sudoers
Ainsi, dans l'éditeur de texte de votre choix, le fichier sudoers s'ouvrira à l'écran.
Vous trouverez ci-dessous les paramètres du fichier système Ubuntu 12.04 (les lignes commentées sont omises et les modifications apportées lors de la configuration initiale du serveur sont enregistrées).
Note: Le fichier CentOS sudoers est beaucoup plus volumineux ; Certains de ses paramètres ne sont pas décrits dans ce manuel.
Valeurs par défaut env_reset
Valeurs par défaut secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
racine ALL=(TOUS:TOUS) TOUS
démo ALL=(ALL:ALL) ALL
%admin TOUS=(TOUS) TOUS
%sudo ALL=(TOUS:TOUS) TOUS
Paramètres standards
La première ligne, Defaults env_reset, réinitialise l'environnement du terminal pour supprimer toutes les variables utilisateur. Cette mesure de sécurité est utilisée pour éliminer les effets potentiellement nuisibles des variables d'environnement de la session sudo.
Le deuxième paramètre, Defaults secure_path=..., spécifie le chemin (PATH, points dans le système de fichiers où le système d'exploitation recherchera les applications) pour les opérations sudo. Cela empêche l’utilisation de chemins utilisateur potentiellement dangereux.
Paramètres des droits des utilisateurs
Les troisième et quatrième paramètres devraient vous être familiers. Vous avez ajouté vous-même la quatrième ligne, mais peut-être ne l’avez-vous pas examinée en détail.
- démo ALL=(ALL:ALL) ALL
- Le premier champ précise le nom de l'utilisateur à qui cette règle doit être appliquée (dans ce cas il s'agit d'une démo).
- Le premier ALL signifie que la règle s'appliquera à tous les hôtes.
- Le deuxième ALL signifie que l'utilisateur spécifié peut exécuter des commandes dans n'importe quelle session utilisateur.
- Le troisième ALL signifie que l'utilisateur spécifié peut exécuter des commandes dans n'importe quel groupe.
- Le dernier ALL indique que ces règles doivent être appliquées à toutes les commandes.
Cela signifie que les utilisateurs root et démo peuvent exécuter toutes les commandes en utilisant sudo avec leur mot de passe.
Paramètres de privilèges de groupe
Les deux dernières lignes sont similaires aux paramètres de privilèges utilisateur, mais elles sont responsables des droits de groupe.
Les noms de groupes commencent par le symbole %.
Comme vous pouvez le voir, le groupe d'administrateurs peut exécuter n'importe quelle commande en tant qu'utilisateur ou hôte. Le groupe sudo a des droits similaires, mais il peut également exécuter la commande comme n'importe quel groupe.
Règles personnalisées
Une fois que vous êtes familiarisé avec la syntaxe de base des fichiers, essayez de créer vous-même quelques règles.
Création d'alias
Le fichier sudoers peut être structuré plus facilement en utilisant divers alias.
Par exemple, vous pouvez créer trois groupes d'utilisateurs différents avec des droits combinés :
User_Alias GROUPONE = abby, brent, carl
User_Alias GROUPTWO = brent, doris, eric,
User_Alias GROUPTHREE = doris, felicia, subvention
Les noms de groupes doivent commencer par une lettre majuscule. Après cela, vous pouvez donner aux utilisateurs GROUPTWO le droit de modifier la base de données apt-get :
GROUPTWO ALL = /usr/bin/apt-get update
Si la règle ne spécifie pas d'utilisateur ni de groupe, sudo est par défaut root.
Vous pouvez ensuite autoriser les utilisateurs de GROUPTHREE à arrêter et redémarrer la machine ; Pour ce faire, vous devez créer un alias de commande :
Cmnd_Alias POWER = /sbin/shutdown, /sbin/halt, /sbin/reboot, /sbin/restart
GROUPE TROIS TOUS = PUISSANCE
L'alias de commande POWER contient des commandes permettant d'arrêter et de redémarrer la machine.
Vous pouvez également créer un alias, Exécuter en tant que, qui remplace la partie de la règle qui spécifie l'utilisateur dans la session duquel la commande doit être exécutée.
Runas_Alias WEB = www-data, apache
GROUPONE TOUS = (WEB) TOUS
Désormais, tout utilisateur du groupe GROUPONE peut exécuter des commandes dans les sessions utilisateur www-data ou apache.
Note Remarque : N'oubliez pas que les règles créées précédemment sont prioritaires en cas de conflit de règles.
Règles de blocage
Il existe plusieurs façons de contrôler le comportement de sudo et sa réponse aux appels.
Par exemple, la commande updateb en combinaison avec le package mlocate est relativement inoffensive. Pour qu'un utilisateur ordinaire puisse l'exécuter avec les privilèges de superutilisateur sans saisir de mot de passe, vous pouvez créer la règle suivante :
GROUPONE TOUS = NOPASSWD : /usr/bin/updatedb
La commande NOPASSWD signifie que le système ne demandera pas de mot de passe. Il existe également une commande PASSWD qui effectue le comportement inverse et est utilisée par défaut.
NOPASSWD s'applique à l'intégralité de la règle, sauf si la commande PASSWD la remplace. Par exemple, la ligne pourrait ressembler à ceci :
GROUPTWO ALL = NOPASSWD : /usr/bin/updatedb, PASSWD : /bin/kill
Une autre commande pratique est NOEXEC, utilisée pour empêcher le comportement dangereux de certains programmes. Par exemple, certaines commandes, comme less, peuvent appeler d'autres commandes :
Cette commande exécute n'importe quelle commande avec les privilèges de l'utilisateur en cours d'exécution, ce qui peut être très dangereux.
Pour éviter ce comportement, vous pouvez utiliser la ligne suivante :
nom d'utilisateur ALL = NOEXEC : /usr/bin/less
Informations Complémentaires
Cette section contient divers conseils utiles pour travailler avec sudo.
Si vous avez spécifié un utilisateur ou un groupe dans le paramètre Exécuter en tant que, vous pouvez exécuter des commandes dans la session de cet utilisateur en utilisant respectivement les indicateurs -u et –g :
Commande sudo -u run_as_user
Commande sudo -g run_as_group
Par défaut, sudo stocke les informations d'identification dans un terminal pendant un certain temps. Cela signifie que vous n’aurez pas à saisir à nouveau votre mot de passe pendant cette période.
Si pour des raisons de sécurité vous souhaitez réinitialiser ce timer, utilisez la commande :
Pour connaître les droits de l'utilisateur, saisissez :
Cette commande listera toutes les autorisations spécifiées dans le fichier /etc/sudoers pour un utilisateur donné.
Si un utilisateur normal essaie d'exécuter une commande d'administrateur sans le préfixe sudo, la commande ne fonctionnera pas. Pour éviter d'avoir à retaper la commande, utilisez une fonction bash qui répète la commande :
Un double point d'exclamation répétera la dernière commande.
Conclusion
Vous disposez désormais de compétences de base avec le fichier sudoers et les autorisations root.
Lorsque vous travaillez avec des droits de superutilisateur, n'oubliez pas que les utilisateurs réguliers ne disposent pas de tels droits par défaut pour des raisons de sécurité. N'abusez pas des droits root, sinon vous pourriez accidentellement causer des dommages irréparables au système.
Mots clés: ,Parfois, il vous suffit d'exécuter une commande d'un autre utilisateur. Et il existe plusieurs manières d’y parvenir. J'en parlerai dans mon article « Exécuter une commande en tant qu'autre utilisateur sous Unix/Linux ».
Exécuter une commande en tant qu'autre utilisateur sous Unix/Linux - méthode 1
Et ainsi, vous pouvez utiliser l'utilitaire SUDO. Regardons un exemple :
$ sudo -H -u Votre_autre_utilisateur -c "ping site"
Explications :
- -H YOUR_HOME : définit HOME (variable d'environnement pour le domicile d'un utilisateur spécifique) et est par défaut root.
- -u YOUR_USER : Spécifiez l'utilisateur à partir duquel la commande sera exécutée.
- -c YOUR_COMMAND : sert d'option pour saisir une commande.
Quelque chose comme ça.
Exécuter une commande en tant qu'autre utilisateur sous Unix/Linux - méthode 2
Vous pouvez utiliser l'utilitaire SU. Et maintenant je vais donner quelques exemples.
Connectez-vous en tant qu'utilisateur root
Pour obtenir le root, exécutez :
$su - racine
Exécutez la commande en tant qu'utilisateur root
Voici un exemple de commande :
# su - root -c "VOTRE_COMMAND_HERE"
Su - -c "VOTRE_COMMAND_HERE arg1"
Exécuter une commande d'un autre utilisateur en utilisant su
Voici donc un exemple :
# su -c "/opt/solr/bin/solr create -c test_solr_core -n solrconfig.xml" -s /bin/sh solr Création d'un nouveau noyau "test_solr_core"
Regardons un autre exemple :
$ su autre_utilisateur -c "ping du site"
$su -VOTRE_USER -c "VOTRE_COMMAND_ICI"
- — — Simulera la connexion de l'utilisateur spécifié.
- -c - Utilisé pour spécifier la commande à exécuter (pour l'utilisateur spécifié).
Quelque chose comme ça.
Exécuter une commande en tant qu'autre utilisateur sous Unix/Linux - méthode 3
Et ainsi, vous pouvez utiliser l'utilitaire runuser. La commande runuser démarre un shell avec des ID d'utilisateur et de groupe de remplacement. Cette commande n'est utile que lorsque vous êtes connecté en tant que root. La syntaxe est la suivante :
# runuser -l VOTRE_USER -c "VOTRE_COMMAND_HERE"
A titre d'exemple, je vais montrer la ligne suivante :
# runuser -l nginx -c "service nginx start"
PS : La commande runuser ne nécessite pas de mot de passe et ne doit être exécutée que par l'utilisateur root.
Options principales :
- -l : crée un shell de connexion en utilisant le fichier PAM runuser-l au lieu de celui par défaut.
- -g : pointe vers le groupe principal.
- -G : Indique un groupe supplémentaire.
- -c : En fait, il est utilisé pour spécifier une commande.
- –session-command=COMMAND : passez une seule commande au shell avec l'option « -c » et ne crée pas de nouvelle session.
- -m : ne réinitialise pas les variables d'environnement (ENV).
Ça y est, le sujet "Exécuter une commande en tant qu'autre utilisateur sous Unix/Linux" est terminé.
Depuis l'Antiquité, beaucoup ont été déconcertés par la variété des options de sécurité lors de l'exécution d'opérations avec des privilèges maximaux. Par exemple, dans la documentation officielle d'Ubuntu, il est recommandé d'utiliser quelque chose comme sudo nano comme commande d'édition, et dans de nombreux manuels amateurs (dans le style de « 5 astuces en ligne de commande qui surprendront votre grand-mère ») pour obtenir un shell racine. est suggéré d'écrire sudo su - je vais essayer d'expliquer pourquoi cet état de fait me semble erroné.
Historiquement, le seul moyen universel d'exécuter une commande en tant qu'autre utilisateur sous Unix était d'utiliser le programme su. Lancé sans paramètres, il a demandé le mot de passe du superutilisateur et, en cas de succès, a simplement remplacé le nom d'utilisateur actuel par root, laissant presque toutes les variables d'environnement de l'ancien utilisateur (sauf PATH, USER et quelques autres, voir man su de votre distribution ). Il serait plus correct de l'exécuter en tant que su - auquel cas le shell recevrait également le bon environnement. Avec l'option -c, vous pouvez exécuter la commande : su -c "vim /etc/fstab" .
Dans ce cas, les utilisateurs de confiance devaient se souvenir du mot de passe root, et tous les utilisateurs répertoriés dans le groupe « wheel » (c'est-à-dire dans le groupe dont les membres pouvaient exécuter la commande su et devenir superutilisateur) avaient le même accès illimité à l'ensemble de l'utilisateur. système, ce qui constituait un grave problème de sécurité.
Ensuite, la commande sudo est arrivée et ce fut une avancée décisive. Désormais, l'administrateur peut spécifier une liste de commandes autorisées pour chaque utilisateur (ou groupe d'utilisateurs), des fichiers disponibles pour l'édition, des variables d'environnement spéciales et bien plus encore (toute cette beauté est contrôlée depuis /etc/sudoers, voir man sudoers depuis votre distribution) . Une fois lancé, sudo demande à l'utilisateur son propre mot de passe, pas le mot de passe root. Un shell complet peut être obtenu en utilisant "sudo -i"
Il convient de noter en particulier la commande spéciale sudoedit, qui lance en toute sécurité l'éditeur spécifié dans la variable d'environnement $EDITOR. Avec un schéma plus traditionnel, l'édition des fichiers se faisait à peu près comme ceci :
sudo vi /etc/fstab
Lancé de cette manière, vi a hérité du shell avec des droits illimités et via :! l'utilisateur pouvait exécuter n'importe quelle commande (à moins, bien sûr, que l'administrateur ne s'en soit occupé à l'avance) et ouvrir n'importe quel fichier.
Sudoedit vérifie si cet utilisateur peut modifier un fichier donné, puis copie le fichier spécifié dans un répertoire temporaire, l'ouvre dans un éditeur (qui hérite des droits de l'utilisateur, pas de root), et après édition, si le fichier a été modifié, le copie avec des précautions particulières.
Sur les distributions basées sur Debian, l'utilisateur root n'a pas de mot de passe ; à la place, toutes les actions administratives doivent être effectuées via sudo ou son équivalent graphique gksudo. Étant un remplacement complet de su , sudo devrait être la seule commande permettant de basculer entre les utilisateurs, cependant, comme cela a été dit au début, ce n'est pas le cas pour le moment et pour une raison quelconque, tout le monde invente des séquences sauvages de sudo, su, vi et des tirets.
Par conséquent, je suggère à chacun de se rappeler une fois pour toutes :
Après la première publication de cette note, plusieurs questions m’ont été posées. À partir des réponses, nous avons réussi à créer une mini-FAQ.
Q : Comment puis-je utiliser sudo pour faire su -c "echo 1 > /etc/privileged_file" ? sudo echo 1 /etc/privileged_file se plaint de « autorisation refusée »
R : Cela se produit car seule la commande echo est exécutée avec des droits élevés et le résultat est redirigé vers le fichier avec les droits d'un utilisateur normal. Pour ajouter quelque chose à privilèged_file, vous devez exécuter la commande suivante :
$ écho 1| sudo tee -a fichier_privilégié >/dev/null
Ou devenez temporairement root :
$ sudo -i # echo 1 > fichier_privilégié # exit $
Q : sudo -i est plus long que su - , mais il ne semble y avoir aucune différence entre eux, pourquoi en imprimer plus ?
R : sudo présente plusieurs avantages qui valent la peine de taper quelques caractères supplémentaires :
- par défaut, sudo enregistre toutes les activités des utilisateurs dans le canal syslog authpriv (en règle générale, le résultat est placé dans le fichier /var/log/auth.log), et dans ce cas, une fonctionnalité similaire doit être activée en définissant un paramètre spécial dans le fichier de paramètres, qui varie d'une distribution à l'autre (SULOG_FILE dans /etc/login.defs sur Ubuntu Linux, /etc/login.conf et /etc/pam.d/su sur FreeBSD, etc.)
- dans le cas de su, l'administrateur système ne peut pas restreindre les commandes exécutées par les utilisateurs, mais dans sudo, il peut
- si l'utilisateur doit être privé des droits d'administration, dans le cas de su, après l'avoir retiré du groupe wheel, il doit oublier le mot de passe root ; si sudo est utilisé, il suffit de le supprimer du groupe correspondant (par exemple, wheel ou admin) et/ou le fichier sudoers, s'il a été personnalisé davantage.
R : Je vais répondre à la question par une question : s’il existe un sudo correct, pourquoi utiliser le su obsolète ?
