Le 20/03/2024 à 20:58, neo futur a écrit :
Bon, je ne suis pas intervenu dans ton troll LE mais je me dois d intervenir su celui ci .
Merci d'intervenir ; je suis intéressé par toute discussion constructive qui pourrait faire progresser mes connaissances, surtout lorsque c'est fait sans agressivité.
Non, je n'ai jamais eu l'intention de troller quoique ce soit. Bien au contraire, je n'imaginais pas que suggérer sur FrsAG qu'exécuter un processus en root ne serait pas une bonne pratique au niveau sécurité puisse déclencher une telle réaction.
La tu attaque l open source. Je suppose que tu n es QUE sysadmin et pas du tout codeur ? ( ici un sysadmin de 50 ans qui est aussi développeur C, et j en passe )
Pas du tout, je "n'attaque" pas l'open source et je suis surtout "codeur". Je pense simplement que ce n'est pas le fait que le code soit "open" qui le rend plus sûr. Par contre je redis qu'il faut qu'il soit open pour être libre.
Oui avec l open source il est facile de decouvrir une faille !
Ah, au moins un point où on est presque d'accord. Il est /plus/ facile de découvrir une faille en analysant un code que l'on peut lire qu'un code qu'on ne peut pas lire :-)
DONC :
- Il est tres probable que la faille sera decouverte RAPIDEMENT ,
C'est là où je ne te rejoins pas. Par exemple, à voir comment est codé openssh cela ne me parait pas du tout évident d'y découvrir rapidement un bug. Ok, openssh est complexe mais en plus son codage est tordu. Pourquoi rajouter une complexité artificielle au traitement d'un problème déjà complexe ?
Pour mon premier travail salarié, j'ai eu pour mission de maintenir un programme d'affichage et de traitement d'informations financières en temps réel. Il était profondément buggé, son concepteur étant plus porté sur le fun que la rigueur. Mais parmi les innombrables bugs, il y en avait un qui n'était pas complètement de sa faute. La mémoire allouée au processus principale de ce programme enflait progressivement au point de le planter ; cela faisait désordre dans les salles de marché. Il m'a fallu un temps considérable pour trouver l'origine du problème. J'ai dû écrire une surcouche aux malloc()/free() pour tracer les fuites. Il y en avait une particulièrement inattendue sur la fonction time() qui manquait manifestement de free(). Le logiciel affichait les heures des principales places boursière du monde entier et la fonction time() était appelée plusieurs fois chaque seconde… Je garde de cette expérience une profonde aversion pour la maintenance d'un code écrit par un autre et une idée précise de la difficulté de cette tâche.
car plein de gens qui sont aussi paranos que toi et moi, vont jeter un oeil au code, et les plus autiste d entre nous y passeront peut etre plusieurs jours ( ou nuits ),
J'ai un gros doute sur le fait que plein de gens (bienveillants) passent du temps à chercher des failles dans les logiciels open source. Je sais par ma première expérience évoqué ci-dessus que c'est un travail très compliqué. Qui les payerait pour cela ? Mais je ne demande qu'à me tromper ; ce serait une bonne nouvelle. Par contre l'utilisation massive de logiciels open source me semble un facteur bien plus rassurant sur leur fiabilité. Cela multiplie les opportunités de remarquer des failles (ou des bugs).
dans le cas d un truc que tu CROIE .devoir faire tourner en root.
Ce n'est pas une question de croyance, c'était juste un constat. Mon installation standard de cerbot aboutissait à un processus lancé par root.
- Le mec qui voudrait mettre une backdoor dans un logiciel choisira la
boite noire, car si il a un minimum d intelligence, il sait que sa backdoor sera vite decouverte et qu il perdra au minimum sa reputation, et au maximum . . . beaucoup plus.
Il n'y a pas que l'insertion volontaire d'une faille ; elle peut s'y trouver à l'insu du codeur ; cf. le bug de la fonction time() évoquée plus haut.
DONC :
- inserer volontairement une backdoor dans un logiciel FOSS est
tellement risqué que c est rare.
AU PIRE :
- parfois une faille ou une backdoor se retrouve dans un logiciel open source
Oui.
- elle est decouverte 1000 fois plus vite que dans une boite noire.
Encore faut-il que ce soit pas découvert par un pirate :-)
- res peu de gens , voire aucun, se feront pirater par cette faille open source.
- le probleme sera réglé tres rapidement pour les milliers d autres
utilisateurs qui se seraient fait pirater si cette backdoor etait dans une boite noire.
De toute évidence je ne partage pas cette conviction, voir plus haut.
EXCEPTION : des gens qui ont de très gros moyens, comme par exemple la N SA, sont capables de t' inventer des backdoors multi niveau très complexes et quasiment introuvables, car elles n' existent pas à première vue.
Il y a aussi eu un concours organisé pour ce genre de sport : http://www.underhanded-c.org/ ; tiens c'est marrant, le lien https ne fonctionne pas pour ce site :-0
depuis 30 ans je n ai vu personnellement passer qu une seule faille de ce genre : https://grsecurity.net/~spender/exploits/exploit2.txt et ca date ( en gros ) de l epoque du hard fork agressif de gcc 2.95.2 par redhat.
/* super fun 2.6.30+/RHEL5 2.6.18 local kernel exploit in /dev/net/tun A vulnerability which, when viewed at the source level, is unexploitable! But which, thanks to gcc optimizations, becomes exploitable :) Also, bypass of mmap_min_addr via SELinux vulnerability! (where having SELinux enabled actually increases your risk against a large class of kernel vulnerabilities) */