Batchyx a écrit 1261 commentaires

Le jour ou quelqu'un annonce une vulnerabilite et qu'un patch n'est pas pret. Ta grand-mere, ta tante, ta fille adolescente, ton grand-pere, etc… ils se protegent comment ?

De la même manière que si elle n'était pas annoncée: Ils peuvent pas. Ou alors si, ils peuvent: il n'ont qu'a pas utiliser un système troué par la pluie.

Ah oui, ils n'en ont aucune idee, ils ne peuvent rien faire, ils ne seront meme probablement pas au courant qu'ils sont en danger.

C'est encore pire si la vulnérabilité n'est pas annoncée, puisque même toi tu ne peux pas les protéger. Celui qui annonce la faille n'est pas forcement le premier à l'avoir découverte.

Le full-disclosure c'est un truc pour les adolescents boutonneux qui ne connaissent pas grand chose au monde reel et pour les petits frustres qui se croient rebelles, c'est a peu pres tout, aucune valeur pour la population en general.

Moi je préfère que les adolescents boutonneux et les petits frustrés fasse du full disclosure plutôt qu'ils s'amusent à garder ça pour eux ou à vendre ça à des gens moins sympa. Parce que si tu crois qu'ils sont assez cons pour aller contacter les auteurs tu te fourre le doigt dans l'œil. Tout le monde à retenu la leçon de Serge Humpich, même les non-informaticiens.

iptables n'intervient pas dans les bridges. Il intervient uniquement pour les communications IP entre l'AP et le reste du monde.

ufw bloque peut-être des choses avec arptables et/ou ebtables, mais sinon rien ne devrai changer.

Par contre, ce que je trouve troublant, c'est que les terminaux puisse faire du SSH vers un autre hôte du réseau: ça veut dire qu'ils ont une communication bi-directionelle avec cette machine, pourtant elle ne peut pas les contacter. Il n'y aurai pas un firewall planqué dans le switch/routeur ou un firewall logiciel sur les terminaux ?

Est ce qu'on peut enfin créer un ArrayList avec des int à l'intérieur ?

Le problème avec Avahi, c'est que Lennart l'a complètement abandonné, du jour au lendemain. Et toutes les assurances foireuses qu'on vendait aussi avec systemd du genre "mais oui si Lennart disparait il y aura d'autre mainteneur" n'ont pas tenu, parce qu'ils se sont tous barrés aussi.

Alors du coup on peut pas faire de news dessus, c'est pas drôle.

Sous linux, ifconfig (tout comme route, netstat, vlanconfig, ect …) est complètement déprécié, depuis le noyau 2.4 au moins. Utilise ip à la place. Pour voir tes ip et tes interfaces, utilise ip a (abréviation de ip address) La sortie est plus courte et donne plus d'informations utiles (rien à faire de l'irq de ta carte réseau filaire). Pour ta table de routage, utilise ip r (abréviation de ip route).

(et j'en déduit à la présence de mon.wlan1 que ta version d'hostapd et/ou de ton noyau est peut-être un poil ancienne)

Vire l'adresse IP fixe sur le dongle wifi: Elle ne sert strictement à rien, surtout si les autres machines n'ont pas de route pour cette adresse.

Poste ta configuration, parce que normalement, ça devrai déjà marcher. Si tu fait un bridge (niveau 2, donc avec une option bridge= dans hostapd, et ton interface filaire dans le même bridge), alors n'importe quel autre poste devrai pouvoir contacter tes clients. Si ce n'est pas le cas, c'est sans doute un problème de routage chez les clients/postes, mais à priori, si les terminaux obtiennent leur IP depuis le même routeur que les autres, ils devraient avoir le même préfixe.

Après, il reste le point d'accès. Un bridge n'a normalement pas besoin d'une adresse IP ou de tables de routage ou de règles iptables (qui seront de toute façon ignorées, pour un bridge, faut utiliser ebtables).

Si tu veux quand même que ton AP ai une IP et puisse communiquer avec les terminaux, il faut qu'il fasse du DHCP sur le bridge (et pas sur les interfaces qui font partie du bridge). Il devrai alors pouvoir communiquer avec toutes les machines du réseau, terminaux comme les autres postes.

Une des erreurs que j'ai déjà fait quand je mettait en place un bridge, c'est d'avoir des adresses IP et/ou des règles de routage sur des interfaces qui font partie du bridge, plutôt que sur le bridge lui-même.

