Sudo et la sécurité?

philarmonie · Le 26/02/2009, à 17:14

dimi84 a écrit :

Je connais quelqu'un qui a un Eeepc avec xandros et il ne demande jamais de mot de passe.
Il n'est pas le seul :
http://forum.ubuntu-fr.org/viewtopic.php?id=197591
http://www.linuxpourlesnuls.org/docuwik … er_xandros

et bah voilà une distribution que je n'utiliserai jamais.
à mon avis ils ont fait ce choix car elle s'est retrouvé liée à la vente avec des pc pour le grand public qui, étant habitué via windows à ne pas distinguer le compte administrateur d'un compte utilisateur, aurait sans doute été perturbé par cette demande de mot de passe à chaque action effectuée en tant que root.
bien que je peux comprendre ce qui a pu les pousser à faire ce choix, je ne le partage pas.

Dernière modification par philarmonie (Le 26/02/2009, à 17:15)

Le Farfadet Spatial · Le 26/02/2009, à 17:30

Salut à tous !

philarmonie a écrit :

Je pense que Jofab faisait ici référence au choix de la politique de Xandros qui est de pouvoir utiliser sudo sans mot de passe, et là effectivement la barrière utilisateur-administrateur tombe d'elle même.

Si c'est bien de Xandros dont il est question, là, oui, je pense que le choix de sécurité n'est pas pertinent et, en effet, on perd la distinction entre utilisateur normal et administrateur.

À bientôt.

Le Farfadet Spatial

loubrix · Le 26/02/2009, à 17:56

ce qu'il faut, c'est opter pour une politique de sécurité cohérente et en accord avec le degré de sensibilité du système.

il est évident qu'on ne réclame pas le même niveau de sécurité sur un PC de bureau que sur un serveur; déjà sur un serveur, on peut commencer par se passer de tout ce qui est graphique, ce qui réduit considérablement le risque de faille...
concernant sudo, je me demande si les admins qui utilisent Ubuntu sur leurs machines le gardent ou remettent un mot de passe root (perso pour un serveur je préfère Debian, plus stable et plus léger en RAM).

Quand j'ai installé ubuntu chez un ami la première chose qu'on m'a dit c'est comment enlevé le mot de passe

tous les gens à qui j'ai fait passer le cap (et il commence à y en avoir un paquet), en avait marre de Windows (pour les raisons qu'on connait tous); je n'ai donc pas eu grand mal à les convaincre qu'un mot de passe, c'est le début de la sécurité, même si ça ne suffit pas...

Je connais quelqu'un qui a un Eeepc avec xandros et il ne demande jamais de mot de passe.
Il n'est pas le seul :

je suppose qu'enlever l'option "NOPASSWD" dans /etc/sudoers résoudrait ce défaut

je me demandais si ce serait pas une bonne idée qu'on cherche des solutions pour améliorer ce qui peut l'être, comme ces fameux fichiers desktop: il y a certainement des moyens d'empêcher leur falsification:
-un démon qui surveille les modifs de ces fichiers
-une clé dans chaque fichier, générée et reconnue par le système
-des restrictions sur ce qu'on peut mettre dedans: pas plus d'une commande, interdiction des ";" "|" "&", et tout ce qui pourrait permettre de lancer plusieurs commandes
-obligation pour ces fichiers de lancer uniquement des applications de répertoires bien précis (/usr/bin, /usr/local/bin, /usr/games,...etc)

Le Farfadet Spatial · Le 26/02/2009, à 18:31

Salut à tous !

loubrix a écrit :

concernant sudo, je me demande si les admins qui utilisent Ubuntu sur leurs machines le gardent ou remettent un mot de passe root (perso pour un serveur je préfère Debian, plus stable et plus léger en RAM).

Là encore, il est question de choix pertinent : pour un petit réseau domestique, Ubuntu est un bon choix et je ne vois pas pourquoi en changer le modèle. Par contre, dès qu'on monte en catégorie, par exemple le réseau d'une association ou d'une PME, je pense qu'Ubuntu n'est pas approprié. Debian devient alors un choix à mon sens plus approprié.

En tout cas, de mon côté, je n'ai pas connaissance d'un administrateur pour un réseau de taille moyenne ou plus qui utiliserait Ubuntu. Il faudrait demander à Canonical.

