Vous n'êtes pas identifié(e).
Ainsi, toto ne peut plus modifier le mot de passe de root en faisant 'sudo passwd root'.
Mais, toto peut faire encore 2 choses :
Modifier le fichier /etc/sudoers en supprimant la ligne qui le restreint. Comment lui bloquer cela ?
et même faire 'sudo -i' pour devenir root, avec le mot de passe de toto !, et donc pouvoir faire le changement de mot de passe de root!
Comment empêcher toto de faire cela ?
Est-ce qu'il y aurait d'autres points critiques à protéger ?
edit: c'est corrigé pour le point d'exclamation, merci mksmn
Dernière modification par totoZero7 (03-11-2022 16:14:59)
Hors ligne
Hors ligne
Debian, c'est bien!
(De retour sous Debian, soyez cool.)
Hors ligne
- Tour : 4 × Intel® Core™ i5-4570 CPU @ 3.20GHz × 4 - RAM 12 Go - Carte graphique GeForce GTX 750 Ti NV117 - Écran 24" et 23" hdmi
- Lenovo IdeaPad 3 15ALC6 - 15.6" - Ryzen 5 5500U - 16 Go RAM - 128 Go SSD + 1 To HDD
- Lenovo Ideapad S130-14IGM
- ASUS F751L X751LA : 4 × Intel® Core™ i3-4030U CPU @ 1.90GHz - 8 Go de RAM - SSD 128 Go
Hors ligne
Tu devrai faire une liste blanche de ce qui est autorisé plutôt qu'une liste noire,
Tu peux définir des alias de commande avec visudo. Comme ça, sudo est "restreint" à ce que tu as défini.
Je suppose que vous dites la même chose ?
Si je prends le problème dans l'autre sens (faire une liste blanche), là ça se complique car je ne sais pas ce que je dois donner à toto pour que tout fonctionne comme d'habitude.
Aussi, je pense ne pas bien comprendre la problématique de différence entre toto (mon user), que j'utilise quotidiennement et root. J'emploie toto un peu à la manière root en métant sudo assez régulièrement.
Peut-être devrais-je modifier mon comportement, mais je ne sais pas par où commencer.
Je me souviens, quand j'ai installé Debian pour la première fois, j'ai été obligé de mettre toto avec les droits root dans sudoers, pour faire ne serait-se qu'une mise à jour des paquets et du système.
Je ne me suis jamais préoccupé de vérifier la différence de fonction entre ces deux là.
C'est aujourd'hui, en testant la commande "sudo -i" que je découvre cela, après pas mal d'années sur Debian en plus ! (on peut être toujours nul après tant d'année...).
Du coup, je pose une autre question.
Est-ce utile de séparer les droits entre user et root me concernant ?
Dernière modification par totoZero7 (29-10-2022 13:39:06)
Hors ligne
Peut-être devrais-je modifier mon comportement, mais je ne sais pas par où commencer.
Je pense que ce qu'il faut comprendre c'est la relation entre les comptes utilisateurs et les droits (lecture, écriture, exécution) définis pour chaque fichier (au sens large, ça inclut les répertoires, fifos...) pour le propriétaire, le groupe et "les autres". C'est ce qui définit qui a accès à quoi, qui peut exécuter quoi, et ça répond en conséquence aux questions que tu te poses ci-dessus bien au delà de l'utilisation de sudo.
Dernière modification par anonyme (29-10-2022 12:40:50)
Est-ce utile de séparer les droits entre user et root me concernant ?
Perso, sur un poste de travail où je suis le seul utilisateur, je ne défini pas de mot de passe root à l'installation et utilise donc sudo à la mode Ubuntu
Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.
Hors ligne
Je me souviens, quand j'ai installé Debian pour la première fois, j'ai été obligé de mettre toto avec les droits root dans sudoers, pour faire ne serait-se qu'une mise à jour des paquets et du système.
Pourquoi donc ..?
Sûrement de là que t'as mal interprété la différence utilisateur / super-utilisateur ....
En ligne
Sûrement de là que t'as mal interprété la différence utilisateur / super-utilisateur ....
Si tu définis un mot de passe root à l'installation, sudo n'est pas installé d'office il me semble, ou si il l'est, il faut le configurer à la main comme l'indique totoZero7.
Si tu ne défini pas de mot de passe root, sudo est installé et configuré pour donner les droits admin au premier utilisateur créé.
Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.
Hors ligne
Si tu ne défini pas de mot de passe root, sudo est installé et configuré pour donner les droits admin au premier utilisateur créé.
Ça je le comprends, mais
obligé de mettre toto avec les droits root dans sudoers, pour faire ne serait-se qu'une mise à jour des paquets et du système.
comment ça, ça se passe ? bien avec root, ....
sinon, lors d'une configuration sans mot de passe root, j'imagine que sudo a déja tous les droits ne serait-ce pour faire une mise à jour ....
En ligne
Je pense que ce qu'il faut comprendre c'est la relation entre les comptes utilisateurs et les droits
Je vois comment dire à bidule si il peut avoir accès à tel répertoire/fichier.
En revanche, je maitrise très mal la vision que peut faire, dans l'ensemble, un utilisateur par rapport à un admin sur un PC.
Pour dire cela d'une autre manière:
Supposons que demain, j'ouvre une session pour une personne de confiance, qui n'est pas complètement à l'aise avec la machine, mais que je l'autorise quand même à installer des paquets.
Est-ce qu'il y a des restrictions à mettre tout de même à cette personne ou est-ce que l'autoriser à installer des paquets est synonyme de comportement root ?
Hors ligne
Pour dire cela d'une autre manière:
Supposons que demain, j'ouvre une session pour une personne de confiance, qui n'est pas complètement à l'aise avec la machine, mais que je l'autorise quand même à installer des paquets.
Est-ce qu'il y a des restrictions à mettre tout de même à cette personne ou est-ce que l'autoriser à installer des paquets est synonyme de comportement root ?
Comme je l'ai indiqué : tu peux définir des alias de commande avec visudo. Comme ça, sudo est "restreint" à ce que tu as défini. En gros, tu accordes à un utilisateur certains droits comme l'installation de paquets ou autre selon ce que tu as défini.
Tu as des explications ici
- Tour : 4 × Intel® Core™ i5-4570 CPU @ 3.20GHz × 4 - RAM 12 Go - Carte graphique GeForce GTX 750 Ti NV117 - Écran 24" et 23" hdmi
- Lenovo IdeaPad 3 15ALC6 - 15.6" - Ryzen 5 5500U - 16 Go RAM - 128 Go SSD + 1 To HDD
- Lenovo Ideapad S130-14IGM
- ASUS F751L X751LA : 4 × Intel® Core™ i3-4030U CPU @ 1.90GHz - 8 Go de RAM - SSD 128 Go
Hors ligne
Dernière modification par totoZero7 (29-10-2022 14:54:21)
Hors ligne
Je pense que ce qu'il faut comprendre c'est la relation entre les comptes utilisateurs et les droits (lecture, écriture, exécution) définis pour chaque fichier
Les privilèges de root (UID=0) vont bien au-delà des permissions sur les fichiers.
sur un poste de travail où je suis le seul utilisateur, je ne défini pas de mot de passe root
Et tu réaliseras que c'est une mauvaise idée si tu te retrouves dans une situation où le mot de passe root est indispensable, comme par exemple le démarrage en mode dépannage ou l'impossibilité d'ouvrir une session utilisateur.
Si tu définis un mot de passe root à l'installation, sudo n'est pas installé d'office
Il peut être installé par dépendance de l'environnement de bureau (recommandé par task-desktop) ou d'un autre paquet.
Dernière modification par raleur (29-10-2022 16:10:58)
Il vaut mieux montrer que raconter.
Hors ligne
est-ce que l'autoriser à installer des paquets est synonyme de comportement root ?
Oui, ce privilège est suffisant pour acquérir le droit d'exécuter n'importe quelle commande en root.
Il vaut mieux montrer que raconter.
Hors ligne
Oui, ce privilège est suffisant pour acquérir le droit d'exécuter n'importe quelle commande en root.
hum, pour aller à l’extrême, peut-il aller... jusqu'à prendre la place de root en modifier/supprimer son mot de passe par exemple ? ou faire des modifications qui ne lui sont pas initialement attribué, comme écrire dans sudoers ?
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
du coup, la liste blanche ne sert à rien.
Si, mais à condition de n'y inclure que des commandes qui ne permettent pas d'obtenir une élévation de privilège, ce qui n'est pas le cas d'apt-get ou dpkg.
dpkg ou apt permettent d'installer n'importe quel paquet .deb arbitraire pouvant par exemple contenir un exécutable suid ou un script de préinstallation exécuté en root, donc exclu.
apt-get ne permet d'installer que des paquets des dépôts définis
[EDIT : en fait non, il permet aussi d'installer des .deb, voir les messages suivants]
mais son option -c permet de spécifier un fichier de configuration arbitraire pouvant contenir des commandes qui seront exécutées en root, donc il faut faire en sorte qu'apt-get ne puisse pas être exécuté via sudo avec cette option (via un script wrapper par exemple).
Dernière modification par raleur (29-10-2022 20:03:50)
Il vaut mieux montrer que raconter.
Hors ligne
du coup, je ne vois pas l'intérêt de brider sudo sauf pour les enfant de 5ans.
Sauf si tes partitions sont chiffrées, avec un accès physique à ta machine, avoir un accès root demande 2 minute environ. Ce n'est pas un secret. Et ça marche pour windows aussi.
Dernière modification par otyugh (29-10-2022 18:15:32)
Hors ligne
du coup, je ne vois pas l'intérêt de brider sudo sauf pour les enfant de 5ans.
Sauf si tes partitions sont chiffrées, avec un accès physique à ta machine, avoir un accès root demande 2 minute environ. Ce n'est pas un secret. Et ça marche pour windows aussi.
Je n'ai pas compris.
Je sais que si les partitions ne sont pas chiffrées, ça demande effectivement 2 minutes pour prendre root (testé).
Par-contre, si c'est chiffré et qu'il y ait sudo activé pour un user, avec ou sans liste blanche, selon ce que j'ai compris de raleur, ça craint aussi.
Il faut donc passer par un bridage spécifique. wrapper script
Mais du coup, je vais dire un truc idiot. Comment installer un paquet sans être root et sans mettre sudo sur le plan théorique ? ou alors je pose la question à l'envers comme d'habitude.
Hors ligne
sans mettre sudo sur le plan théorique
Pardon ?
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par totoZero7 (30-10-2022 12:53:20)
Hors ligne
Je n'ai pas compris.
Moi non plus, c'est quoi l'objectif T_T
Dernière modification par otyugh (29-10-2022 18:58:42)
Hors ligne
Hors ligne