Sudo et la sécurité?

h4l · Le 24/01/2009, à 17:48

pourquoi elle se loguerait en root? j'ai jamais eu le cas sur une 20aine de pote...

Rubyman · Le 26/01/2009, à 20:35

Pour installer un logiciel, il faut bien se logguer en root, non? Etant donné qu'elle compte volontairement installer un logicil, il est logique qu'elle se loggue en root... Enfin, personnellement, je trouve qu'on fait vraiment beaucoup de bruit autour de ce problème. A partir du moment où quelqu'un est assez stupide pour télécharger un exécutable sur un site douteux, l'autoriser à s'exécuter puis le lancer(quoique ce serait plus un obstacle, il pourrait se dire que le fichier "ne marche pas"), il l'est assez pour exécuter un installateur *.deb et rentrer son mot de passe quand demandé, rassuré par l'interface habituelle de gksudo (ou, dans le cas d'autres distribs, pour se logguer en root et l'installer). L'utilisateur sait que pour installer quelquechose, il faut utiliser son mot de passe/se logguer en root. A partir du moment où il décide d'installer une cochonnerie, il le fera, qu'elle aie besoin d'un mot de passe ou non.

h4l · Le 26/01/2009, à 20:43

attendez... qu'est-ce que vous appelez se logguer en root?

est-ce que si je lance une commande avec sudo je me logue en root?

parce que pour moi se loguer en root c'etait a la connexion... kdm/gdm root + mdp...

l'utilisation de mes amis en root se résume a synaptic...

®om · Le 26/01/2009, à 20:45

Rubyman a écrit :

A partir du moment où quelqu'un est assez stupide pour télécharger un exécutable sur un site douteux, l'autoriser à s'exécuter puis le lancer.

Ça c'était pour le ProofOfConcept. En réalité, ce pourrait être beaucoup plus subtil, une faille dans un logiciel quelconque permettant l'exécution de code arbitraire sans que l'utilisateur ne s'en rende compte (jusque là c'est normal), le problème avec sudo c'est que ce code pourrait attendre que l'utilisateur "élève" ses droits pour exécuter ce qu'il veut en root.

philarmonie · Le 26/01/2009, à 20:50

il reste la possibilité d'un binaire caché dans un jpeg: tu crois ouvrir une image (reçu par mail ou autre) et au final tu lances un programme
et encore je suis sur que les script malveillants ont bien d'autres cordes à leurs arcs pour s'exécuter à l'insu de l'utilisateur, sans qu'il est à télécharger lui même un programme, le rendre exécutable puis l'exécuter.

ce qui me dérange quand même avec ce soucis, c'est que parmi tous les précautions mises en place par les systèmes de type unix pour protéger un système il y en a un qui est fondamental: c'est la séparation des droit root et des droits utilisateurs; et cette faille fait tomber cette barrière, facilitant ainsi la possibilité d'obtenir un shell root sur une machine.
sans faire trop de bruit autour, ça reste à mes yeux une faille assez grave.

®om · Le 26/01/2009, à 20:54

Ça donne quoi le rapport de bug (privé) sur launchpad?

philarmonie · Le 26/01/2009, à 21:01

h4l a écrit :

attendez... qu'est-ce que vous appelez se logguer en root?

faire un 'su root + mdp'

h4l a écrit :

est-ce que si je lance une commande avec sudo je me logue en root?

non là tu lances un processus dont le propriétaire est root, c'est comme si t'avais fait

su root
ma_commande

Dradge · Le 27/01/2009, à 10:57

Bonjour,
Je crois que le fonctionnement de gksudo est ainsi pour les applications qui ont un menu déverrouiller. En fait ca lance tout bêtement un gksudo en processus fils et de par le fonctionnement évoqué ci-dessus, le processus père est débloqué pour 15 minutes. Pour résoudre ce problème, il faut revoir cette fonctionnalité gksudo et donner les droits de sudo au processus père et non à toutes les applications graphiques.

Bonne journée

valAa · Le 27/01/2009, à 11:02

Je dis peut-être des bêtises, mais il me semble que le nouveau bouton "déverrouiller" utilise justement PolicyKit au lieu de gksudo, ce qui permet de gérer beaucoup plus finement l'élévation de droits et serait plus sécurisé.
Dixit Fedora où PolicyKit est implémenté depuis quelques temps déjà.

Mais je n'en sais pas plus (et ne suis même pas sur de ce que j'avance).

Dradge · Le 27/01/2009, à 11:09

En effet Ubuntu utilise Policykit depuis la 8.04 (et fedora depuis la 8). En gros, la réponse à cette faille va être : les developpeurs de softs doivent utiliser policykit et non gksudo... Enfin je suppose.

alexduf · Le 27/01/2009, à 11:16

Je suis le sujet depuis un moment, c'est bien intéressant tout ça.
Le problème c'est que le gksudo est quand même bien ancré dans les habitudes. Il va falloir communiquer là-dessus non ?

