Pour pouvoir utiliser sudo, voici comment le configurer. Avec les droits root, appelez visudo:
[code]$ su
visudo[/code]
Ajoutez cette ligne dans le fichier ainsi ouvert:
Quittez avec ctrl+x, choisir oui pour enregistrer.
Vous pouvez maintenant utiliser sudo.
[moderation]AVERTISSIMENT
Cette façon de procéder est contraire à la règle de sécurité qui est de mise sous Debian.
Comme dit ailleurs, cette méthode est employée sous Ubuntu mais nous ne sommes pas partisans de la préconiser.
La modération.[/moderation]
adduser le_user sudo
et ils désactivent root: (comme le user à tous les droits root maintenant) passwd -l root
pour le réactiver: passwd -u root
perso: j’ai désactivé root, (nom beaucoup trop connu) mais hors de question que le user principal qui reste logué aient tous les droits avec sudo comme chez Ubuntu, alors j’ai crée un utilisateur aux droits root dont je ne me sers jamais.
et quand j’ai besoin de commande root: su user et sudo commande…
C’est quoi cette manie de vouloir utiliser sudo pour tout et n’importe quoi (et n’importe qui).
c’est pas windows ou autre distribution qui veut y ressembler ici.
c’est debian, et si ce n’est pas configurer comme ça par défaut par les devs de cette distributions, renseignez vous pour comprendre pourquoi.
Très franchement [mono]sudo[/mono] déchire. Il permet de faire la même chose que su si on le souhaite (passer en root en donnant le mot de passe root) tout en permettant de configurer un tas de chose comme l’environnement dans le quel s’exécute le programme appelé.
Personnellement j’utilise [mono]sudo[/mono] notamment parce que ça me simplifie la tâche. Je commence par faire des commandes avec mon utilisateur et je peux lancer une commande avec les droits qui vont bien avec mon historique courant (donc en réutilisant mes variables et mon historique) chose peu agréable avec l’option [mono]-c[/mono] de [mono]su[/mono].
J’utilise également sudo, mais avec quelques précautions et en m’obligeant à redonner mon pass pour toutes les opérations qui mettent en péril mon système.
Je tiens également compte de T&A où François recommandait l’utilisation de :
Mouais
Niveau sécurité, ça n’change rien par rapport à se connecter en root
Niveau utilisabilité, mettre sudo devant chaque commande (ou su - machin -c sudo bidule), n’est-ce pas un peu contraignant ?
[quote=“haleth”]Mouais Niveau sécurité, ça n’change rien par rapport à se connecter en root
Niveau utilisabilité, mettre sudo devant chaque commande (ou su - machin -c sudo bidule), n’est-ce pas un peu contraignant ?
Bref;[/quote]
Vrai si ton MDP ‘root’ est de la même compexité que ton MDP ‘user’.
Faux si, et c’est mon cas, ton MDP ‘root’ est plus complexe.
[moderation]Ce débat devient du “PC”, je l’y bascule.[/moderation]
[quote=“ricardo”][quote=“haleth”]Mouais Niveau sécurité, ça n’change rien par rapport à se connecter en root
Niveau utilisabilité, mettre sudo devant chaque commande (ou su - machin -c sudo bidule), n’est-ce pas un peu contraignant ?
Bref;[/quote]
Vrai si ton MDP ‘root’ est de la même compexité que ton MDP ‘user’.
Faux si, et c’est mon cas, ton MDP ‘root’ est plus complexe.[/quote]
Faux, c’est comme tu le souhaite (comme dis plus haut).
Tu ajoute la configuration [mono]rootpw[/mono] et sudo te demandera le mot de passe root. Tu peut aussi utiliser [mono]targetpw[/mono] et c’est le mot de passe de l’utilisateur cible qui te sera demandé (root si tu deviens root).
Si tu veut vraiment jouer avec de la sécurité tu peut jouer à créer des groupes et utilisateurs spécifiques qui ont des droits limités mais précis et lancer certaines commandes qu’avec eux. Ça c’est plus agréable avec sudo.
Avec su, il faut faire gaffe à ne pas laisser de session ouverte, il faut pour ça ajouter [mono]readonly TMOUT=n[/mono] avec n le nombre de secondes du timeout.
Si tu veut tracer les élévations de privilèges avec su il faut regarder les log de connexions classiques avec sudo tu peut en plus avoir un des mails lors de tentatives et échecs.
Bref avec sudo AMHA tu peut faire tout ce que tu fait avec su en plus pratique et avec une configuration plus simple tout en ayant plus de flexibilité (tu peut faire des choses avec sudo que tu ne pourra jamais faire avec su).
On peut critiquer la configuration par défaut de sudo, mais fonctionnellement je pense qu’il n’y a pas photo.
Une chose que je n’ai jamais comprise :
Pourquoi y-aurait-il plus de sécurité à utiliser sudo si l’“user” à TOUS les droits ?
Quelle différence entre laisser ‘root’ ouvert (je sais qu’il ne faut pas faire)
et laisser l’“user” ouvert, si ce dernier a TOUS les droits ?
On lit tout et n’importe quoi sur l’utilisation de sudo.
Il serait intéressant de faire un VRAI débat, avec des personnes compétentes, donc pas moi, mais je serais intéressé par les déductions.
[quote=“ricardo”]Une chose que je n’ai jamais comprise :
Pourquoi y-aurait-il plus de sécurité à utiliser sudo si l’“user” à TOUS les droits ?
Quelle différence entre laisser ‘root’ ouvert (je sais qu’il ne faut pas faire)
et laisser l’“user” ouvert, si ce dernier a TOUS les droits ?[/quote]
Hum, je ne sais pas qui a dit ça, mais sudo à l’avantage de t’obliger à dire « je veux exécuter cette commande avec tel privilège ». Sa facilité d’utilisation fait que tu ne va utiliser des droits dangereux qu’au minimum (que pour les actions qui le réclament vraiment) quitte à lancer une commande, se rendre compte qu’on a pas les bons droits et lancer [mono]sudo !![/mono].
Après je ne dis pas qu’il faut en faire tout et n’importe quoi, mais on peut facilement avoir une configuration qui convient bien et qui est plus agréable à utiliser que [mono]su[/mono].
[quote=“MisterFreez”]
… Après je ne dis pas qu’il faut en faire tout et n’importe quoi, mais on peut facilement avoir une configuration qui convient bien et qui est plus agréable à utiliser que [mono]su[/mono].[/quote]
Voilà où je voulais en venir : la liste (en général, bien sûr) de ce qu’on peut faire avec sudo dans trop de dommages et celle de ce qui appelle impérativement d’être ‘root’.
Ensuite, le façon de traduire ça, soit en ligne directement, soit en définition dans ‘sudoers’.
je vois trop de personnes dont les MDP ‘user’ sont du genre “Médor” et dont le MDP ‘root’ n’est guerre plus complexe.
EDIT :
Si vous voulez, on peut commencer par ce qui doit être “impérativement” commandé sous ‘root’ ?
Tu utilise le mot de passe root pour passer root.
L’élévation est cloisonnée au tty.
Si tu lance 3 sudo à la suite il ne te demandera qu’une seule fois le mot de passe.
C’est largement plus agréable que su et je ne vois pas de risque particulier.
Le problème de mot de passe dont tu parle n’a rien avoir avec su/sudo.
Historiquement, sudo était prévu pour autoriser ponctuellement une opération à un utilisateur ou un groupe d’utilisateur.
Exemple: Autoriser www-data à lire un log précis sur une période donnée, Autoriser www-data à lire un fichier perso, autoriser un utilisateur à installer des paquets (utile sur une machine perso).
Sur une machine personnelle, cela peut être effectivement utile de séparer certaines applications que l’ont fait fréquemment et peu dangereuses pour la machine (apt-get est un exemple, il est rare de se tromper sur la syntaxe d’apt-get et de tout désinstaller sans levouloir, un rm -Rf dans un mauvais répertoire est plus vite écrit). sudo est une bonne idée pour ça.
Que sudo deviennent un équivalent de su me parait personnellement une mauvaise idée et détourne ce qu’était le sudo à l’origine. La sécurité d’unix vient de la différence entre les utilisateurs. Réunifier les comptes root et user via le sudo fait réapparaitre le compte administrateur de windows. Bien configuré il n’y a pas de problèmes, mais ça peut être mal configuré. Il n’existe pas de mauvaise configuration du compte root. Il existe avec un bon mot de passe, c’est tout.
Je fesais ça, avant
Et puis, je me suis rendu compte que, à la vue d’un “permission denied”, je rajoutais sudo instinctivement
M’enfin, j’utilise régulièrement sudo, en particulier pour faire des probes de supervision (exemple typique : autoriser la supervision à compulser le status de fail2ban ou autre), sans faire tourner ledit système sous root
Je me rapproche plus du point de vue de François mais certains “aménagements” proposé par Michel semblent avoir un intérêt.
J’ai aussi entendu des sons de cloche différents sur l’utilisation de ‘root’ sur console graphique ou exclusivement sur TTY.
Il serait intéressant de faire quelques listes :
ce qu’on peut faire sans risques sous sudo
ce qu’on doit faire exclusivement sous root
Quelle différence entre :
placer un utilisateur dans le groupe sudo
placer un utilisateur comme ALL (ALL) ALL
aucune ou il y a une subtilité que j’ignore
On a pas besoin de sudo pour ça. La gestion des groupes et les droits unix ou les ACL suffisent voir font mieux (pour www-data, je préfère lui donner les droits qui vont bien et qui lui permettent de faire un [mono]open()[/mono] dans le langage CGI qu’il souhaite que de lui faire faire un [mono]fork()[/mono]/[mono]exec()[/mono] (plus couteux et plus dangereux). Si sudo a était fait pour ça il n’a jamais était une solution pertinente.
Je ne suis pas d’accord. Il est rare de jouer avec 2 shells ou de faire des aller-retour entre ton utilisateur et root avec su parce que c’est très rébarbatif. Donc si tu as quelque chose à faire tu commence avec ton utilisateur puis dès que tu va avoir besoin des privilèges root, tu va passer en root et ne plus le quitter, tu va donc faire bien plus de commande sans aucune restriction et c’est là que tu risque le plus de faire des erreurs.
De plus il n’est pas moins dangereux de faire un [mono]rm -rf ${HOME}[/mono] avec les droits utilisateur qu’un [mono]rm -rf /[/mono] avec les droits root. Ce qui importe l’utilisateur ce sont ces données et alors que les données du système sont plus facile à reproduire. La seule solution correct à ça c’est le shell qui la fourni.
Le détournement de logiciel ne me dérange pas c’est l’un des principes du LL.
Oula pas la peine de monter sur tes grands chevaux en nous parlant de Windows.
D’une part j’ai expliqué et montré plus haut que sudo peut être configuré pour être un équivalent à [mono]su[/mono] (demande systématique du mot de passe de l’utilisateur cible) à la différence pour pour ouvrir un shell complet et permanent au lieu de faire [mono]su -[/mono], il faudra faire [mono]sudo -s[/mono] (ce dernier peu être interdit par la conf’) et pour lancer une commande unique il faudra faire [mono]sudo cmd[/mono] au lieu de [mono]su -c “cmd”[/mono]. Dans ces cas là on voit que sudo privilégie l’utilisation limité des droits à une commande précise là où su sert surtout à créer un shell qui sera utilisé plus longtemps. Ça c’est bénéfique pour la sécurité, c’est contribue à la séparation des privilèges (une commande n’es lancée avec les droits root que si elle en a réellement besoin). C’est un concept qu’on retrouve aussi dans policykit.
D’autre part, il n’y a pas de mélange comme tu le dis. Que l’utilisateur toto puisse passer root via su ou via sudo ça ne change rien au fait qu’il puisse passer root. Au contraire c’est bien plus proche de ce que l’on trouve actuellement dans windows (depuis vista) avec des élévations de privilèges ponctuels. Le parallèle entre des logiciels comme gksu et le UAC windows sont quand même flagrant et montrent juste qu’on réduit les droits utilisateur et qu’on améliore l’élévation ponctuel des privilèges en les rendant plus simple et plus facile à tracer. Avant sous windows le premier utilisateur était root et sous unix on utilise un compte pour l’administration, mais avec ce compte on fait plus que ce que l’on devrait faire.
Je ne vous parle pas de choses en l’air, j’ai vu à plusieurs reprises des problèmes sur des machines parce que les gens font trop de choses en root soit ils cassent, soit on se retrouve avec les mauvais droits sur des fichiers et l’utilisateur légitime de ces fichiers ne peux plus s’en servir.
On peut toujours casser le système. On parle de donner des accès root quelque soit la manière dont tu le fait il est toujours possible volontairement ou pas de détruire tout ou partie du système. La question c’est est-ce qu’il vaut mieux lancer un shell complet et faire le job avec lui ou utiliser les droits root uniquement pour les commandes qui le demande ? ÀMHA la deuxième solution est la meilleure.
Edit : ce qui crée un mélange entre root et les autres utilisateurs systèmes c’est plus le stiky-bit que sudo. Encore une fois ce n’est pas parce qu’on crée une commande qui rend plus simple l’utilisation de su que ça change quelque chose.
(d’ailleurs sous zsh vous pouvez faire :
function rootdo () {
su - -c "$*"
}
compdef _precommand rootdo
[quote=“ricardo”]Il serait intéressant de faire quelques listes :
ce qu’on peut faire sans risques sous sudo[/quote]
Rien comme pour su lancer un programme avec les privilège root c’est dangereux quelque soit la manière d’escalader les privilèges.
Je ne comprends pas très bien ? Tout ce qui est dans /sbin et /usr/sbin ?
[quote=“ricardo”]Quelle différence entre :
placer un utilisateur dans le groupe sudo
placer un utilisateur comme ALL (ALL) ALL
aucune ou il y a une subtilité que j’ignore [/quote]
Je regarderais demain.
Pas la peine d’en faire une tartine. J’ai donné mon opinion sur un pbm qui dépend des habitudes de chacun et de la façon de voir les choses de chacun. Le reste me parait plus un débat type vim/emacs avec un intérêt limité. Faire sans arrêt «su -c» revient à faire une batterie de sudo. Travailler constamment en root revient à configurer le sudo sans mot de passe et au final il y a autant de façons de planter la machine. Je n’aime pas sudo mais je n’empêche personne de l’utiliser comme je n’oblige personne à aimer les Islay… (et pourtant, là je ne comprend vraiment pas comment on peut ne pas aimer!)