je me demandais si ce serait pas une bonne idée qu'on cherche des solutions pour améliorer ce qui peut l'être, comme ces fameux fichiers desktop: il y a certainement des moyens d'empêcher leur falsification:
-un démon qui surveille les modifs de ces fichiers

Ça va prendre des ressources à la machine. Les démons, c'est bien, en abuser ça craint.

-une clé dans chaque fichier, générée et reconnue par le système

Pas mal. Cela dit, comment faire alors lorsque l'on a besoin de modifier les fichiers à la main ? C'est une chose qui arrive relativement souvent pour les développeurs KDE ou les administrateurs systèmes qui doivent réparer les erreurs qu'ont faites les utilisateurs (problème beaucoup plus courant que le risque d'exploitation de cette faiblesse).

-des restrictions sur ce qu'on peut mettre dedans: pas plus d'une commande, interdiction des ";" "|" "&", et tout ce qui pourrait permettre de lancer plusieurs commandes

Cela limiterait la souplesse du système.

-obligation pour ces fichiers de lancer uniquement des applications de répertoires bien précis (/usr/bin, /usr/local/bin, /usr/games,...etc)

Cela réduirait la souplesse et la portabilité du système.

De toute façon, cette discussion est toute théorique, puisque les développeurs ont déclaré qu'ils n'étaient pas intéressés pour réduire cette faiblesse. Quelque part, on peu les comprendre, vu que cela nécessiterait beaucoup de ressources humaines et temps pour une faiblesse qui reste somme toute mineur : elle n'a toujours pas été exploitée, en 13 années d'existence... Après coup, je me dis que ma remarque sur le fait qu'elle serait probablement corrigée était bien bien naïve, vu que c'est du même acabit que la faiblesse de Sudo.

À bientôt.

Le Farfadet Spatial

loubrix · Le 26/02/2009, à 20:11

-une clé dans chaque fichier, générée et reconnue par le système
Pas mal. Cela dit, comment faire alors lorsque l'on a besoin de modifier les fichiers à la main ? C'est une chose qui arrive relativement souvent pour les développeurs KDE ou les administrateurs systèmes qui doivent réparer les erreurs qu'ont faites les utilisateurs (problème beaucoup plus courant que le risque d'exploitation de cette faiblesse).

il suffit d'un utilitaire capable de générer une clé valide, que l'on peut ensuite copier-coller dans le fichier (utilitaire sécurisé par un droit d'éxécution accordé seulement à l'utilisateur propriétaire du fichier desktop). ça doit pouvoir être géré par le fameux policy-kit dont on a parlé plus haut...

Le Farfadet Spatial · Le 26/02/2009, à 20:59

Salut à tous !

loubrix a écrit :

il suffit d'un utilitaire capable de générer une clé valide, que l'on peut ensuite copier-coller dans le fichier (utilitaire sécurisé par un droit d'éxécution accordé seulement à l'utilisateur propriétaire du fichier desktop). ça doit pouvoir être géré par le fameux policy-kit dont on a parlé plus haut...

Décidément pas mal, mais pas une clef collée dans le fichier, plutôt un système de validation indépendant : on modifie d'abord le fichier, puis on le fait valider par l'utilitaire, qui maintient une base cryptée des fichiers validés.

Cela dit, encore une fois : il semble bien que les développeurs ne soient pas intéressés... Cela dit, il est possible de faire un petit utilitaire de ce genre. Si j'ai cinq minutes, j'essayerais de faire ça la semaine prochaine : une proposition avec du code prêt à l'emploi est toujours plus facilement acceptée.

À bientôt.

Le Farfadet Spatial

kuri · Le 26/02/2009, à 22:02

philarmonie a écrit :

Bon bah j'abandonne, j'espère juste que vous bossez pas pour des boîtes faisant des audits de sécurité.

yeah!
je bosse pour une boite qui vend des solutions de sauvegardes (sous forme d abonnement), avec plus d un millier de serveurs deployes
je m occupe d un peu tout ce qui concerne les dit serveurs (de l admin sys/net au developpement de logiciels).
tu as peur ? moi pas.