Enfin l'idéal serait d'avoir une réponse "officielle" de la part d'un expert ubuntu via la déclaration du bug sur le LP.

NonConnecté · Le 27/01/2009, à 11:32

philarmonie a écrit :

h4l a écrit :
attendez... qu'est-ce que vous appelez se logguer en root?
faire un 'su root + mdp'
h4l a écrit :
est-ce que si je lance une commande avec sudo je me logue en root?
non là tu lances un processus dont le propriétaire est root, c'est comme si t'avais fait
su root
ma_commande

il me semble que sudo se rapproche plutôt de :

su - -c "<commande>"

le - est très important car c'est lui qui permet de charger l'environnement "root".

roynux · Le 27/01/2009, à 14:04

valAa a écrit :

Je dis peut-être des bêtises, mais il me semble que le nouveau bouton "déverrouiller" utilise justement PolicyKit au lieu de gksudo, ce qui permet de gérer beaucoup plus finement l'élévation de droits et serait plus sécurisé.
Dixit Fedora où PolicyKit est implémenté depuis quelques temps déjà.
Mais je n'en sais pas plus (et ne suis même pas sur de ce que j'avance).

http://hal.freedesktop.org/docs/PolicyKit/

Voici ma traduction de la partie rationale de cette page :
https://wiki.ubuntu.com/DesktopTeam/Spe … ntegration

Rationale
Applications which use gksu today (such as gnome-system-tools or mounting an internal hard disk) currently run with root privileges. PolicyKit allows these to run as normal user with just getting a particular bit of extra privileges, so they can be controlled better, and in a more flexible way.

Logique
Les applications qui utilisent gksu actuellement (telles que gnome-system-tools ou monter un disque dur interne) le font avec les privilèges root. PolicyKit permet à ces application d'être éxécutées tel qu'un utilisateur normal en lui attributant quelques petits privilèges supplémentaires, afin d'être mieux controlés et d'une manière plus souple.

lawl · Le 27/01/2009, à 18:48

En gros, la réponse à cette faille va être : les developpeurs de softs doivent utiliser policykit et non gksudo... Enfin je suppose.

Ou bien qu'il n'y a pas de faille....

alexduf · Le 28/01/2009, à 09:21

Le policy kit peut-il réellement être utilisé partout ?

Parce que je suis allé lire un peu la doc concernant celui-ci, et (arrêtez moi si je me trompe) on donne les droits au goute-à-goute.

J'ai besoin de faire un mount, hop, je demande les droits, j'ai besoin de faire une écriture sur un fichier protégé, hop je demande les droits.

Ce qui me fait peur, c'est l'installation d'un paquet debian. (là encore arrêtez moi si je me trompe) Un paquet debian pouvant contenir un script d'install contenant à peu près n'importe quelle commande ayant besoin d'être lancée avec les droits d'admin, l'installeur de paquet peut-il utiliser le policy kit sans en faire une usine à gaz ?

AlexandreP · Le 29/01/2009, à 05:24

Si je ne m'abuse, le gestionnaire de paquets PackageKit utilise PolicyKit pour l'installation de paquets. PackageKit est disponible pour Ubuntu (dans la section universe), je l'avais essayé vite fait. Bah, ça fonctionne, les paquets s'installent bien.

Dernière modification par AlexandreP (Le 29/01/2009, à 05:25)

alexduf · Le 29/01/2009, à 13:09

Ok, comme ça ça répond à toutes mes interrogations

philarmonie · Le 29/01/2009, à 15:30

que le gestionnaire de paquets utilise Policykit ou gksudo, kdesudo ça ne change pas grand chose.
si ton paquet contient un script d'install malveillant il s'exécutera quand même: pour qu'un paquet puisses s'installer convenablement il faut donner les droits root à son script d'install.

Bilan: Installer des paquets provenant uniquement des sources de confiance!! C'est un principe de base d'un bon comportement utilisateur. Ne pas respecter ce principe revient à utiliser la plus grosse faille de l'informatique quelque soit le système utilisé: cette fameuse faille qui se situe entre le clavier et la chaise.

Dernière modification par philarmonie (Le 29/01/2009, à 15:30)

Link31 · Le 29/01/2009, à 17:23

philarmonie a écrit :

Bilan: Installer des paquets provenant uniquement des sources de confiance!!

Ce n'est pas un "bilan". La faille de (gk)sudo est potentiellement exploitable à distance, sans aucune intervention de l'utilisateur.

philarmonie · Le 29/01/2009, à 17:39

Link31 a écrit :

philarmonie a écrit :
Bilan: Installer des paquets provenant uniquement des sources de confiance!!
Ce n'est pas un "bilan". La faille de (gk)sudo est potentiellement exploitable à distance, sans aucune intervention de l'utilisateur.

ce bilan c'était pour répondre à la question de alexduf sur l'installation manuelle de paquet debian:

alexduf a écrit :

Ce qui me fait peur, c'est l'installation d'un paquet debian. (là encore arrêtez moi si je me trompe) Un paquet debian pouvant contenir un script d'install contenant à peu près n'importe quelle commande ayant besoin d'être lancée avec les droits d'admin, l'installeur de paquet peut-il utiliser le policy kit sans en faire une usine à gaz ?

