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)
*/