ps : ce n est pas une faille il n y a pas de faille quand le choix est fait deliberement. si un mec laisse un ftp avec acces anonyme et droits d ecriture, si il se fait tout supprimer il dit qu il s est fait hacker ? qu un mec a exploite une faille ? si c est le cas, c est un menteur, car il a juste ete incroyablement negligeant. ce probleme de securite que represente sudo est du meme type : c est un rabaissement du niveau de securite du systeme, pour des question de commoditees. c est pas une faille. (le premier qui me sort le proces de zataz comme exemple pour me contredire, je le castre )

Dernière modification par kuri (Le 26/02/2009, à 22:11)

philarmonie · Le 26/02/2009, à 23:13

kuri a écrit :

ps : ce n est pas une faille il n y a pas de faille quand le choix est fait deliberement

Dans ce cas effectivement, le problème traité ici n'est pas une faille de sécurité.
Mais je dois avouer que j'ai du mal à ne pas appeler une faille ce qui est un choix délibéré dans l'affaiblissement de la politique de sécurité.
Ça me rappelle un problème relever dans le fonctionnement de l'UAC de windows seven. Pour Microsoft ce n'est pas une faille mais un comportement voulu et qu'il faut déjà qu'un script malveillant soit présent sur le système pour être exploitée (cette situation me semble bien familière ) . Ce à quoi l'expert rétorque

Long Zheng a écrit :

Comment une application avec des privilèges faibles pourrait-elle désactiver la totalité de la couche de sécurité s’il ne s’agit pas d’une faille de sécurité ?

Je n'étais pas au courant pour l'affaire zataz, je viens de lire ça, c'est une honte qu'ils aient été condamnés! tu rends service et en plus on te le fait payer, il y en a qui n'ont vraiment aucune gêne.

Dernière modification par philarmonie (Le 26/02/2009, à 23:15)

loubrix · Le 27/02/2009, à 11:05

Cela dit, encore une fois : il semble bien que les développeurs ne soient pas intéressés... Cela dit, il est possible de faire un petit utilitaire de ce genre. Si j'ai cinq minutes, j'essayerais de faire ça la semaine prochaine : une proposition avec du code prêt à l'emploi est toujours plus facilement acceptée.

ben on avance; si tu as besoin d'aide pour tester...
et puis on est pas obligé de l'incorporer au système, on peut simplement le proposer à ceux qui veulent améliorer leur sécurité...

pour revenir à Sudo, je me suis aperçu que Gdebi redemande le mot de passe à chaque fois, même à quelques secondes d'intervalle entre l'installation de 2 paquets, contrairement aux autres application qui font appel à Sudo...

kuri · Le 27/02/2009, à 13:23

philarmonie a écrit :

Je n'étais pas au courant pour l'affaire zataz, je viens de lire ça, c'est une honte qu'ils aient été condamnés! tu rends service et en plus on te le fait payer, il y en a qui n'ont vraiment aucune gêne.

ce qui me choque c est pas juste qu on les accuse de piratage, c est le ridicule de la chose : en disant qu ils ont etes reperes sur un certain login "anonymous" et que toutes les actions de suppression ont etees faites sur ce compte, c est donc que c est zataz qui l a fait!

bref, le compte anonymous etant ce qu il est, si en plus y a les droits +w dessus ... c est bien la personne qui a cree ce ftp, la personne qui a porte plainte (meme personne ?), et le juge qui devraient etre condamnes pour exces de connerie.

car il n y a pas eu piratage, ni exploitation de faille de securite. un acces publique a ete utiliser pour copier/supprimer des donnees ont ne peut plus publiques.

concernant cette faille de l UAC, je n en sait pas assez pour me declarer dessus. ca ne m interesse pas trop d ailleurs leurs problemes, ni meme leurs avancees, donc je ne vais pas commenter

Dernière modification par kuri (Le 27/02/2009, à 13:24)

Le Farfadet Spatial · Le 27/02/2009, à 14:26

Salut à tous !

loubrix a écrit :

ben on avance; si tu as besoin d'aide pour tester...
et puis on est pas obligé de l'incorporer au système, on peut simplement le proposer à ceux qui veulent améliorer leur sécurité...

J'y ai un peu réfléchit, je pense m'orienter vers un Linux Security Module : c'est ce qu'il y a de plus souple, en plus on peu coupler plusieurs modules, donc on peut se contenter d'un élément au domaine d'application très modeste, à l'utilisateur de coupler différents modules en fonction de ses besoins. De plus, c'est indépendant du système de fenêtrage utilisé.