pour la faille, je sais bien qu'elle est exploitable sans intervention de l'utilisateur d'où le gros problème. Enfin ça fait plus d'une semaine que la faille est signalée, et on n'a toujours pas eu de retour sur sa prise en charge.

Dernière modification par philarmonie (Le 29/01/2009, à 17:40)

alexduf · Le 29/01/2009, à 19:43

philarmonie a écrit :

ce bilan c'était pour répondre à la question de alexduf sur l'installation manuelle de paquet debian

oui oui je sais bien qu'il faut pas installer n'importe quoi (même si entre nous les paquets vérolés ne doivent pas courir les rues)
Ma question concernait seulement la faisabilité technique d'un installeur de paquet via le policykit. Ce qui visiblement, policykit ou pas permet effectivement de lancer un script malveillant a, mais là n'est pas le débat, on s'égare.

lawl · Le 29/01/2009, à 23:11

Enfin ça fait plus d'une semaine que la faille est signalée, et on n'a toujours pas eu de retour sur sa prise en charge

Parce que ce n'est tout simplement pas une faille...

philarmonie · Le 29/01/2009, à 23:24

lawl a écrit :

Enfin ça fait plus d'une semaine que la faille est signalée, et on n'a toujours pas eu de retour sur sa prise en charge
Parce que ce n'est tout simplement pas une faille...

La configuration par défaut d'Ubuntu facilite l'obtention d'un shell root sur une machine à l'insu de l'utilisateur et tu n'appelles pas ça une faille???
Ce n'est pas une faille de sudo, gksudo... mais de l'utilisation qui en ai faite par défaut sur Ubuntu.

Si tu considères que ce n'est pas une faille, j'aimerai bien que tu m'expliques pourquoi?

lawl · Le 30/01/2009, à 09:27

Ce n'est pas une faille car pour avoir accès au mot de passe via sudo il faut déjà que quelques chose soit installé sur la machine.
Dans ce cas le home utilisateur est une faille car si un programme peut s'installer à l'insu de l'utilisateur il peut lui piquer sont mot de passe mais aussi lui effacer tous ses docuements.
L'accès physique est aussi une faille car on peut réinitialiser le mot de passe root
Etc..

Ici il s'agit plus d'un choix de règle de sécurité.

Bigcake · Le 30/01/2009, à 09:43

Choisir de laisser une porte ouverte, pendant 15 minutes, à n'importe quelle processus les droits root, me paraît être une faille de sécurité non pas dans le code, ce n'est pas un 'bug' mais une faille dans la politique de sécurité choisi, qui, je trouve, ne correspond au reste de l'OS.

j'ai envie de dire qu'il s'agit d'une faille dans le choix des règles de sécurité

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#76 Le 24/01/2009, à 17:48

Re : Sudo et la sécurité?

#77 Le 26/01/2009, à 20:35

Re : Sudo et la sécurité?

#78 Le 26/01/2009, à 20:43

Re : Sudo et la sécurité?

#79 Le 26/01/2009, à 20:45

Re : Sudo et la sécurité?

#80 Le 26/01/2009, à 20:50

Re : Sudo et la sécurité?

#81 Le 26/01/2009, à 20:54

Re : Sudo et la sécurité?

#82 Le 26/01/2009, à 21:01

Re : Sudo et la sécurité?

#83 Le 27/01/2009, à 10:57

Re : Sudo et la sécurité?

#84 Le 27/01/2009, à 11:02

Re : Sudo et la sécurité?

#85 Le 27/01/2009, à 11:09

Re : Sudo et la sécurité?

#86 Le 27/01/2009, à 11:16

Re : Sudo et la sécurité?

#87 Le 27/01/2009, à 11:32

Re : Sudo et la sécurité?

#88 Le 27/01/2009, à 14:04

Re : Sudo et la sécurité?

#89 Le 27/01/2009, à 18:48

Re : Sudo et la sécurité?

#90 Le 28/01/2009, à 09:21

Re : Sudo et la sécurité?

#91 Le 29/01/2009, à 05:24

Re : Sudo et la sécurité?

#92 Le 29/01/2009, à 13:09

Re : Sudo et la sécurité?

#93 Le 29/01/2009, à 15:30

Re : Sudo et la sécurité?

#94 Le 29/01/2009, à 17:23

Re : Sudo et la sécurité?

#95 Le 29/01/2009, à 17:39

Re : Sudo et la sécurité?

#96 Le 29/01/2009, à 19:43

Re : Sudo et la sécurité?

#97 Le 29/01/2009, à 23:11

Re : Sudo et la sécurité?

#98 Le 29/01/2009, à 23:24

Re : Sudo et la sécurité?

#99 Le 30/01/2009, à 09:27

Re : Sudo et la sécurité?

#100 Le 30/01/2009, à 09:43

Re : Sudo et la sécurité?

Pied de page des forums