Ola* LinuxFR
En ce temps troublé où l'on se met à regarder l'actualité sous le prisme du dernier scandale en date révélé par le traître Snowden, la question de la protection de nos données, et donc de nos vie revient sur le tapis une énième fois.
Personnellement je ne suis pas plus choqué (enfin, surpris du moins) que ça d'apprendre que le gouvernement 'ricain fouille dans les données qu'on confie à gmail, facebook et consorts, il me semblait que c'était déjà de notoriété publique, de part la simple existence du Patriot Act.
Depuis quelques jours les langues se délient sur FRnOG au sujet des splitter qu'on met au bout des fibres optiques transcontinentales pour zyeuter ce qui se passe dedans, et la pratique semble, si ce n'est généralisée, au moins très répandue.
Mais l'humain étant ce qu'il est, il m'a fallu à moi aussi cet électro-choc pour finir de me débarrasser de Gmail.
Je suis un peu bêbête, j'ai déjà mon serveur de mail auto-hébergé, et pour avoir une solution de repli il me suffisait de demander à mon FAI, FDN, de me créer une boite au lettre qui serait hébergé sur une machine dont j'ai globalement confiance en l'éthique de ceux qui ont la main dessus.
Mais là n'est pas le sujet…
Le camarade Spyou pose une question intéressante via un autre service dont on peut se méfier : https://twitter.com/Turblog/status/349638536548450304 .
(Pour ceux qui ne veulent pas cliquer, la question est la suivante : « Quelqu'un, en dehors de la NSA, a audité le code de SELinux ? :) #complot #parano #BSDsaymieux »)
C'est là que ça pourrait partir en troll, mais j'ai un mince espoir de voir des réponses argumentées, amis contributeurs de LinuxFR.
La première des réponses qu'on va me faire c'est «oui mais le code source il est dispo, t'as qu'à vérifier, tu peux le faire, c'est un gage de sécurité et d'absence de backdoor».
Une réponse un peu plus honnête serait «Effectivement on peut vérifier, mais rien ne garanti que quelqu'un ai réellement pris le temps de le faire sérieusement, que le code source soit dispo est une chose, qu'il est effectivement été audité en est une autre.»
Sur un sujet relativement connexe, Stéphane Bortzmeyer rappelle dans son dernier billet de blog ( http://www.bortzmeyer.org/porte-derobee-routeur.html ) que même si un réseau est entièrement composé de boites, peut être pas noires, mais au moins très opaque, le fait que tout ceci soit surveillé de très près permet tout simplement de douter de l'existence de backdoors, ou en tout cas permet d'affirmer que les chances sont réellement et excessivement proche de 0.
Ensuite effectivement le code de SELinux est certes du made in NSA, mais la NSA est un gros service, il est pas débile d'imaginer que la main droite ignore ce que fait le pied gauche, ou du moins n'influe pas dessus, donc il est tout à fait possible d'imaginer que ceux chargés de vérifier dans les mails qu'une bombe va pas pêter sur le sol américain n'aient que peu de choses en commun avec l'équipe chargée de renforcer la sécurité de Linux via le module SELinux.
Alors, vos avis ?
Faut-il que j'abandonne le confort de ma ubuntu pour mon desktop et de debian pour le serveur et tout réapprendre et switcher vers (par exemple) FreeBSD sur le desktop et OpenBSD sur le serveur, selon vous, ou puis je conserver mon petit train train quotidien sans train craindre d'indiscrétion de la part de mon OS ?
# Mouai…
Posté par Marotte ⛧ . Évalué à 9.
Je ne vois pas trop la différence entre GNU/Linux et *BSD pour le coup. OK (je ne le savais pas) la NSA est à l'origine de SELinux mais elle n'est pas la seule à voir le code. D'autre part, un agent de la NSA pourrait très bien participer au développement de FreeBSD (de manière officielle, ou pas) s'il le souhaitait.
Je crois très peu à une backdoor dans le noyau de FreeBSD ou le noyau Linux car il y a trop de monde qui regarde le code. Par contre dans des applications sous GNU/Linux ça s'est déjà vu.
Il me semble qu'en France c'est la gendarmerie nationale qui est à l'origine (ou en tous cas ils ont œuvré pour) le support de GPG dans Thunderbird. Je ne vois pas où est le problème, pour SELinux et la NSA c'est pareil.
Pareil.
# BSD
Posté par Marotte ⛧ . Évalué à 3.
Si tu tiens vraiment à essayer BSD à ta place j'éviterais de prendre deux BSD différents, ça va te faire plus à « appréhender ». À ma connaissance ni FreeBSD ni OpenBSD ne sont particulièrement orientés vers une utilisation serveur ou dekstop.
Ce que je pourrais te conseiller c'est de mettre FreeBSD sur ton serveur et PC-BSD sur ton desktop. PC-BSD c'est du FreeBSD sous le capot mais avec une belle carrosserie pour une utilisation desktop.
[^] # Re: BSD
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 9.
Les différences entre les deux ne sont pas insurmontables quand même. Passer de FreeBSD à OpenBSD se fait plus facilement que d'un Linux avec "Network Manager" à un Linux "interfaces.conf"-like :)
J'ai évité de parler de init Sys V et de systemd pour éviter le troll… Hein ? C'était déjà fait ? :D
[^] # Re: BSD
Posté par anaseto . Évalué à 6.
En fait, j'ai essayé OpenBSD une fois il y a un an et ça s'installe vraiment en très peu de temps, avec X et tout, donc plus facile qu'une Arch ou une Gentoo, tant que tout le matériel est bien reconnu. Par contre, d'expérience, dans un matériel quelconque assez récent c'est facile d'avoir des problèmes (j'ai eu droit à un écran mal détecté et un touchpad qui faisait n'importe quoi), donc il faut regarder sur leur page pour se faire une idée des matériels supportés.
[^] # Re: BSD
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 6.
FreeBSD serveur et PC-BSD desktop pourquoi, c'est un peu comme dire debian serveur ubuntu desktop, autant prendre debian partout si ça marche mieux :p
Sinon, il y a Debian/kfreebsd, pour l'avoir testé un peu en serveur, ça marche bien.
# Deux idées
Posté par Zylabon . Évalué à 5.
SELinux est une sécurité « en plus », si vous envisagez qu'une backdoor ait pu y être introduite, il suffit de ne pas l'utiliser, la sécurité native de Linux est déjà excellente. Ou utiliser apparmor au lieu de SELinux (c'est pas le cas d'Ubuntu d'ailleurs ?).
Par ailleurs, s'ils ont introduit une backdoor, ils l'ont fait discrètement ! Auditer de le code ne servirait pas à grand chose.
Please do not feed the trolls
[^] # Re: Deux idées
Posté par Misc (site web personnel) . Évalué à 3.
En fait, selinux est un système de label et de permission. Chaque objet a son label ( stocké via xattr sur les fs, rien de spécial ), et un moteur de regle, avec un minimum d'optimisation pour pas faire ramer ( voir les détails sur https://www.imperialviolet.org/2009/07/14/selinux.html ). Donc ne pas l'utiliser pour éviter une backdoor, c'est revenir au système par défaut qui donne beaucoup plus de permissions et , et c'est comme dire que sans firewall, on est plus en sureté.
Retirer un firewall parce que ça fait chier, parce qu'on a pas le temps de le maintenir et que ça a un cout, pourquoi pas, ça se défend. Dire qu'on a pas besoin car il peut y avoir des failles dans le traitement des chaines( genre l7, le super truc qui fait de l'analyse protocolaire ), à la rigueur, mais c'est pas lié au concept de firewall lui même mais au code.
Par contre, j'ai vu personne dire "je retire le firewall car c'est plus sur, j'ai pas de risque de backdoor". Dire pareil de selinux, ça tiens plus du cargo cult qu'autre chose.
Sinon, oui le code de selinux a été audité par les gens de RH avant de l'intégrer ( comme tout ce qui est rajouté dans le kernel de RHEL ), et aussi par le même group de gens qui ont audités tout le reste du kernel sur la lklm ( surtout vu le selinux a mis du temps à rentrer ), et aussi par les gens de tresys.
Ensuite, quand on parle du code de selinux, c'est superbement imprécis. Est ce qu'on parle des LSMs, d'un LSM en particulier, du code en userspace, de la policy ?
Et prendre apparmor, je dirais qu'il y a pas la même couverture fonctionnelle, ni les mêmes fonctions. Le but, c'est pas de charger un LSM pour charger un LSM, mais de voir les menaces, les risques, les besoins tu as et quels solutions tu va déployer. Et pour un utilisateur, garder la solution choisi par le distributeur me semble logique, vu que la plupart dépende d'une politique de régles, soit c'est complet sur un LSMs, soit c'est grossièrement incomplet sur tout les LSMs. Donc le choix se fait plus au niveau de la distribution choisi qu'autre chose.
[^] # Re: Deux idées
Posté par octane . Évalué à 2.
Ca existe encore? C'est pas mort, enterré sous 18 pieds de terre?
http://l7-filter.clearfoundation.com/
derniere info: 2011.
Et puis ça ne fait pas de l'analyse protocolaire, ça fait de la reconnaissance d'appli.
Je cherche un truc qui puisse, sans proxy, faire des règles du style:
iptables -A FORWARD -p tcp --proto HTTP -m match --user-agent "*Internet explorer*" -j DROP
-> Je ne spécifie pas le port, juste le proto, et je matche sur ce que je veux dans le protocole.
Ou des trucs comme
iptables -A FORWARD -p tcp --proto HTTP -m match --server-version -j REMOVE "server-version"
[^] # Re: Deux idées
Posté par Misc (site web personnel) . Évalué à 3.
ce projet, visiblement si. Ensuite, c'est un exemple que les gens connaissent.
ça fait du pattern matching sur les chaines, pour analyser le flux pour reconnaitre les applis, je pensais que ça rentrais dans analyse protocolaire. Ceci dit, à 1h du matin les détails de ce genre m'échappe parfois.
Et sinon, je pense que qosmo a un produit pour toi :)
[^] # Re: Deux idées
Posté par octane . Évalué à 2.
Qosmos fait surtout du logging pour permettre aux gentils gouvernements respectueux des droits de l'homme et de la liberté de pouvoir surveiller les vils pédonazis voleurs de pains au chocolat. Donc bon, c'est bof.
[^] # Re: Deux idées
Posté par Zylabon . Évalué à 3.
Dans l'hypothèse où un logiciel est malveillant, il est plus sûr de NE PAS l'utiliser oui, je l'affirme. Peu importe les sécurités que prétend apporter ce logiciel s'il introduit volontairement une faille.
Imagine, t'as un type qui viens te proposer sa protection en contrepartie il aura le droit de te tabasser quand bon lui semblera. Tu vas dire « ah oui mais il me protège quand même, mieux vaut avoir recours à ses services… » ?
Je passerais sur le grossier « c'est comme dire que sans firewall on est plus en sûreté », non, c'est pas comme.
Please do not feed the trolls
[^] # Re: Deux idées
Posté par Renault (site web personnel) . Évalué à 6.
Sauf qu'il a expliqué que le code a déjà été étudié par des personnes assez compétentes pour s'assurer que le risque était proche de 0. Et mieux, le code a évolué à l'aide de contributeurs extérieurs à la NSA ce qui pourrait boucher accidentellement les éventuelles failles volontaires par modification du code concernée.
Bref, pour moi c'est de la paranoïa.
Pourquoi ? Car je pense que si la NSA voudrait mettre un backdoor dans un logiciel libre pour s'introduire sur des machines il n'aurait pas fait via SELinux pour les raisons suivantes :
-SElinux est officiellement lié à la NSA à l'origine, ce n'est pas discret et il était évident que la méfiance autour du code se serait fait d'où les audits… Ils auraient sans doute fait des contributions à un logiciel en cachant sa provenance pour être discret.
-Ils auraient pris un autre logiciel que SELinux comme Firefox ou OpenSSH qui sont bien plus répandus et dont l'attaque est plus facile car ils communiquent avec le réseau nativement. SELinux c'est une part insignifiante du parc des machines mondiales (et même sans doute des systèmes GNU/Linux).
Bref, si tu as peur de la NSA, plutôt que de supprimer SELinux ou de changer de distributions, coupe ta borne Wifi ou ton câble Ethernet et tu seras sûr et certains de ne pas être espionné par cette voie là.
[^] # Re: Deux idées
Posté par pasBill pasGates . Évalué à 4.
Sauf qu'il a expliqué que le code a déjà été étudié par des personnes assez compétentes pour s'assurer que le risque était proche de 0.
Tu m'excuseras de rire en lisant cette phrase…
N'importe quel composant de taille non-negligeable peut se retrouver avec des failles dedans que personne ne trouvera en revue de code. Si il suffisait d'avoir des gens competents lisant le code, ca se saurait et je serais au chomage.
[^] # Re: Deux idées
Posté par Misc (site web personnel) . Évalué à 2.
ben si tu retires selinux, les applications ont des droits en plus, tout comme le fait de retirer le firewall fait que tes applications ont des droits en plus.
Ensuite, si tu part du principe que le soft est vérolé sans raison, ben le soft est vérolé. Mais tu ne supposes pas que tout est vérolé. En pratique, tu supposes même que la plupart des outils sont raisonnablement non vérolés, et tu tires de la une analyse risque/bénéfice.
Le bénéfice de selinux est tangible, tu peux voir que ça bloque une partie des exploits (http://danwalsh.livejournal.com/10131.html), même si ça bloque pas tout comme le rappelle avec aigreur un des dev de grsec ( qu'on a moins entendu le jour ou grsec n'a pas bloqué un truc).
Le risque de faire tourner selinux serait soit que le système de protection ne soit pas étanche à dessein, soit d'avoir une faille bien caché depuis des années. Le 1 serait facheux, mais la solution n'est pas de pas l'utiliser. Personne ne dit que selinux bloque tout, plutôt le contraire. C'est pas parce que tu as selinux que tu peux avoir root/root comme login/mdp.
Si le plus gros problème de quelques chose est de pas être efficace dans certain cas, alors le retirer ne va pas améliorer la chose.
Et si le risque est "y a une faille caché", il faut bien voir qu'il y a déjà des failles ailleurs dans Linux et que personne ne crie à cause de ça. Et de surcroit, mettre une faille visible de tous dans un noyau au code source ouvert, quand tu sais que tout le monde relie ton code 15 fois, c'est un pari audacieux.
Et je commence à me demander si la NSA n'a pas fait exprès de poster ça de façon visible afin de s'assurer que tout le monde relise le code afin de pouvoir avoir une vérification gratos de son code en vue de l'utiliser pour protéger les SI du gouvernement US. Il faut pas déconner, à la NSA comme partout, les budgets coulent pas à flots, ça reste une administration avec sans doute la même lourdeur et lenteur administrative. Si une méthode d'amélioration de l'efficacité de la bureaucratie avait été mise au point, le reste du gouvernement en bénéficierait depuis longtemps.
[^] # Re: Deux idées
Posté par Anonyme . Évalué à 3.
Il est possible d'imaginer que la NSA decide d'introduire une faille subtile pour pouvoir en profiter ensuite. Mais moi si j'etais la NSA, je ne le ferai pas forcement sur SELinux. Il pourraient tres bien le faire sur un patch quelconque d'une autre partie du noyau, sous un faux nom, celui d'un contributeur qui n'est pas connu pour travailler pour la NSA pour ne pas trop attirer l'attention.
Mais peu etre aussi qu'ils se contentent de paier des chercheurs en securite pour trouver des failles introduites involontairement, avant qu'elles soient publiques, sans avoir besoin d'en rajouter eux meme.
# Moui
Posté par Pascal Terjan (site web personnel) . Évalué à 3.
Oui il y a plein de moyens d'écouter le trafic et c'est le cas sur les grosses fibres depuis des années, et sur les câbles téléphoniques avant ça.
De même, utiliser tor n'empêche pas d'écouter sur le nœud de sortie…
C'est pour ça que
tout leplein de monde utilise du SSL pour HTTP/SSH/XMPP/IRC/… depuis des années.[^] # Re: Moui
Posté par Starch . Évalué à 1.
Moui enfin le SSL ça protège sur le chemin (quand c'est bien fait, que le DNS est fiable, que tu as un moyen fiable de déterminer si le certificat est valide, etc.) ; mais pas une fois à destination, là où il y'a du Windows, du Chrome, de l'Android ou du SElinux…
[^] # Re: Moui
Posté par Artefact2 (site web personnel) . Évalué à 4.
C'est pour ça qu'on a DNSSEC et OCSP stapling.
[^] # Re: Moui
Posté par mazarini . Évalué à 5.
Pas sur que seul le contenu soit intéressant. Qui regarde quoi et qui communique avec qui est déjà une bonne source d'information.
[^] # Re: Moui
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 5.
SSL pour IRC, c'est secure. Surtout pour troller sur des canaux publiques.
# Un lien
Posté par ®om (site web personnel) . Évalué à 10.
http://seclists.org/fulldisclosure/2010/Dec/335
blog.rom1v.com
[^] # Re: Un lien
Posté par dyno partouzeur de drouate . Évalué à 3.
C'est étonnant comme ça a fait peu de bruit à l'époque chez le grand public comparé aux révélation récentes de l'ex-agent américain sur l'écoute généralisée des citoyens.
[^] # Re: Un lien
Posté par Moonz . Évalué à 1. Dernière modification le 28 juin 2013 à 11:43.
Peut-être parce qu’à l’époque la majorité des gens n’étaient pas aussi « connectés » ?
# Audit
Posté par patrick_g (site web personnel) . Évalué à 10.
SELinux a été quand même scruté de très très près avant d'être intégré au noyau Linux. Le fait que la NSA soit à l'origine du code avait provoqué des suspicions et donc pas mal de gens se sont penchés sur le bouzin avant de l'accepter. En plus, même si c'est la NSA qui est à l'origine du projet, le code a été étendu et modifié pendant plusieurs années par des hackers très divers (Red Hat et autres).
Et pour ceux qui n'ont toujours pas confiance il reste Smack, Tomoyo ou Apparmor.
Utiliser cet argument pour prôner une migration vers les BSD c'est juste du FUD.
[^] # Re: Audit
Posté par mazarini . Évalué à 2.
Audité pour vérification, mais (et c'est plus rassurant) étudié pour trouver des failles exploitable par des gens plus ou moins bien intentionnés.
Je ne vois aucune raison que ceux qui cherchent des failles à exploiter n'aient pas chercher du coté d'un soft un peu répandu.
L'utilisation d'une faille pour nuire (au serveur !) permet certainement de découvrir la faille en question.
[^] # Re: Audit
Posté par Misc (site web personnel) . Évalué à 2.
Si tu cherches du code buggué sur du truc peu répandu, c'est tout chaud :
http://blog.azimuthsecurity.com/2013/06/attacking-crypto-phones-weaknesses-in.html
La pile zrtp en question est vachement utilisé, tu pourrais croire que c'est de la sécurité, ça a été relu, et visiblement, pas trop. Mais bon, à part ça, faut se méfier des LSMs bien sur :)
# BSD et Confort.
Posté par Misc (site web personnel) . Évalué à 9.
Moi, je pense que tu devrais passer à du BSD.
Non pas parce que c'est plus sur, moins sur, ou la licence est meilleur ou pas. Ou parce que la NSA a envoyé un patch sur le kernel.
Non je pense que tu devrais car c'est important de connaitre plus qu'une distribution, plus qu'un système libre.
# Backdoor NSA dans un algo de chiffrement ?
Posté par calandoa . Évalué à 4.
Petit exemple des pratiques (soupçonnées) de la NSA : http://www.schneier.com/essay-198.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.