L'idée n'est pas de faire un module qui garantit d'une intrusion, il y a déjà des projets pour ça, avec des gens plus compétent que moi sur ce sujet. L'idée, c'est d'éviter les modifications involontaires de fichiers, typiquement des fichiers de configurations (mais pourquoi pas d'autres), soit à cause d'une erreur de manipulation, soit à cause d'une infection de type virale. Il faut qu'il ne grève pas (enfin pas de manière trop sensible) les performances. Par contre, comme l'objectif n'est pas de verrouiller un accès, point n'est besoin d'utiliser un système de cryptage très avancé (particulièrement gourmand en temps de calcul). Si le chiffrement tient une demi-heure, c'est déjà très suffisant pour se garantir d'une erreur de manipulation et rendre la tâche de création d'un virus beaucoup plus délicate.

Du coup, je vais essayer de mettre en place une première ébauche, basée sur DES et MD5 et je le mettrais à disposition. J'essayerais de soumettre tout ça sur la liste du noyau Linux. Le langage sera donc C. On verra ce que ça donne.

À bientôt.

Le Farfadet Spatial

Link31 · Le 27/02/2009, à 18:36

Le Farfadet Spatial a écrit :

L'idée, c'est d'éviter les modifications involontaires de fichiers, typiquement des fichiers de configurations (mais pourquoi pas d'autres), soit à cause d'une erreur de manipulation, soit à cause d'une infection de type virale.

Pour ça, il existe déjà... les droits UNIX

Si les développeurs d'Ubuntu font n'importe quoi avec la configuration de sudo, et affaiblissent la séparation des droits, c'est leur problème. Mais n'espère pas pouvoir convaincre les développeurs du noyau. Désolé.

loubrix · Le 27/02/2009, à 19:29

Pour ça, il existe déjà... les droits UNIX

oui, mais ces droits ne servent à rien si c'est l'utilisateur qui lance un script destiné à corrompre un fichier desktop lui appartenant (simplement parce qu'il ne savait pas que c'etait néfaste).
ici, on voudrait empêcher la modification d'un fichier desktop, vu que leur faille est de n'avoir pas besoin des droits d'éxécution pour lancer des applis...

Link31 · Le 27/02/2009, à 19:38

loubrix a écrit :

Pour ça, il existe déjà... les droits UNIX
oui, mais ces droits ne servent à rien si c'est l'utilisateur qui lance un script destiné à corrompre un fichier desktop lui appartenant (simplement parce qu'il ne savait pas que c'etait néfaste).
ici, on voudrait empêcher la modification d'un fichier desktop, vu que leur faille est de n'avoir pas besoin des droits d'éxécution pour lancer des applis...

Alors il suffit d'exiger qu'ils aient les droits d'exécution. Les droits UNIX d'exécution

Et pour empêcher la modification accidentelle d'un fichier, il suffit de lui enlever le droit d'écriture. Ou, si on veut une protection bien plus solide, valable aussi contre les malwares les plus perfectionnés : ne pas être connecté sous la même identité que l'utilisateur propriétaire de ces fichiers, voire les passer en immutable.

philarmonie · Le 27/02/2009, à 19:58

Link31 a écrit :

Alors il suffit d'exiger qu'ils aient les droits d'exécution. Les droits UNIX d'exécution