Si tu n'a pas ajouté d'option ap_isolate, hostapd n'isole pas les clients.

La solution la plus simple pour toi serait de reproduire le plus fidèlement possible la situation dans lequel ton programme est quand il plante. Remplace ton programme CGI par un script qui affiche le répertoire courant, les uid/gid du processus, les capabilities/contextes/autre machins (si ton serveur en utilise), toutes les variables environnement. tout les fd ouverts (ls /proc/$$/fd -l), puis reproduit ces conditions pour exécuter ton programme. Si ça marche, y a effectivement un problème. Mais souvent ça marche pas ;)

Une autre solution qui m'a bien aidé, c'est de wrapper mon CGI pour qu'il soit lancé avec valgrind --log-file=/tmp/log. Pour les bugs que valgrind trouve en deux secondes, c'est idéal. Après tu l'oublie jusqu'au moment ou ton programme plante encore et ou tu te rend compte que tu à déjà la trace valgrind ;)

Une autre solution que j'ai pas eu besoin d'essayer, c'est de wrapper avec gdbserver au lieu de valgrind: ton programme va attendre en tâche de fond jusqu'a que gdb s'y connecte. Pour avoir utilisé gdbserver par ailleurs, je préfère ne pas avoir à l'utiliser, mais bon…

Et pourquoi utiliser la pile TCP du noyau ? Tu pourrai la recoder aussi…

Est ce que je dois lister toutes les IP et définir les routes ainsi?

… Oui.

Est ce qu'il existe une autre méthode?

… Non.

En fonction du protocole, une solution propre serait d'utiliser un proxy.

Ta connexion est certainement pas une connexion à Internet, mais un truc salement verrouillé qu'ils osent appeler "Internet".

Ton seul salut est l'utilisation d'un VPN

En anglais, "manger", c'est un mangeoire

Un mangeoire à réseau, c'est pour que les autres viennent mangent mes paquets ?

Pourtant y a des gens qui mettent NetworkManager dans l'initrd, et qui écrivent même des patchs noyau (foireux, mais c'est une autre histoire) pour rendre ça plus simple. Donc dire qu'il y a besoin de tout recoder from stratch pour faire quelque chose dans l'initrd c'est du bullshit.

Sinon moi j'aurai bien envie d'avoir du réseau dans l'initrd, mais pour utiliser une conf que même NetworkManager ne supporte pas, alors que la fonctionnalité date des noyau 2.4.

Faut pas utiliser un const_cast quand on en a pas besoin. const_cast permet de passer du pas-const à du const, or t'a pas envie de permettre ça, même lorsque tu caste du pas-const en const.

Non, une simple conversion implicite suffit, et c'est plus lisible:

const A& me = *this;
return me.mean();

C'est vague.

"Une librairie pour du réseau", ça veut pas dire la même chose pour tout le monde.

Pour faire du réseau, la plupart des applications ont besoin :

• D'une couche de "sérialisation": traduire des structures internes en une série d'octet indépendant de la machine qui peut se balancer sur le réseau
• Une couche de gestion du protocole: Tu a bien une idée du protocole que tu veux mettre en œuvre. Si tu à des états, il va falloir les gérer. Si tu réutilise un protocole existant, ça te fera moins de boulot.
• Une couche de session: Qu'est ce qui se passe quand on se connecte et déconnecte. Peut potentiellement aussi gérer l'authentification, le chiffrement …
• Une couche de transport. Soit un protocole de transport existant suffit (tcp, udp, sctp, dccp … voire HTTP, XMPP, ect…), soit il faut se greffer dessus. Il faut aussi prévoir une couche de transport plus classique si tu veut pouvoir passer à travers des firewall néo-nazis. La couche de transport peut être soit dans l'OS, soit dans une bibliothèque.
• Une couche d'abstraction de l'API de l'OS, même si les API réseaux sont un tant soit peu normalisés dans des RFC
• Une gestion d'E/S multiple, soit à coup de poll/select, soit à coup de thread, ou autre. Viens souvent avec la couche d'abstraction, mais pas toujours.

C'est quoi que tu veux exactement ?

Dans la norme USB 2, Le logo USB doit être présent sur la partie haute du câble, et les ports doivent être orientés tel que le logo USB soit "visible pendant le branchement".

Si ce n'est pas le cas, quelqu'un ne respecte pas la norme USB ou ne tiens pas le périphérique dans le bon sens ;)

