Sudo et la sécurité?

®om · Le 20/01/2009, à 20:05

Pareil, je viens de rentrer chez moi, ça ne fonctionne pas, j'ai fait avec ce script :

#!/bin/sh
while true
do
  date | sudo tee -a /etc/test &
  sleep 10
done

et le fichier /etc/test n'est pas créé, même après avoir fait un sudo ou gksudo autre part.

Par contre tous les sudo prennent du cpu.

Rubyman · Le 20/01/2009, à 20:16

Relis bien mon message précédent : tu ne dois pas faire un sudo ou un gksudo "autre part", tu dois lancer graphiquement un programme nécessitant les privilèges root (depuis le menu Système ou l'icône de notification de mise à jour). En outre, le script doit être lui aussi lancé graphiquement, en double-cliquant dessus.

Mathieu147 · Le 20/01/2009, à 21:37

Ouais ça marche! Moi je le lançais dans une console...

xabilon · Le 21/01/2009, à 01:17

philarmonie a écrit :

Edit: j'ai signalé le sujet pour qu'il soit supprimé.

Salut

Nous avons bien reçu ton signalement, mais je ne crois pas que ce soit souhaitable de dissimuler des failles potentielles.

Pour l'instant, cette faille nécessiterait :
- que le script soit lancé par l'utilisateur avec les droits d'exécution
- que cet utilisateur soit dans les sudoers (bon, c'est sûr, c'est le cas de 99,9% des utilisateurs d'Ubuntu)

Y-a-t'il un quelconque moyen de lancer automatiquement ce script, sans intervention de l'utilisateur ?

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

xabilon a écrit :

Y-a-t'il un quelconque moyen de lancer automatiquement ce script, sans intervention de l'utilisateur ?

Là je ne sais pas trop, je ne suis pas assez doué en programmation et dans la connaissance de linux pour savoir si on peut lancer un programme dans le dos de l'utilisateur (mais d'après les messages de certains sur la première page, j'ai cru comprendre que ça semblait possible).
Mais en tout cas, ce qu'a montré ce sujet c'est que dès qu'on fait appel à gksudo toutes les applications graphiques ont accès au droit root pendant un laps de temps sans demande de mot de passe, et un navigateur internet n'échappe pas à la règle Après je ne sais pas ce qu'un script sur une page web peut exécuter mais tout ceci ne me rassure pas trop pour le moment.
D'autant qu'un 'sudo -K' ne semble remettre le compteur à 0 de 'sudo' que dans la console dans laquelle il est exécuté.
J'ai bien tenté un 'gksudo "sudo -K"' afin d'annuler la non demande de mot passe pour les applications graphiques mais ça ne fonctionne pas
Résultat: je n'arrive toujours pas à forcer à nouveau la demande de mot de passe pour une application graphique après un appel à gksudo. Ce serait, en attendant la correction de la faille, un moyen de se rassurer un peu.

P.S: pour ce qui est de conserver le sujet en ligne, je comprend votre position.

Dernière modification par philarmonie (Le 21/01/2009, à 01:47)

Link31 · Le 21/01/2009, à 02:01

philarmonie a écrit :

Après je ne sais pas ce qu'un script sur une page web peut exécuter

Pas grand-chose, normalement. Mais à la moindre faille dans le navigateur, ça ne pardonnera pas.

Ce "bug" supprime en fait totalement les bénéfices de la séparation des droits utilisateurs/root : si un utilisateur sous Ubuntu utilisant un compte de simple utilisateur (donc quasiment tout le monde) est victime d'une faille logicielle, le code malveillant peut non seulement corrompre les fichiers de l'utilisateur, mais aussi compromettre/détruire le système, ainsi que toutes les partitions actuellement montés.

C'est totalement contraire à l'esprit d'UNIX. Dès qu'une faille est exploitée dans le navigateur, on en revient quasiment à une sécurité équivalente à celle de windows.

Bref : mauvaise distribution, changez de distribution

edit : je ne doute pas que les premiers "virus Linux", s'ils doivent apparaître un jour, exploitent ce genre de faille stupide sur des distributions qui se prétendent "grand public".

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

xabilon · Le 21/01/2009, à 02:11

Sauf qu'ici on est sur Ubuntu, une distrib grand public.
On se place donc dans une utilisation desktop mono-utilisateur, ou utilisation familiale
Or dans ce cas, les données des utilisateurs sont beaucoup plus importantes que le système.
Et faire un script qui supprime tout le contenu de ~/ est à la portée de n'importe qui, et ça marche sur n'importe quelle distrib.
Est-ce une faille ?

L'interface chaise-clavier reste un facteur prépondérant, et cette faille-là ne sera jamais corrigée.

N'empêche que ce sujet est intéressant

AlexandreP · Le 21/01/2009, à 05:18

Et vous êtes bien sûr que lorsque gksudo est utilisé, toutes les applications graphiques peuvent effectuer des tâches réservées au compte système ?

Par exemple, si j'ouvre Synaptic, gksudo me demande mon mot de passe pour me permettre d'exécuter Synaptic par le compte système (root). Si je tente d'ouvrir dans les 15 minutes suivantes une autre application qui nécessite d'être utilisée par root à l'aide de gksudo, gksudo ne me demande pas mon mot de passe. Jusque là, c'est normal. Mais :
- Est-ce que l'exécution dans les 15 minutes suivantes d'un programme qui ne peut être qu'exécuté par root sans que je passe par gksudo exécute réellement l'application ? Par exemple, si j'exécute synaptic (et non pas gksudo synaptic), est-ce que Synaptic s'exécute ? Il me semble bien que non, car toute tâche administrative doit l'être par gksudo.
- Est-ce que, si j'exécute une application quelconque sans passer par gksudo, cette application dispose des droits du compte système ? Par exemple, si j'ouvre Gedit sans gksudo dans les 15 minutes suivant le lancement de Synaptic, est-ce que Gedit saura modifier le contenu de /etc/fstab ? Il me semble que non, car le processus gedit n'a pas été exécuté par le compte système. Je n'ai donc pas accès aux fichiers appartenant à root.

Je prends pour acquis que :
- gksudo exécute un programme précis comme s'il avait été exécuté par le compte système, et non pas l'ensemble des applications actuellement et ultérieurement exécutées pendant tout le temps que gksudo ne demande pas la confirmation des actions ;
- que toutes les actions et processus exécutés depuis ce programme précis sont aussi exécutées par le compte système (normal : gksudo a attribué le processus au compte système, donc toutes les actions faites par cette application et les processus exécutés depuis cette application le sont par le compte système).

Du coup, la faille de sécurité est la même que si on exécute une session graphique en root...

jofab · Le 21/01/2009, à 08:00

Rubyman a écrit :

(gk)sudo est gardé en mémoire pour 15mn

Ca c'est déjà un comportement par defaut à risque... (faut pas aller au wc sans verouiller sa console juste apres un gksudo, sinon ton voisin de bureau peut etre root sur ta machine ...). Sans blague, par defaut il faudrait pas de memoire. Apres si on sais que l'on va faire plusieurs modifs à la suite, on active la memoire manuellement...

®om · Le 21/01/2009, à 08:22

xabilon a écrit :

Or dans ce cas, les données des utilisateurs sont beaucoup plus importantes que le système.

Le problème ici c'est qu'un programme "utilisateur" peut permettre l'exécution de code arbitraire par root (en attendant suffisamment longtemps que l'utilisateur tape son mot de passe root).

®om · Le 21/01/2009, à 08:25

AlexandreP a écrit :

Du coup, la faille de sécurité est la même que si on exécute une session graphique en root...

D'après moi, c'est exactement ça.

Du coup, chaque programme graphique (firefox par exemple) qui contient une faille permettant d'exécuter du code arbitraire permettrait d'exécuter du code "par root".

Après il faudrait avoir l'avis de personnes "expertes" (dévs ubuntu), pour qu'ils nous expliquent si le problème est réel, et si non, pourquoi ça n'est pas un problème.

Perso j'ai parfois du mal à appréhender le comportement de sudo/gksudo, parfois j'ai l'impression qu'il me redemande tout le temps le mot de passe, parfois non, faudrait faire un peu plus de tests…

Mais a priori, si un simple script comme ça :

#!/bin/sh
while true
do
  date | sudo tee -a /etc/test &
  sleep 10
done

permet d'écrire un fichier là où seul root peut écrire (il pourrait modifier /etc/hosts par exemple), et que ce code peut être exécuté en exploitant une faille d'un logiciel utilisateur (firefox par exemple), le problème est bien réel, et la phrase "sudo est aussi sécurisé que su" n'est pas vraie (car on ne peut pas exploiter ce genre de problème avec su).

philarmonie · Le 21/01/2009, à 08:31

@jofab: oui c'est ce que je vais faire, je vais couper la mémoire

@AlexandreP: je ne pense pas qu'une application lancée après un gksudo soit exécutée par le compte système (sauf bien entendu si on la lance avec un gksudo) mais bien par le compte utilisateur. Comme dans ton exemple de gedit, si tu le lances dans les 15 minutes, tu ne pourras jamais modifié des fichiers appartenant à root. Et c'est lié au fait que lorsque gedit veut sauvegarder un fichier il exécute une commande du type 'save mon_fichier'. Par contre si gedit le faisait avec une demande 'sudo save mon_fichier' (autrement dit si il demande à exécuter une commande en tant qu'administrateur) alors l'autorisation lui sera donné sans la demande du mot de passe.
Donc pour résumé, je dirai que la faille est la suivante: toute application graphique exécutée par un sudoers peut demander à exécuter des actions en tant que root sans que le mot de passe lui soit demandé.

La seule solution actuelle étant effectivement de mettre la mémoire de sudo à 0.

Mathieu147 · Le 21/01/2009, à 10:20

Je peux avoir un script/programme que je sais pas trop ce qu'il fait et que je veux tester. Je vais ouvrir un terminal. Après je peux tester mon script, avec mes droits utilisateur.

Maintenant, si, avant d'ouvrir le terminal j'ai ouvert Sunaptic pour installer un truc (par exemple, le programme à tester), alors le programme en question, s'il contient un sudo, ne me demandera pas mon mot de passe, alors que je pense l'exécuter avec mes droits à moi.

h4l · Le 21/01/2009, à 10:56

attendez je ne comprends pas une chose...

certes ubuntu c'est différent d'opensuse mandriva fedora etc... oui je trouve que sudo est plus permissible MAIS...

il faut bien rendre le script executable n'est-ce pas... et s'il n'est pas rendu executable avant d'arriver sur l'ordi à infecter, ya peu de chance que l'utilisateur le fasse... non?

ensuite, je pense que ça a été dit (enfin si j'ai bien pigé), mais le fait de lancer sudo dans un terminal ne donne pas les droit root à tout le système, donc le script n'a pas les droits tant qu'il n'est pas lancé dans le même terminal dans les 15 minutes ...
ça a été évoqué, le fait de lancer synaptic et de donner a ce dernier les droits root donnent-ils vraiment les droits à nautilus et compagnie? ça me choque là! et je dirais même ça serait étonnant...

puis, pour ce qui est de l'OS et plus précisément de la distro utilisée, certes ubuntu semble etre plus utilisée mais sudo est à mon humble avis moins utilisé que su si on regroupe ceux qui utilisent et ceux qui n'utilisent pas... apres faut voir si les configs sont restés par défaut etc... quel casse tête!! donc le méchant devra dans ce cas se dire "je vais toucher un minimum de personne et je m'en contente!"

Pour ce qui est de la securité, je ne pense pas qu'on puisse s'en faire plus que sous d'autres OS, perso, je ne sais pas si ubuntu est plus facilement vulnérable qu'une opensuse (même si sudo a tendance a donner avantage a opensuse) mais ce qui est sur c'est que les distros gnu/linux sont moins facilement vulnérables que mac et windows... comme peuvent le témoigner plusieurs concours de hacking ex: http://www.generation-nt.com/cansecwest-hack-piratage-linux-vista-mac-concours-securite-actualite-70475.html...

En tout cas, je suis pour un renforcement de la securité par le biais de nouveaux softs sous linux... je ne parle pas spécialement d'antivirus mais pourquoi pas... et quand je dis antivirus je ne parle pas de norton ou avg ou antivir mais bien d'outil linux et libre qui permette de bloquer des comportements anormaux ou non signé etc...

un systeme de signature pour tout ce qui est dépot ça c'est fait, on peut imaginer des signature pour les soft en .deb récupéré sur google ou adobe etc... et enfin, pour tout ce qui exige un droit root demander confirmation de l'utilisateur, exemple:

le script veut se lancer, on lui donne les droits a cause de synaptic par exemple MAIS comme il n'appartient pas au "domaine" synaptic, on fait intervenir l'utilisateur...

je ne sais pas si c'est cohérent mon raisonnement mais bon!

h4l · Le 21/01/2009, à 11:01

re!

je ne pige pas là... sous ubuntu, un gksudo ou kdesu nautilus donne les droits a tout ce qui est graphique????

ça m'étonne franchement...

pour ce qui est de mettre la memoire de sudo à 0, c'est mieux, mais dans ce cas autant utiliser su... et puis si t'as utilisé sudo pour une compilation de firefox, le script a le temps non?

®om · Le 21/01/2009, à 11:03

h4l a écrit :

il faut bien rendre le script executable n'est-ce pas... et s'il n'est pas rendu executable avant d'arriver sur l'ordi à infecter, ya peu de chance que l'utilisateur le fasse... non?

Si une faille d'un programme quelconque est exploitée pour exécuter du code arbitraire, le code arbitraire, par définition, fait ce qu'il veut (avec les droits qu'on lui donne). Donc s'il veut exécuter un script en passant par un fichier, il fait un chmod +x, s'il veut l'exécuter en faisant "sh monscript", il le fait...

jofab · Le 21/01/2009, à 11:35

xabilon a écrit :

Sauf qu'ici on est sur Ubuntu, une distrib grand public.
On se place donc dans une utilisation desktop mono-utilisateur, ou familiale

Comme certains se placent dans une utilisation mono-utilisateur, on doit oublier les autres ?

xabilon a écrit :

Or dans ce cas, les données des utilisateurs sont beaucoup plus importantes que le système.
Et faire un script qui supprime tout le contenu de ~/ est à la portée de n'importe qui, et ça marche sur n'importe quelle distrib.
Est-ce une faille ?

Et meme dans le cadre d'une utilisation familiale, il peut y plusieurs comptes. Si les données d'un comptes sont détruites, les autres ne sont pas touchés, en revanche, si le systeme est atteint, toutes les donnees sont exposées... Si ton petit frere fait une betise et perd ses données, tu es content de garder les tiennes ?

Sinon autant revenir à Windows

iuchiban · Le 21/01/2009, à 11:43

®om a écrit :

h4l a écrit :
il faut bien rendre le script executable n'est-ce pas... et s'il n'est pas rendu executable avant d'arriver sur l'ordi à infecter, ya peu de chance que l'utilisateur le fasse... non?
Si une faille d'un programme quelconque est exploitée pour exécuter du code arbitraire, le code arbitraire, par définition, fait ce qu'il veut (avec les droits qu'on lui donne). Donc s'il veut exécuter un script en passant par un fichier, il fait un chmod +x, s'il veut l'exécuter en faisant "sh monscript", il le fait...

Oui mais dans ce cas là, le "virus" est-il lancé en graphique ou bien dans un shell dans lequel il faudrait donc lancer une commande avec sudo pour le rendre effectif?
Vu qu'en général ce sont les navigateurs qui sont visés puisque connecté au web, si firefox subit l'attaque d'une faille et exécute du code, dans quel "terminal" ce code est-il exécuté?

valAa · Le 21/01/2009, à 11:49

iuchiban a écrit :

si firefox subit l'attaque d'une faille et exécute du code, dans quel "terminal" ce code est-il exécuté?

Dans le même que tout autre application graphique.
Donc si firefox exécute ce code, il suffit ensuite qu'une application graphique demande (et obtienne) les droits admin, pour que le script méchant aie 15 min pour devenir admin sans demande de mot de passe.
Toutes les applications graphiques d'une session sont en effet lancées par la même console, et c'est pour cela que ça peut marcher.

iuchiban · Le 21/01/2009, à 12:00

valAa a écrit :

iuchiban a écrit :
si firefox subit l'attaque d'une faille et exécute du code, dans quel "terminal" ce code est-il exécuté?
Dans le même que tout autre application graphique.
Donc si firefox exécute ce code, il suffit ensuite qu'une application graphique demande (et obtienne) les droits admin, pour que le script méchant aie 15 min pour devenir admin sans demande de mot de passe.
Toutes les applications graphiques d'une session sont en effet lancées par la même console, et c'est pour cela que ça peut marcher.

Et donc, si sur le lanceur de firefox on coche l'option "Lancer dans un terminal", le code arbitraire sera lancé dans ce terminal et ne bénéficiera pas du sudo de synaptic qui sera lancé dans un autre terminal par exemple?

@philarmonie : tu as ouverts un sujet fort passionnant en tous cas

valAa · Le 21/01/2009, à 12:05

iuchiban a écrit :

Et donc, si sur le lanceur de firefox on coche l'option "Lancer dans un terminal", le code arbitraire sera lancé dans ce terminal et ne bénéficiera pas du sudo de synaptic qui sera lancé dans un autre terminal par exemple?

Là comme ça, à l'arrache je dirais oui. Mais ça demande vérification (je peux pas tester là au taf) ou confirmation.

Rubyman · Le 21/01/2009, à 12:53

xabilon a écrit :

philarmonie a écrit :
Edit: j'ai signalé le sujet pour qu'il soit supprimé.
Salut
Nous avons bien reçu ton signalement, mais je ne crois pas que ce soit souhaitable de dissimuler des failles potentielles.
Pour l'instant, cette faille nécessiterait :
- que le script soit lancé par l'utilisateur avec les droits d'exécution
- que cet utilisateur soit dans les sudoers (bon, c'est sûr, c'est le cas de 99,9% des utilisateurs d'Ubuntu)
Y-a-t'il un quelconque moyen de lancer automatiquement ce script, sans intervention de l'utilisateur ?

D'accord avec toi, comme je l'ai précisé, cette faille n'est pas non plus critique : elle permet certes à un cheval de troie d'obtenir les droits root, mais çà reste un cheval de troie n'affectant que les utilisateurs avec les droits d'admin... Qu'il faut télécharger soit-même sur un site peu fiable, autoriser à s'exécuter puis lancer volontairement en temps que programme. Pas beaucoup de différence avec un simple cheval de troie empaqueté dans un .deb, quelqu'un lançant graphiquement un programme téléchargé étant de toute façon quelqu'un qui donnerait son mot de passe si c'était demandé.

Du coup, chaque programme graphique (firefox par exemple) qui contient une faille permettant d'exécuter du code arbitraire permettrait d'exécuter du code "par root".

Oui, effectivement... Mais une faille permettant d'exécuter du code arbitraire serait déjà classée "hautement critique".

Je peux avoir un script/programme que je sais pas trop ce qu'il fait et que je veux tester. Je vais ouvrir un terminal. Après je peux tester mon script, avec mes droits utilisateur.
Maintenant, si, avant d'ouvrir le terminal j'ai ouvert Sunaptic pour installer un truc (par exemple, le programme à tester), alors le programme en question, s'il contient un sudo, ne me demandera pas mon mot de passe, alors que je pense l'exécuter avec mes droits à moi.

Ne t'inquiète pas, j'ai donné une procédure très précise de la manipulation, et c'est seulement celle-là qui pose problème : lancer graphiquement un programme (graphique ou non), en double-cliquant dessus et en choisissant "Lancer" (après avoir activé l'autorisation), puis lancer un programme demandant les droits root depuis le menu système ou l'icône de notification. Si le script téléchargé est exécuté dans un terminal, il n'y a aucun risque.

Dernière modification par Rubyman (Le 21/01/2009, à 13:07)

philarmonie · Le 21/01/2009, à 12:59

iuchiban a écrit :

Et donc, si sur le lanceur de firefox on coche l'option "Lancer dans un terminal", le code arbitraire sera lancé dans ce terminal et ne bénéficiera pas du sudo de synaptic qui sera lancé dans un autre terminal par exemple?

A priori je dirai oui aussi, je vais faire le test et je te tiens au courant.
Par contre imagine ce scénario:
- tu ouvres une console
- tu fais quelques sudo blabla dedans
- tu fermes la console
- tu lance ton firefox dans un terminal
- y'a de forte chance que ce terminal soit le même que celui utilisée par la précédente console et la faille est de retour

En fait je trouve que c'est le concept même de 'sudo' qui est problématique, car il réduit la limite compte admin/compte utilisateur.
Comme sur Ubuntu y'a pas de compte root, on ne peut pas faire autrement que d'utiliser sudo pour effectuer des taches d'admin.
Résultat la seule solution sécurisée est de supprimer la mémoire de mot passe de 'sudo' et de la remettre si besoin (par exemple quand on besoin de faire plusieurs taches d'admin à la suite, ça évite de retaper le mot passe à chaque fois).

Enfin pour une distribution grand public comme ubuntu, qui si j'ai bien compris a mis en place 'sudo' et la non existence de compte root afin de protéger l'utilisateur d'erreur de manipulation, met plutôt ses utilisateurs dans une situation de sécurité proche de windows (et encore si on utilise windows avec un compte admin et un compte utilisateur on est dans la même position qu'un linuxien qui utilise 'su' pour passer en admin).

Rubyman · Le 21/01/2009, à 13:06

philarmonie a écrit :

Par contre imagine ce scénario:
- tu ouvres une console
- tu fais quelques sudo blabla dedans
- tu fermes la console
- tu lance ton firefox dans un terminal
- y'a de forte chance que ce terminal soit le même que celui utilisée par la précédente console et la faille est de retour

Non, puisqu'entre ton sudo et le lancement de firefox, tu as fermé le terminal. Si le terminal est le même, alors oui, mais à mon avis, ce scénario n'a aucune chance de se produire dans la vraie vie (faire sudo puis lancer firefox dans la même console, c'est déjà pas courant, alors si en plus il faut que cet utilisateur avancé aille sur un site compromis dans les 15 mn...)

Tant que vous ne lancez pas de scripts louches graphiquement, aucun problème. Rappelez-vous simplement que vous devez l'exécuter dans un nouveau terminal, au cas où vous auriez utilisé un sudo dans ce même terminal (par contre çà, "it's not a bug, it's a feature", à moins de désactiver la mémorisation de sudo).

Dernière modification par Rubyman (Le 21/01/2009, à 13:10)

philarmonie · Le 21/01/2009, à 13:07

Rubyman a écrit :

Ne t'inquiète pas, j'ai donné une procédure très précise de la manipulation, et c'est seulement celle-là qui pose problème : lancer graphiquement un programme (graphique ou non), en double-cliquant dessus et en choisissant "Lancer" (après avoir activé l'autorisation), puis lancer un programme demandant les droits root depuis le menu système ou l'icône de notification. Si le script téléchargé est exécuté dans un terminal, il n'y a aucun risque.

Et dans le cas d'un fichier binaire (qui ne demande donc pas si on veut bien le lancer ou l'éditer) le problème est aussi présent?
Et dans le cas du navigateur, si le code malicieux qui utilise la faille demande à agir en root, vu que j'ai moi même ouvert le navigateur en graphique, il doit bien avoir le droit de le faire?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 20/01/2009, à 20:05

Re : Sudo et la sécurité?

#27 Le 20/01/2009, à 20:16

Re : Sudo et la sécurité?

#28 Le 20/01/2009, à 21:37

Re : Sudo et la sécurité?

#29 Le 21/01/2009, à 01:17

Re : Sudo et la sécurité?

#30 Le 21/01/2009, à 01:43

Re : Sudo et la sécurité?

#31 Le 21/01/2009, à 02:01

Re : Sudo et la sécurité?

#32 Le 21/01/2009, à 02:11

Re : Sudo et la sécurité?

#33 Le 21/01/2009, à 05:18

Re : Sudo et la sécurité?

#34 Le 21/01/2009, à 08:00

Re : Sudo et la sécurité?

#35 Le 21/01/2009, à 08:22

Re : Sudo et la sécurité?

#36 Le 21/01/2009, à 08:25

Re : Sudo et la sécurité?

#37 Le 21/01/2009, à 08:31

Re : Sudo et la sécurité?

#38 Le 21/01/2009, à 10:20

Re : Sudo et la sécurité?

#39 Le 21/01/2009, à 10:56

Re : Sudo et la sécurité?

#40 Le 21/01/2009, à 11:01

Re : Sudo et la sécurité?

#41 Le 21/01/2009, à 11:03

Re : Sudo et la sécurité?

#42 Le 21/01/2009, à 11:35

Re : Sudo et la sécurité?

#43 Le 21/01/2009, à 11:43

Re : Sudo et la sécurité?

#44 Le 21/01/2009, à 11:49

Re : Sudo et la sécurité?

#45 Le 21/01/2009, à 12:00

Re : Sudo et la sécurité?

#46 Le 21/01/2009, à 12:05

Re : Sudo et la sécurité?

#47 Le 21/01/2009, à 12:53

Re : Sudo et la sécurité?

#48 Le 21/01/2009, à 12:59

Re : Sudo et la sécurité?

#49 Le 21/01/2009, à 13:06

Re : Sudo et la sécurité?

#50 Le 21/01/2009, à 13:07

Re : Sudo et la sécurité?

Pied de page des forums