Aris Adamantiadis a écrit 151 commentaires

Ce que j'en pense:
http://securityreactions.tumblr.com/post/52299339625/linux-kernel-devs-reaction-to-complaints-about-silent

Le bug existe: https://bugzilla.mozilla.org/show_bug.cgi?id=215243
TL;DR: Bug fermé comme invalide parce que la demande doit émaner du CA lui-même. CACert ne fait pas la demande car ils savent qu'ils ne respectent pas les conditions d'accès. Le bug n'a pas évolué depuis 2009 on dirait.

Oui effectivement la dernière version de Gimp est native. Par contre le thème s'intègre vraiment très mal dans l'environnement et les boites de choix de fichiers sont pas du tout natives, mais ça marche déjà beaucoup mieux qu'en mode X11.
Aucune idée pour wireshark

Youpie, Wireshark ressemblera enfin à quelque chose sous OSx, pour le moment l'utilisation obligatoire du serveur X rend l'application très moche et à l'utilisabilité moyenne

Je plussoie (comme quoi des fois on est d'accord :)). Si CACert ne respecte pas les critères pour être inclus dans des browsers comme FF,Chrome ou IE, je ne vois aucune raison pour laquelle je leur ferais confiance et les rajouterais en tant que CA.
Et le fait que d'autres CA ont eu leur lot de bavure n'est pas pour moi un argument positif pour CACert, voire même le contraire.
Pour le moment je me contente de rajouter une exception pour linuxfr.org.

Tu trouves responsable l'idée (si on augmente ton principe) de laisser crever des gens alors que tu aurais pu empêcher ça en informant juste la bonne personne, et tu peux dormir tranquille, pas moi. Ils ne sont pas payés pour faire la recherche? Qu'ils ne la fassent pas. Mais si ils trouvent, c'est de leur responsabilité (non légale) d'informer la bonne personne (et si l'upstream s'en fout, tant pis, ils auront fait ta part). Ils n'en n'ont pas l'obligation légale certes, mais cette non obligation n'enlève pas l'idée que ces personnes sont des salopards (sans les guillemets).

Pour reprendre tes propres mots:

Tant que ce n'est pas exploité, ça ne pose aucun problème. Sans compter que la plupart du temps, c'est non exploitable.

Nous parlons aussi du comportement de l'équipe de dev de linux, qui pour toi n'ont rien fait d'irresponsable alors qu'ils ont aussi l'obligation "morale" de prévenir lorsqu'un bug qu'ils ont réparé était exploitable, selon tes critères.

Les risques sont si tu t'attaques au système d'un autre (accès frauduleux genre si tu t'attaques au GIE carte bancaire, il y en a un qui en a fait les frais), ici tu peux t'attaquer à ton propre système, donc le seul risque et de te prendre un procès de toi-même, risque gérable.

Malheureusement il y a un paquet de contre exemples, allant de mecs qui montrent que le DRM d'une solution x est inutile (Dmitry contre Adobe), à des mecs qui montrent qu'il est facile de contourner un antivirus (qui tourne sur ta propre machine). Petite liste disponible ici: http://attrition.org/errata/legal_threats/

Lien pertinent à mon message plus haut: http://blog.trailofbits.com/2009/03/22/no-more-free-bugs/

Ce n'est pas parce qu'elle ne te plait pas qu'elle est puante. C'est un choix. Qui a l'air de plaire.

Le choix ne plait pas, cfr propos de spender (à sortir du contexte grsecurity, son framework ne plait pas forcément pour des raisons techniques.)

Je t'en prie, propose mieux. En vrai, hein, pas en lalalala, pour démontrer qu'il est possible de mieux faire (en plus, tu dis toi-même que les "méchants" scannent les logs GIT, donc ça doit être aussi possible pour les "gentils").
Perso, je constate juste que Linux est sur tous les serveurs ou presque non pas parce que les commerciaux sont doués, mais parce qu'il répond au besoin technique (sécurité comprise, faut voir comparé à d'autres OS).

J'ai expliqué mon point de vue sur les choses à améliorer, suffit de lire. Avoir une vraie team sécurité, des vrais reviews de patches, ne pas considérer la sécurité comme un truc chiant qui ne concerne que les autres.
Linux est sur beaucoup de serveurs, y compris les miens, parce qu'il y a beaucoup de fonctionnalités dedans et que ça marche pas mal. Mais j'aimerais bien avoir un OS dont j'ai la garantie que tous les bugs de sécurité qui ont été trouvés dans le passés soient patchés sur mon système. Je n'ai pas encore cette garantie aujourd'hui.

Je reprend ce bout de phrase, mais l'utilise pour ton "(Je connais personnellement des dizaines de personnes qui le font, moi y compris)".

Je vais ignorer cette basse attaque ad hominem.

Il va falloir que tu m'expliques en parlant lentement : pour quelle raison sans visées illégales cette personne garde secrète ce genre d'info ?
Si c'est un professionnel « propre » de la sécurité, il n'a aucun bénéfice à attendre pour publier. Sinon il risque de se faire doubler, et son CV sera moins bon.
Il faut donc enlever « propre » pour que son attitude soit logique.

Ton commentaire touche à un des points assez sensibles en infosec, qui est le grand débat full disclosure/no disclosure. Beaucoup de chercheurs compétents croient au non disclosure et gardent leurs trouvailles pour eux, au risque de se faire doubler comme tu dis. En résumé, leur raisonnement est le suivant:
- Ils ne sont pas payés pour faire la recherche donc n'ont pas d'obligation de publication
- Les bugs de sécurité sont vu comme des trésors heisenbergiens qui disparaissent lors de la publication. Un exploit 0day, même non partagé, est une sorte de trophée qu'ils conservent précieusement.
- Ils n'ont pas besoin de publier pour étoffer leur CV, partant du principe que le CV ne leur intéresse pas ou qu'ils n'ont pas besoin de publier pour être reconnus
- Le point le plus important: la publication de découvertes de sécurité est une pratique dangereuse. Cela ne s'applique sans doute pas à linux, mais publier en son nom propre (même en suivant les pratiques de "responsible disclosure") expose le chercheur à des ripostes légales. Parfois prendre ce risque gratuitement ne vaut pas le coup.

Vendre des failles de sécurité, c'est la même chose que vendre le code administrateur d'une centrale d'alarme, ou d'une ouverture de porte automobile. Le but est uniquement illégal.

J'ai une opinion différente. Certains hackers considèrent que vendre de l'exploit est non éthique (je pense que sd en fait partie), et préfèrent laisser leur exploit moisir sur le disque dur que le divulguer de cette manière. Quoi qu'il en soit, vendre une faille de sécurité n'est pas similaire à vendre un code d'alarme. C'est vendre la primeur sur un problème de sécurité peut-être connu ailleurs pour laisser une chance aux clients de se protéger à l'avance. Je pense que le raisonnement "vendre des vulnérabilités est forcément illégal" tient du même raisonnement fallacieux que "Si tu utilises de la cryptographie, c'est que tu as des choses illégales à cacher".
Et vu le nombre de vulnérabilités critiques rapportées par ZDI et autres, qui seraient peut-être restées très longtemps non publiées si il n'y avait pas de contrepartie financière, je pense que la monétisation de rapports de vulnérabilité est positif à long terme. Rechercher des vulnérabilités, ça prend du temps et c'est loin d'être gratuit.

Se boucher les oreilles et crier lalalala n'est pas un argument valide. La politique de sécurité de linux est puante et ce n'est pas parce que l'équipe de dev de linux se complait dans leur médiocrité que c'est comme ça que ça doit fonctionner.

Ce genre de personne que tu décris est bien un salopard, pas besoin de mettre des guillemets.
Et non, ce n'est pas standard dans l'industrie de la sécurité, il y en a pas mal qui découvrent des bugs, codent l'exploit pour démontrer aux autres qu'il y a un réel problème, démonstration soit privée (responsible disclosure, la personne attend le patch puis se fais la pub, si ça tarde trop hop en public pour forcer le patch), soit en public lors des meeting de sécurité, et parfois empochent quelques milliers de $ en remerciement, soit un bon gros plaisir sadique de faire du 0-day (irresponsible disclosure).

Désolé de te contredire, le standard dans l'industrie c'est de garder les résultats de recherches privés. sd n'a rien fait de mal en gardant pour lui ses résultats. Il n'a rien publié avant que ce soit connu, il ne s'est même pas plaint que ce soit devenu public. Il n'a rien fait d'irresponsable.
Au contraire, les devs qui ont publié les patches sans faire de review de sécurité sur le bug qu'ils avaient trouvé ont publié un bug de sécurité selon ta vision de l'irresponsible disclosure.

Le développeur ne savait peut-être pas que ça posait un problème utilisable de sécurité. Si il faut faire un CVE pour chaque patch…

C'est un problème de processus. Sur les gros projets (et les petits aussi), chaque bug qui est trouvé et dont on soupçonne des répercussions au niveau de la sécurité doit être analysé par une équipe compétente. Mon petit projet y arrive, pourquoi linux n'y arrive pas ? Parce qu'il n'y a pas d'équipe de sécurité.

C'est à ma connaissance la politique de Linus depuis le début, ton irresponsable a quand même un CV en béton.

Donc d'après toi, puisque monsieur Linus a un meilleur pédigrée que moi, il a toujours raison. Ton argument d'autorité, tu peux le garder. Et bien non, en terme de sécurité, la vision de Linus (Un bug de sécurité = un bug) est totalement irresponsable. Il se moque totalement de l'impact des bugs de linux au niveau de la sécurité et compte sur les autres pour tenter de regarder le backlog et trouver ce qui est urgent à backporter et ce qui ne l'est pas. Linus le dit lui même, la sécurité de Linux c'est pas son problème. Je refuse de prendre des conseils en sécurité de cette personne.
Et ce n'est pas juste moi qui le dit, mais Spender (le mec de grsecurity qui s'y connait "un peu" en sécurité linux) [1] premier hit sur "spender linus security"