Comme ce sont des fichiers ouverts par une autre application, ça parait étrange de leur demander d'avoir des droits d'exécutions (on ne demande pas à un .png d'avoir de tel droit). Mais effectivement comme c'est fichiers ont pour finalité de créer des lanceurs, et donc de faire exécuter du code, ça se comprend parfaitement et ça règle la faille.
Faudrait juste soumettre l'idée aux développeurs KDE et Gnome. C'est pas bien compliqué de checker si le fichier .desktop a les droits d'exécutions avant d'exécuter les commandes qu'il contient.

Link31 a écrit :

Et pour empêcher la modification accidentelle d'un fichier, il suffit de lui enlever le droit d'écriture.

oui mais si le but est de se protéger d'un malware, il lui suffit de redonner les droits d'écritures sauf si

Link31 a écrit :

Ou, si on veut une protection bien plus solide, valable aussi contre les malwares les plus perfectionnés : ne pas être connecté sous la même identité que l'utilisateur propriétaire de ces fichiers, voire les passer en immutable.

Dernière modification par philarmonie (Le 27/02/2009, à 19:58)

Link31 · Le 27/02/2009, à 20:39

philarmonie a écrit :

Faudrait juste soumettre l'idée aux développeurs KDE et Gnome. C'est pas bien compliqué de checker si le fichier .desktop a les droits d'exécutions avant d'exécuter les commandes qu'il contient.

Le mieux serait de passer les fichiers .desktop en binfmt_misc, ce qui requiert donc les droits d'exécution et a l'avantage de ne pas dépendre de la façon dont ils sont implémentés dans chaque environnement de bureau.

L'ennui (je viens d'y penser), c'est que les .desktop semblent être parfois utilisés pour autre chose que des lanceurs, par exemple les locales sous KDE, ce qui complique un peu la façon dont on doit les gérer globalement.

Dernière modification par Link31 (Le 27/02/2009, à 20:40)

philarmonie · Le 27/02/2009, à 21:10

Link31 a écrit :

Le mieux serait de passer les fichiers .desktop en binfmt_misc

c'est quoi?

Link31 a écrit :

L'ennui (je viens d'y penser), c'est que les .desktop semblent être parfois utilisés pour autre chose que des lanceurs, par exemple les locales sous KDE, ce qui complique un peu la façon dont on doit les gérer globalement.

[troll_on]quand je dis que KDE saylemal[troll_off]

Link31 · Le 27/02/2009, à 23:00

philarmonie a écrit :

Link31 a écrit :
Le mieux serait de passer les fichiers .desktop en binfmt_misc
c'est quoi?

C'est un moyen d'ajouter facilement de nouveaux formats d'exécutables au noyau.

De base, sous la plupart des distributions, il y a le format ELF (binfmt_elf), le format script (binfmt_script, dont l'interpréteur est indiqué par le #!), et le binfmt_misc qui n'est généralement pas configuré. Avec le binfmt_misc, on peut par exemple ajouter le format PE (les .exe), qui pourra être géré par wine ou mono mais qui apparaîtra pour tout le système comme un exécutable normal (chmod +x test.exe && ./test.exe). On peut aussi ajouter le format .jar, pour lancer des programmes Java comme n'importe quels autres exécutables, à condition d'avoir une VM Java installée.

Et on pourrait même ajouter le format .desktop, et le considérer comme un programme exécutable.

Dernière modification par Link31 (Le 27/02/2009, à 23:01)

philarmonie · Le 28/02/2009, à 16:32

@Link31: ok, merci du renseignement. Ça pourrait être une bon idée mais effectivement ça risque de poser problèmes pour la gestion des .desktop qui ne sont pas utilisés comme lanceurs.

@Le Farfadet Spacial: en me promenant sur le forum, je suis tombé sur un sujet parlant du logiciel AIDE (Advanced Intrusion Detection Environnement), c'est ce type de logiciel que tu as en tête?

Dernière modification par philarmonie (Le 28/02/2009, à 16:33)

Le Farfadet Spatial · Le 02/03/2009, à 12:29

Salut à tous !

philarmonie a écrit :

@Le Farfadet Spacial: en me promenant sur le forum, je suis tombé sur un sujet parlant du logiciel AIDE (Advanced Intrusion Detection Environnement), c'est ce type de logiciel que tu as en tête?

Pile-poil et, à première vue, ça à l'air très bien fait. Donc, je ne vais pas lancer un projet débile à côté. Mieux vaut voir ce que cela donne en profondeur.

Link31 a écrit :

Et pour empêcher la modification accidentelle d'un fichier, il suffit de lui enlever le droit d'écriture. Ou, si on veut une protection bien plus solide, valable aussi contre les malwares les plus perfectionnés : ne pas être connecté sous la même identité que l'utilisateur propriétaire de ces fichiers, voire les passer en immutable.

Il y a un petit pépin, tout de même : l'utilisateur a besoin d'avoir des fichiers de configurations sur lesquels il doit avoir les droits d'écriture (l'exemple typique est le fichier .bashrc). Même si l'utilisateur peu n'y mettre les droits d'écriture que lorsqu'il décide de modifier le fichier, il en reste le propriétaire donc un script malveillant pourrait prendre le droit d'écriture. Cela dit, AIDE a l'air de proposer un moyen efficace de limiter ce risque.

