Avec « virer Skype », on s’attend à un bête truc comme ça:apt-get remove skype
apt-get purge skype
Alors que le contenu du fil est bien plus riche. Par ailleurs, peut-être certaines personnes ont mémorisé « sécuriser », et ne retrouveront pas le fil en cas de recherche dans x mois. « sécuriser Skype = mission impossible n’utilisez pas de spyware social » serait un titre plus approprié.
[quote=“nykoos”] apparmor="DENIED" operation="file_mmap" parent=15303 profile="/usr/bin/skype" name="/etc/group" pid=15317 comm="Backbone" requested_mask="m" denied_mask="m" fsuid=1002 ouid=0
que voulait faire dans /etc/group avec Backbone qui possède uid 0 de root !?
qui est ce fameux Backbone dont se sert skype ? en tout cas apparmor l’a bien empêché d’allé fouiné dans /etc/group
faisons une petite recherche depuis la racine:
grep -rn “Backbone” /
Fichier binaire /usr/sbin/tcpdump concordant
Fichier binaire /usr/lib/libwireshark.so.2.0.2 concordant
question: mais que veut faire skype avec tcpdump libwireshark ??
[/quote]Je ne suis pas sûr de cette interprétation, je ne connais pas bien apparmor mais j’ai été étonné de voir skype avec des droits acquis root. Ça me parait hautement plus grave que la découverte par skype des sites où je vais. Voilà ce que j’ai trouvé:
file_mmap est une opération d’accès en lecture seule à des fichiers (conseillés pour ceux utilisés par de nombreux processus), /etc/group doit être accédé par les programmes pour connaitre les groupes, il n’est pas anormal que skype y accède lors de son fonctionnement.
ouid désigne le propriétaire de «name» soit donc /etc/group.
En clair l’application cherche à accéder à /etc/group (ce qui en soit n’est pas bien grave)
Enfin Backbone est certes dans wireshark, en l’occurrence dans le chaine «802.1ah Provider Backbone Bridge (mac-in-mac)» qui n’a pas grand chose à voir avec skype. Je pense que wireshark n’a strictement rien à voir avec cette histoire (on se demande d’ailleurs en quoi skype aurait besoin de faire appel à wireshark plutôt que d’intégrer directement cette application si ellele veut). Reste le nom Backbone et son origine; comm= indique le nom de l’application qui a lancé l’appel noyau. profile désigne le profile concerné par apparmor. Je n’arrive pas à voir d’où vient ce nom «Backbone». Visiblement le processus père (15303) a lancé plusieurs processus (celui là est le 15317) en leur donnant des noms. Peut être est ce un nom choisi (mais je n’ai pas trouvé la chaine Backbone dans le binaire de skype). J’ai fouillé les sources d’apparmor mais je n’ai rien trouvé de particulier là dessus.
En tout cas, ça n’est pas du tout un faux utilisateur backbone crée par skype avec un uid à 0 lançant wireshark, juste un processus, venu de skype et lisant /etc/group ce qui est parfois normal lorsqu’on fait du controle d’accès (pour savoir si untel appartient au groupe video par exemple). Seul lenom Backbone est vraiment curieux, je n’ai pas d’explications dessus.
Ça n’enlève rien sur skype fouillant .mozilla…
merci pour les explications fran.b, lui enlever les droits de lecture + apparmor seraient finalement crédible pour le sécuriser, mais dans le doute je ne le réinstalle plus.
Mais pourquoi empecher la lecture de /etc/group? C’est utile pour éventuellement regarder les droits de l’éxécutant et ne pas proposer la vidéo par exemple…
Il y a des tas de raisons de ne pas installer skype, mais pas la lecture de /etc/group. Le parcours de .mozilla est une raison suffisante.
[quote=“fran.b”]Mais pourquoi empecher la lecture de /etc/group? C’est utile pour éventuellement regarder les droits de l’éxécutant et ne pas proposer la vidéo par exemple…
Il y a des tas de raisons de ne pas installer skype, mais pas la lecture de /etc/group. Le parcours de .mozilla est une raison suffisante.[/quote]
parceque je pensais que Backbone avait un droit root et qu’il pouvait alors se rajouter dans un groupe pour s’octroyer les droits, mais fort heureusement ouid=0 ne concerne pas Backbone mais /etc/group ce qui change tout évidemment, merci de ton éclaircissement, je vais alors pouvoir remettre le titre d’origine: sécuriser skype.
Et je ne sais pas si c’est une coincidence mais depuis l’installation apparmor skype ne fait plus ramer mon ordi ce qui peux laisser supposer qu’il y a quelque chose qu’il faisait et qu’il ne fait plus…finalement je le réinstalles pour lever ce doute je vais désactiver apparmor.
@Cluxter
complément d’accord avec toi, mais je n’ai pas toujours la possibilité de proposer à mes contacts d’installer linphone, jitsi, gajim…et lorsqu’il le font, bien souvent il faut passer du temps car ils n’ont plus de son, ni vidéo, ou les multi-conférence ne fonctionne pas bref il faut quand même reconnaître que la grande force de skype est d’être immédiatement fonctionnel quelque soit la plateforme.
Il faut analyser le strace pour cela et regarder avec top le processus gourmand. Interdire des accès peut par exemple empêcher l’accès à la recherche de certaines ressources videos, audio ou autres que de toute façon tu n’utilises pas. ça peut être aussi tout bêtement qu’il ne parcourt pas le disque. J’avais tracé skype à l’époque de la version 2.0 (voir ce fil par exemple) et il ne débordait pas de .firefox par contre je l’avais clairement vu ouvrir le fichier contenant les mots de passe stockés de firefox.
C’est ce qui fait sa force.
Mais avec le WebRTC on peut monter soi-même sa propre plateforme en HTML 5, c’est pas si compliqué à faire. Ca serait bien si on faisait notre propre site Debian-Fr WebRTC tiens !
le salopard
à ton avis ce sont les développeurs skype depuis leurs serveurs ? ou un autre utilisateur qui saurait comment exploiter la particularité que skype peut utiliser la bande passante d’un connecté pour servir de relais.
Je pense très clairement pour l’intégration de cette fonction directement dans le binaire de Skype. Il faudrait voir si Microsoft propose le hash du binaire pour pouvoir le comparer avec celui qu’on a téléchargé (et je doute que les serveurs et/ou les connexions aux serveurs de Microsoft soient piratés au point qu’on récupère des informations falsifiées, c’est voyant quand même).
C’est ce qui fait sa force.
Mais avec le WebRTC on peut monter soi-même sa propre plateforme en HTML 5, c’est pas si compliqué à faire. Ca serait bien si on faisait notre propre site Debian-Fr WebRTC tiens ! [/quote]
pas mauvaise idée, surtout que le serveur ne sert qu’à initialiser la connection, aprés, c’est directement entre les 2 machines, j’avais déjà essayé WebRTC mais le navigateur faisait ramer l’ordi à l’époque, ce n’était pas encore au point, à réessayer.
Dans le genre il y avait ça :
appear.in/
(vu sur le site de Korben)
Ça fonctionne comment ce WebRTC ? C’est du P2P ? ou tu passes par un serveur ?
Pour le fichier des mots de passe de firefox, ça lui serait impossible si on met un mot de passe global à firefox (à ce moment là le firefox chiffre ce fichier). Ça me semble être une bonne pratique.
Attention, ce n’est pas parce que c’est chiffré que c’est protégé.
Le chiffrement n’est là que pour ralentir l’accès à des données, pas pour empêcher d’y accéder (exception faite des clés à usage unique).
Attention, ce n’est pas parce que c’est chiffré que c’est protégé.
Le chiffrement n’est là que pour ralentir l’accès à des données, pas pour empêcher d’y accéder (exception faite des clés à usage unique).[/quote]
Hum, si tu veux, je t’envois des données chiffrées et te paye un repas à la tour d’argent si tu y accèdes…
Attention, ce n’est pas parce que c’est chiffré que c’est protégé.
Le chiffrement n’est là que pour ralentir l’accès à des données, pas pour empêcher d’y accéder (exception faite des clés à usage unique).[/quote]
Hum, si tu veux, je t’envois des données chiffrées et te paye un repas à la tour d’argent si tu y accèdes…[/quote]
Aujourd’hui peut être pas, mais disons que dans 10 ans tes données seront bien moins protégées du fait de l’augmentation de la puissance de calcul. D’autant plus si je suis une entité qui possède des supercalculateurs. On a vu ce qu’a donné le chiffrement qui était utilisé à l’époque dans les cartes bancaires. Il était très robuste lorsqu’il est sortit, il l’a été beaucoup moins quelques années après.
Le chiffrement n’empêchera pas d’accéder aux données dans quelques années si on en a conservé une copie. Tout l’intérêt d’utiliser un chiffrement fort c’est de retarder le plus possible l’accès aux données sensibles de façon à ce que le jour où on arrive à casser le chiffrement, les données ne soient plus d’une grande utilité. A part un chiffrement à clé unique, rien ne peut empêcher dans un futur relativement proche l’accès aux données chiffrées, du fait de l’augmentation exponentielle de la puissance de calcul.
Le chiffrement est donc à considérer comme un frein, pas une sécurité en tant que telle.
Un pare-feu, ça c’est une sécurité bloquante : si on définit les bonnes règles, on ne peut rien faire passer sur les canaux qu’on veut bloquer. Un chiffrement, tôt ou tard, finit par être cassé.
[quote=“Cluxter”]Le chiffrement est donc à considérer comme un frein, pas une sécurité en tant que telle.
Un pare-feu, ça c’est une sécurité bloquante : si on définit les bonnes règles, on ne peut rien faire passer sur les canaux qu’on veut bloquer. Un chiffrement, tôt ou tard, finit par être cassé.[/quote]
Tu expliquera à ton garagiste que le problème de frein lors des contrôles technique n’est pas une sécurité.
Toute sécurité est relative. Tu peut toujours dire que dans un temps donné la sécurité en question n’aura plus aucune valeur. Les parfeux ne sont pas une sécurité selon ta définition, en 2012 la majorité des attaques par déni de service ont visé les par-feu et pas les services derrière. Même bien configurer un botnet suffisamment grand peu faire tomber ton par-feu. Tout les chiffrements asymétriques tomberont si on arrive à faire des ordinateurs quantiques ou si on trouve un algo pour faire une décomposition en nombre primaire de très grands chiffres de complexité plus faible. Il y a de plus une ingéniosité qui consiste à trouver des failles qui ne sont pas dans les algorithmes, mais dans les implémentations. Aujourd’hui utiliser une CPU Intel, ARM ou AMD c’est avoir une sécurité toute relative quelque soit ce que tu fait.
Bref toute sécurité est relative.
La question n’est donc pas de savoir s’il est techniquement impossible d’accéder à tes données (parce que ça ce n’est un problème, les services de renseignement peuvent y accéder quelque soit la sécurité informatique que tu utilise), mais de savoir quelle valeur cherche-tu à protéger et combien ça coute de les avoir. Donc tes mots de passe, est-ce que tu pense que Microsoft a les moyens (ou l’intérêt) de récupérer les fichiers chiffrés des quelques utilisateurs de Skype qui chiffrent leur mot de passe pour les lancer sur un super calculateur. Tout ça pour… pourquoi au fait ? Non MS est plus intéressé pour te profiler donc techniquement il serait probablement plus intéressé par ton historique, ça a nettement plus de valeur parce que ça leur permet de te définir comme potentiel client.
[quote=“Cluxter”][quote=“fran.b”][quote=“Cluxter”]
Hum, si tu veux, je t’envois des données chiffrées et te paye un repas à la tour d’argent si tu y accèdes…[/quote]
Aujourd’hui peut être pas, mais disons que dans 10 ans tes données seront bien moins protégées du fait de l’augmentation de la puissance de calcul. D’autant plus si je suis une entité qui possède des supercalculateurs. On a vu ce qu’a donné le chiffrement qui était utilisé à l’époque dans les cartes bancaires. Il était très robuste lorsqu’il est sortit, il l’a été beaucoup moins quelques années après.
Le chiffrement n’empêchera pas d’accéder aux données dans quelques années si on en a conservé une copie. Tout l’intérêt d’utiliser un chiffrement fort c’est de retarder le plus possible l’accès aux données sensibles de façon à ce que le jour où on arrive à casser le chiffrement, les données ne soient plus d’une grande utilité. A part un chiffrement à clé unique, rien ne peut empêcher dans un futur relativement proche l’accès aux données chiffrées, du fait de l’augmentation exponentielle de la puissance de calcul.
Le chiffrement est donc à considérer comme un frein, pas une sécurité en tant que telle.
[/quote][/quote]
Non, tout est affaire de complexité: Tu raisonnes comme si le décryptage avait une complexité automatiquement polynomiale. Le codage RSA, les codes fondés sur le pbm du sac à dos, sur les courbes elliptiques, ou globalemant les logs dans un groupe sont des codes qui à l’heure actuelle sont mathématiquement indéchiffrables parce que la complexité mathématique des algorithmes est exponentielle, le temps de décryptage rend l’age de l’univers non significatif et rajouter un bit à la clef double le temps de calcul. Ça n’est pas avec des moyens techniques nettement supérieurs que tu arriveras à le décoder. Même si il existe désormais un algorithme polynomial pour casser un code RSA sur un ordinateur quantique (très astucieux d’ailleurs), d’autres codes résistent de toute façon à cela et sont connus. Bref, tu veux rendre des données non déchiffrables le temps de survie du système solaire, tu peux. Si la NSA est en mesure d’intercepter des communications chiffrées, c’est parce qu’il a des mouchards lui donnant la clef de chiffrage avant, pas parce qu’il sait casser le code.
[PS:Ça devrait aller dans Pause Café]
c’est fort cette phrase, Cluxter comme potentiel client de Microsoft, s’ils tombent sur son profil ils vont avoir les cheveux qui se redressent …
J’ai regardé de nouveau un strace de skype (lancement etarrêt).Il fait un paquet de chosesmais ilsemble s’être calmé un peu:
Fichiers ouverts:
- Il parcourt toujours .mozilla mais n’ouvre que pref.js (réglages d’iceweasel). Sous Windows, les proxys sont récupérés dans ces réglages, cela pourrait être une explication.
- Il parcourt toutes les extensions et les répertoires correspondants.
Fichiers sur lequel il fait un stat64 (donc informations diverses, en général c’est du à un parcours du répertoire pour chercher un fichier donné): Tout le répertoire .mozilla mais c’est tout.
Il y a effectivement un filament (thread, ça ne semble pas être un fork) nommé Backbone lancé. Pour autant que ma recherche rapide soit correcte, les noms des processus sont
aresolv
AsyncIOModule
auf::SystemTrac
Backbone
CommLayerManage
dyncon-worker
FallbackConnMan
IPChangeMonitor
LVAP0 thread
MutexDeadlockMo
PowerEvents
RVAP0 thread
Setup
skype
Stats2Thread
ThreadMonitor
(il en manque peut être)
Il ouvre beaucoup de fichiers systèmes (dont /etc/passwd) mais je n’ai rien vu de scandaleux.
Bien évidemment tout cela est juste sur un démarrage et une fermeture rapide. Il faudrait regarder plus longuement en le laissant tourner. Je le fais mais en regardant juste les fichiers accédés (le log est explosif).
[à suivre]
[suite]Voilà la liste complète des fichiers ouverts par skype pendant un fonctionnement d’une heure.
Il y a plusieurs fichiers sur lesquels un stat64 à été fait donc lecturedes informations basiques (propriétaire, etc). Bon, par rapport à la version 2.0, c’est nettement mieux, notamment je ne vois plus vraiment de fichiers ouverts choquants dans .mozilla à l’inverse de la version 2.0. C’est plutôt une bonne surprise.
[ça ne retire rien sur le fait qu’on ne sait pas ce qu’il fait, et sur le protocole fermé utilisé]
Fichiers.txt (20.3 KB)