Tant que ce n'est pas exploité, ça ne pose aucun problème. Sans compter que la plupart du temps, c'est non exploitable.

Ce type d'excuse est irresponsable. Tu crois que parce qu'un problème est caché sous le paillasson, il n'existe pas ? Il y a des gens qui passent leur temps à inspecter les commits linux à la recherche de bugs exploitables et crois-moi, ils ne réagissent pas comme sd lorsqu'ils trouvent quelque chose. Tant que ce travail ne sera pas fait de manière systématique par l'équipe sécurité de Linux, on aura ce genre de problèmes de manière récurrente.

[1] http://www.reddit.com/r/netsec/comments/18qab0/spender_grsecurity_author_linux_approach_to/ https://lwn.net/Articles/538600/

Je pense qu'on est en train de détourner la responsabilité de ce mini scandale. Le "salopard" en question ne fait que suivre ce qui est standard dans l'industrie de la sécurité, c'est à dire découvrir des bugs, coder l'exploit pour soi et attendre que ça tombe ailleurs. (Je connais personnellement des dizaines de personnes qui le font, moi y compris)
Par contre personne ici pour critiquer les deux raisons principales de la publicité de cet exploit:
1- il y a eu un bug qui permet d'obtenir un local root dans un premier temps
2- Lorsqu'un développeur a trouvé le bug (une écriture en dehors du buffer !!) ils ont corrigé le bug sans même créer un CVE, sans mettre le fix en quarantaine ni suivre la moindre procédure de backporting du patch. Ces personnes sont les véritables irresponsables, car un bug de sécurité a été publié dans la nature sans que le patch ne soit prêt à être déployé.