À bientôt.

Le Farfadet Spatial

philarmonie · Le 02/03/2009, à 13:12

Le Farfadet Spatial a écrit :

Il y a un petit pépin, tout de même : l'utilisateur a besoin d'avoir des fichiers de configurations sur lesquels il doit avoir les droits d'écriture (l'exemple typique est le fichier .bashrc). Même si l'utilisateur peu n'y mettre les droits d'écriture que lorsqu'il décide de modifier le fichier, il en reste le propriétaire donc un script malveillant pourrait prendre le droit d'écriture. Cela dit, AIDE a l'air de proposer un moyen efficace de limiter ce risque.

Je crois que l'idée de Link31 est de créé un utilisateur qui est propriétaire des fichiers de configurations, quand on veut les modifier on se connecte sous se compte qui possède les droits d'écriture dessus, mais pas contre notre compte courant n'a que les droits de lecture. Comme ça les logiciels qui ont besoin de ses fichiers peuvent s'en servir (on a les droits de lecture) mais un script malveillant ne peut les modifier (il n'a pas les droits d'écriture et comme on n'est pas propriétaire des fichiers le script ne peut se donner ce droit dessus).

Le Farfadet Spatial · Le 02/03/2009, à 15:24

Salut à tous !

philarmonie a écrit :

Je crois que l'idée de Link31 est de créé un utilisateur qui est propriétaire des fichiers de configurations, quand on veut les modifier on se connecte sous se compte qui possède les droits d'écriture dessus, mais pas contre notre compte courant n'a que les droits de lecture.

Oui, c'est moi qui me suis mal exprimé, toutes mes excuses.

Je voulais juste dire que si on a opté pour que chaque utilisateur possède des fichiers de configurations le concernant c'est, je pense, pour la facilité et la souplesse que cela implique. Je crains que faire posséder les droits sur ces fichiers à un autre utilisateur implique plus de contrainte qu'un contrôle du type d'AIDES. Cela dit, il faut encore que je teste en profondeur AIDES pour le confirmer.

À bientôt.

Le Farfadet Spatial

philarmonie · Le 02/03/2009, à 15:45

Le Farfadet Spatial a écrit :

Je crains que faire posséder les droits sur ces fichiers à un autre utilisateur implique plus de contrainte qu'un contrôle du type d'AIDES.

oui sans aucun doute, ou au moins ça donne un accès plus « grand public ».
La technique de Link31 s'adresse plus à des utilisateurs avertis qui veulent augmenter la sécurité de leur système.
Mais au niveau des contraintes c'est pas énorme. On se crée un compte qui gère les fichiers d'options. On lui donne tous les fichiers de configuration sensibles. Ça prend juste un peu de temps pour mettre en place le système (et encore c'est pas bien long). Quand on installe un nouveau programme qui a des fichiers de configuration sensibles, on en change le propriétaire (ça prend deux secondes). Et pour ce qui est des contraintes d'édition franchement je les vois pas, suffit juste de les éditer en tant que compte d'options (y'a juste un petit su à rajouter dans la commande) au lieu de le faire avec le compte courant.

Dernière modification par philarmonie (Le 02/03/2009, à 15:47)

Le Farfadet Spatial · Le 03/03/2009, à 00:29

Salut à tous !

philarmonie a écrit :

Mais au niveau des contraintes c'est pas énorme. On se crée un compte qui gère les fichiers d'options. On lui donne tous les fichiers de configuration sensibles. Ça prend juste un peu de temps pour mettre en place le système (et encore c'est pas bien long). Quand on installe un nouveau programme qui a des fichiers de configuration sensibles, on en change le propriétaire (ça prend deux secondes). Et pour ce qui est des contraintes d'édition franchement je les vois pas, suffit juste de les éditer en tant que compte d'options (y'a juste un petit su à rajouter dans la commande) au lieu de le faire avec le compte courant.

Tout à fait d'accord (je ne sais pas ce que Link31 en pense). En fait, cela revient à créer un compte d'administration. En limitant les capacités d'administration de ce compte, ce qui n'est sans doute pas plus mal.

À bientôt.

Le Farfadet Spatial

Oni · Le 18/03/2009, à 02:44

philarmonie a écrit :

Bonjour à tous,
Le sujet n'est pas en lien direct avec la programmation mais je pense que les développeurs seront les mieux à même de répondre à ma question.
Je m'interrogeais sur une possible faille de sécurité qu'offre la commande sudo. Nous sommes tous contents que notre système favoris n'a pas (ou quasiment pas) de virus répertoriés, et ce qui est souvent argué à ce sujet est qu'un virus pouvant faire peu de dégâts sur le système, les créateurs de virus n'ont pas d'intérêt à en écrire. Là-dessus, j'aurai plutôt tendance à penser que c'est le faible nombre d'utilisateurs allié à la philosophie de l'OS qui nous protège de ce côté là.
Pour en revenir à mon interrogation au sujet de la faille de sécurité, j'en viens au fait.
Imaginons quand même qu'un pirate malveillant décide d'écrire un virus pour GNU/Linux. S'il s'y prend ainsi j'ai tendance à croire qu'il peut faire beaucoup de dégâts:
- il lance son virus en background
- pour s'installer proprement il a besoin des droits root
- il rentre alors dans une boucle en attendant que l'utilisateur face usage de 'sudo'
- une fois cet événement arrivé, il a 15 minutes pour profiter des privilèges root
- il s'installe où il veut
- crée un entrée dans '/etc/sudoers' pour pouvoir s'exécuter en root sans demande de mot de passe
- crée une entrée pour s'exécuter à chaque démarrage du système (en root et sans mot de passe)
- fait tout ce qu'il veut faire en tant que root et donc beaucoup de dégâts possibles.
Voilà, la parole est maintenant à vous. Ce scénario est-il possible?

Salut à tous.

Je n'ai pas le courage de lire toutes les pages.
Une personne qui a suivi l'avancée du topic pourrait-elle me dire qu'elle est, en définitive, la réponse à la question initiale ?

Merci d'avance.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#226 Le 26/02/2009, à 17:14

Re : Sudo et la sécurité?

#227 Le 26/02/2009, à 17:30

Re : Sudo et la sécurité?

#228 Le 26/02/2009, à 17:56

Re : Sudo et la sécurité?

#229 Le 26/02/2009, à 18:31

Re : Sudo et la sécurité?

#230 Le 26/02/2009, à 20:11

Re : Sudo et la sécurité?

#231 Le 26/02/2009, à 20:59

Re : Sudo et la sécurité?

#232 Le 26/02/2009, à 22:02

Re : Sudo et la sécurité?

#233 Le 26/02/2009, à 23:13

Re : Sudo et la sécurité?

#234 Le 27/02/2009, à 11:05

Re : Sudo et la sécurité?

#235 Le 27/02/2009, à 13:23

Re : Sudo et la sécurité?

#236 Le 27/02/2009, à 14:26

Re : Sudo et la sécurité?

#237 Le 27/02/2009, à 18:36

Re : Sudo et la sécurité?

#238 Le 27/02/2009, à 19:29

Re : Sudo et la sécurité?

#239 Le 27/02/2009, à 19:38

Re : Sudo et la sécurité?

#240 Le 27/02/2009, à 19:58

Re : Sudo et la sécurité?

#241 Le 27/02/2009, à 20:39

Re : Sudo et la sécurité?

#242 Le 27/02/2009, à 21:10

Re : Sudo et la sécurité?

#243 Le 27/02/2009, à 23:00

Re : Sudo et la sécurité?

#244 Le 28/02/2009, à 16:32

Re : Sudo et la sécurité?

#245 Le 02/03/2009, à 12:29

Re : Sudo et la sécurité?

#246 Le 02/03/2009, à 13:12

Re : Sudo et la sécurité?

#247 Le 02/03/2009, à 15:24

Re : Sudo et la sécurité?

#248 Le 02/03/2009, à 15:45

Re : Sudo et la sécurité?

#249 Le 03/03/2009, à 00:29

Re : Sudo et la sécurité?

#250 Le 18/03/2009, à 02:44

Re : Sudo et la sécurité?

Pied de page des forums