Oui fin le porn c'est la version soft du truc honteux. Il y a aussi le fait, dans certains milieux, d'être gay, d'avoir le sida, d'être malade mental, de fréquenter des néo-nazis, d'être de la même famille qu'un dictateur sanguinaire …

Alors oui, si les gens pouvaient être plus intelligents, ça serait plus simple. Mais déjà qu'on à du mal avec du simple racisme, c'est pas gagné…

Donc, je peux prendre un script Debian et le faire tourner sur Red Hat vu qu'il y a un standard ?

Tu peux prendre un script LSB et le faire tourner sur une distribution LSB.

Si quelque chose ne marche pas, tu peux examiner la conformité du script et de la distribution et nommer les coupables. C'est ça l'avantage des standards.

systemd n'a aucun standard. C'est dommage, parce que qui dit standard, dit au moins qu'il y a plus d'une personne qui à réfléchit au truc. Du coup si je fait une réimplémentation de l'API systemd, qu'un programmeur développe un truc qui marche avec mon implémentation mais pas avec systemd, on ne sait pas de qui c'est la faute.

Ce n'est persistent, c'est justement ce que permet l'API systemd.

Ce n'est persistent avec systemd que si tu utilise son API. Le noyau en a rien à faire de systemd, et va autoriser n'importe qui à changer le hostname à travers sethostname.

Il y a tant de chose à dire aujourd'hui sur [gs]ethostname() et des considérations modernes, comme le fait qu'en 2013 un nom d'hôte à un ou plusieurs mappings vers zéro ou plusieurs adresses IP, et qu'une machine à zéro ou plusieurs adresses IP. Qu'un programme moderne digne de ce nom devrai faire une résolution inverse sur l'IP locale effectivement utilisée pour avoir le nom d'hôte. Si on voulait tout remettre à plat pour le plaisir, on aurai pu faire ça proprement.

Mais non, c'est tellement mieux de rester dans le passé.

Toi, tu généralises aux autres (alors que la, il n'y plus aucune légitimité à le dévoiler).

Oui je généralise. Parce qu'on peut faire tomber pas mal de monde avec du porn, pas uniquement des puritains.

Et s'ils n'y avait que le porn comme activité honteuse…

Dans les faits, je trouve que les défenseurs du Bt ont en eux soit une mauvaise foi frappante, soit des convictions anarchistes ou ultra-libérales qu'ils essayent de cacher. Personne n'a jamais réussi à démontrer un quelconque intérêt à rendre intraçable les transactions légales.

Tu viens de fournir toi-même la réponse à ta question: Ça sert à tout ceux qui ont des choses à cacher. Des choses honteuses qui peuvent potentiellement nuire à leur réputation dans certains milieux, mais qui sont parfaitement légales.

Ces gens là n'ont pas envie que d'autres sachent qu'ils achète des biens ou des services honteux ou financent des organisations honteuses.

On sait déjà que la NSA espionne des opposants politiques pour savoir s'ils regardent du porn pour les discréditer. Mais ils pourraient très bien examiner les relevés de leurs comptes bancaires à la recherche de transactions vers des sites pornos. Surtout que l'historique est conservé plus longtemps.

Ta banque va voir tes mouvements de 500 000 €. Si l'état s'en rend compte, il peut te demander des explications.

Et vu que le système est contrôlé par les banques, tu pourrai très bien mettre des limites sur les transactions.

Quel standard existe pour l'init actuellement ?

LSB.

Quel standard existe pour le changement d'hostname ?

LSB et la commande hostname. Sachant que la vision ou une machine n'a qu'un seul hostname est … un peu dépassée.

Tu veux bien parler de la liberté de frauder, de ne pas payer ta part à la société?

On veut la liberté de faire des transactions anonymes, pas de planquer de l'argent.

Bitcoin ne fait pas ça. Bitcoin rend les transactions publiques mais les comptes anonymes. Il faudrai l'inverse: des transaction dont le montant est connu de ta banque mais ou l'émetteur ou le destinataire n'est pas connu, ou alors uniquement par un hash salé, ce qui permet de te justifier auprès de l'état si il est pas content.

Mais bon, ça risque pas d'arriver vu le conservatisme des banques et de l'état et les difficultés pour implémenter ça de manière sécurisée. Tant pis, les marchands auront pas mon argent.

… Parce que SMTP est un standard qui à été formalisé, publié et largement reconnu. Donc tu peux changer d'implémentation quand tu veux.

Alors que Systemd ne respecte aucun standard et a une API qui contient "systemd" dans le nom.