Rapporter la responsabilité de l'absence de CVE et publication de l'exploit à sd est de la mauvaise foi. La véritable responsabilité, c'est l'attitude totalement autruchienne de l'équipe de dev de linux par rapport aux bugs de sécurité. Et je suis convaincu que ce n'est pas le premier bug de sécurité publié ouvertement dans le git sans qu'il y ait le moindre CVE et backporté dans aucune distribution majeure.

Je suis très content de voir qu'il y a des évènements intéressants dans ma région, surtout sur un tel sujet. Mais prévenir la veille c'est un peu difficile…
Ce genre de dépêche devrait être publiée une ou deux semaines à l'avance pour servir à quelque chose. Ici ça n'a fait qu'alimenter ma frustration de ne pas pouvoir y aller :(

Ne pas l'inviter… Quand on se fait inviter pour parler à une conférence, on ne fait pas la fine bouche sur le type de boisson que l'on accepte (est-il au courant que Pepsi est une boisson propriétaire ?), le nombre de personnes au resto et on ne se nettoie pas les doigts de pieds pendant qu'on parle. http://www.youtube.com/watch?v=I25UeVXrEHQ

Mon avis (et ce n'est que le mien) c'est qu'utiliser les mêmes lois pour les logiciels et pour la musique (et autres oeuvres artistiques) est fondamentalement une très mauvaise idée.
Je pense que leur plan d'action est assez extrême en prévision des négociations nécessaires le jour où ils auront un mot à dire.

Il y a un tas de cas dans lesquelles l'exploitation commerciale est possible:
- La vente de produits dérivés et de produits à plus-value (par exemple vendre quelque chose de plus qui inciterait le consommateur à ne pas aller au P2P mais acheter le DVD, par exemple par un packaging original ou des objets supplémentaires (posters, bouquins d'illustrations, explications complémentaires, …)
- L'exploitation du film dans des conditions "optimales" (salles de concert, cinéma, …) -> le consommateur est prêt à payer pour profiter du bien dans de meilleures conditions.

Dans l'approche du PP, l'oeuvre originale serait une commodité, mais tout ce qu'il y a autour pourrait être vendu pour rentabiliser la création de l'oeuvre. Cela encouragerait les studios à produire et vendre des biens et services de qualité supérieure à ce qui est trouvable dans le P2P (alors qu'aujourd'hui c'est exactement l'inverse). Pourquoi autoriser uniquement le détenteur du copyright à le faire ? Pour éviter que l'exploitation commerciale soit faite par une autre boite sans payer une thune.

Je m'interroge sur le prix que je vois sur amazon : Il est demandé 2.88€.
Sur cette petite somme, combien revient aux auteurs et aux traducteurs ? Je me suis d'ailleurs posé la même question à propos de l'ebook sur python décrit sur slashdot ce week-end.

Petit truc mnémotechnique pour RAID 0 ou 1 : le chiffre indique le nombre de copies de tes données qu'il te reste après un crash :)

Il n'y a aucune difficulté à mélanger allègrement les différentes licences, même si on les mélange, pourvu que ce que l'on diffuse a une licence compatible (et que les licences utilisées soient compatibles entre elles, ce qui est le cas pour les *GPL et *BSD).
Par contre, publier un logiciel libre, le maintenir, créer une communauté et simplement faire une revue du code pour voir si rien de sensible ne sort, ça prend un temps très loin d'être négligeable. Sans parler que la plupart du temps le code interne est tellement sur mesure qu'il sera inutilisable sans modifications ou généralisations.
Publier du libre dans les services publics, cela ne se fait généralement qu'à la demande d'un des développeurs sensible au libre et se fait très rarement sur son temps de travail.

versatilité

Tu voulais probablement parler de polyvalence.

Et c'est toi qui dis que je ne connais rien à la sécurité :) Pour pouvoir fonctionner, ce type d'authentification nécessite que le serveur:
1 Connaisse le mot de passe en clair (par ex toutes les auth basées sur MSchapv2)
ou
2 Stocke un hash du mdp. Mais l'utilisateur ne doit pas réellement connaitre le vrai mot de passe, seulement le hash (-> goto 1). Par ex authentification AD.

1 apporte un effet de bord ennuyeux (mdp stocké en clair), et 2 apporte un autre effet de bord (un hash suffit pour s'authentifier).

Sans parler de tous ces gens rétros qui n'utilisent pas javascript.
Non, le plus sûr c'est d'inclure une checkbox "Je jure être celui que je prétends être" dans le formulaire de login. Ca peut même remplacer le mot de passe.

Une erreur habituelle lors de la gestion de mots de passes est de stocker les mots de passe sous forme hachée simple (hash = md5(password)). Cette forme n'est pas sûre du tout à cause de l'absence de salt (graine) qui rend la constitution de dictionnaires ou rainbow tables triviale. d'où l'utilisation de bcrypt.

Systemtap devrait bien t'interesser, c'est un outil largement inspiré de dtrace mais optimisé pour linux.

Et si je me souviens bien, il y a un port de dtrace pour linux. Je ne suis par contre pas sûr que ce soit intégrable dans linux même pour des raisons de licence.

En continuant à spoiler, l’éternité n'existe plus et n'a jamais existé, et donc il n'y a aucune raison qu'il y ait une référence à l’éternité dans le futur.
Mais comme le dit ploum, Asimov écrit lui-même que les raccords ne sont pas cohérents (Il y a même des incohérences dans la série fondation, qui n'a d'ailleurs pas été écrite d'une traite).

Ça ne change rien au fait que j'apprécie beaucoup l’œuvre d'Asimov.
Je déplore les films "inspirés de Asimov" ("I,Robot" au hasard) qui se basent sur le scénario de "Frankenstein" où les robots se rebellent contre l'humanité.

Je dirais même qu'il exagère, quitte à insérer des passages incompatibles entre eux. (Sans rentrer dans un spoiler, il est impossible que les gens de Gaia dans "terre et fondation" connaissent l'éternité, parce l'éternité n'a jamais permis les vols galactiques).

Mais on retrouve à chaque fois le même thème : les civilisations qui se font chouchouter (via l'éternité ou via les robots) périclitent et vont à leur perte.
Ce qui n'est pas tout à fait faux mais reste à démontrer pour une société informatisée comme la notre.