MicroBSD

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
6
sept.
2002
OpenBSD
MicroBSD est un noyau BSD qui est conçu pour être peu gourmand en mémoire et sécurisé. Il possède néammoins un nombre important de fonctionalités (firewall, détection d'intrusion, VPN, SMTP, WWW, DNS, FTP, ...). En outre, il existe pour un nombre conséquent d'architectures (x86/Alpha/Sun/PPC). On peut aussi ajouter que son installation semble aisée (voir l'article sur BSD Newsletter). Bref, c'est le système idéal pour vos passerelles et firewalls!


Sur la page du projet, j'ai même vu qu'ils étaient en train d'implémenter un système MAC (Mandatory Access Control) comme dans Linux SE. Ce qui permettra de résoudre convenablement le problème des 'buffer overflows', entre autres.


Un système à suivre de près, donc.

Aller plus loin

  • # Buffer overflows ...

    Posté par  . Évalué à 10.

    Ce qui permet de résoudre convenablement les problèmes de buffer overflow c'est de programmer proprement. Ça veut dire bien réfléchir et bien auditer son code si on est vraiment obligé d'utiliser un système incapable de gérer la mémoire tout seul et sinon, dans tous les autres cas, de coder dans un langage/environnement sûr.

    <troll>
    Pourquoi se faire chier avec du C quand on a du java, du caml, du python ou autres ? Pourquoi pas de l'assembleur tant qu'on y est ?
    </troll>

    Bref, troll à part, les pis-aller qui limitent la casse en mettant les logiciels en cage ne résolvent pas le problème de buffer overflow, juste les symptômes.

    • [^] # Re: Buffer overflows ...

      Posté par  (site web personnel) . Évalué à 10.

      Je ne connais pas encore bien Linux (conversion en cours …).
      J'ai bien compris, le sens du "<troll>" ...
      Mais pourquoi, si tu penses que l'usage du C y est pour quelque chose, dois-tu prendre cette précaution pour l'exprimer ?
      Est-ce du fait que les alternatives dont tu parle sont "hors de prix" (performances) ?
      Je programme beaucoup en C++, et j'ai l'impression de pouvoir résoudre beaucoup de problèmes, plus facilement et avec plus d'élégance que ce que je pourrais faire (moi) en C. Il s'agit souvent d'exploiter les mécanismes "orientés objet" et d'exceptions et les template.
      Je commence à peine ma reconversion (MSFT/Win32 -> GNU/Linux) et j'ai l'impression que le C++ pourrait bien apporter beaucoup sans pénaliser à outrance en terme de performance.

      • [^] # Re: Buffer overflows ...

        Posté par  . Évalué à 8.

        le MAC ca permet de limiter les effets d'une attaque réussie sur les dépassements de tampons.

        Effectivement, ca ne change rien au fait que le code puisse être un code de merde (ce qui n'est pas le cas de BSD semble t-il) écrit dans un langage médiocre (ce qui semble tout de même être le cas).

    • [^] # Re: Buffer overflows ...

      Posté par  . Évalué à 10.

      Dit MicroBSD, c'est pas un fork d'Open suite à un problème de licence dans le code de flitrage ?

      (Tu dois savoir çà jyb ;p)

      • [^] # Re: Buffer overflows ...

        Posté par  . Évalué à 10.

        Je t'avouerais que je n'en sais rien ... je score à -10 les trollpolitik dans les mailing-lists en ce moment.

        Mais bon, à regarder comme ça, on dirait un merge Open/Free + patches extérieurs bien dégueulasses. Surtout que des solutions plus propres que ces patches ont déjà été proposées par les systèmes d'origine (genre systrace pour OpenBSD en fait).

        Rien de neuf, en fait. Un truc novateur dans le domaine de la distro simple et sûre ce serait de porter Linux/BSD/Whatever sur les petits routeurs Zyxel/Netgear qui sont de vraies passoires avec leur firmware d'origine. Ou même de faire un nouveau firmware libre, tiens.

        Mais bon, hors-sujet ... -1

        • [^] # Re: Buffer overflows ...

          Posté par  (site web personnel) . Évalué à 8.

          Un truc novateur dans le domaine de la distro simple et sûre ce serait de porter Linux/BSD/Whatever sur les petits routeurs Zyxel/Netgear qui sont de vraies passoires avec leur firmware d'origine.

          Je vote pour, j'ai pas confiance en un firmware obscur dont les sources sont cachées.

          Mais as-tu des preuves solides que ces merdes sont bien des passoires ?

          • [^] # Re: Buffer overflows ...

            Posté par  . Évalué à 4.

            Bugtraq. Plus les outils de script-kiddies pour DoS les bidules en moins de deux.

            Et il y en a un parc énorme de ces machins-là.

    • [^] # Re: Buffer overflows ...

      Posté par  (site web personnel) . Évalué à 10.

      Ah, un troll C, ça nous manquait.

      Personne ne t'empêche d'écrire un noyau en python ou en java, tu sais. Simplement, dans la vraie vie, il y a des applications pour lesquelles le python et le java sont faits, et des applications pour lesquelles ils ne sont pas faits.
      Si tu veux faire un système d'exploitation ou un logiciel de calcul en autre chose que du C, tu vas sûrement devoir inventer un nouveau langage, qui aura très probablement les mêmes inconvénients que le C.

      • [^] # Re: Buffer overflows ...

        Posté par  . Évalué à 10.

        Je ne parle pas de l'OS. C'est un des cas où l'on est presque obligé de faire du C ou autre langage bas-niveau. En plus, sur un système centralisé, les MAC ne feront rien ou presque pour les buffer overflows du noyau.

        Je parle d'un foultitude de serveurs qui pourrait être soit mieux écrit, soit écrit dans un langage/environnement évitant au maximum les problèmes de buffer overflows. Certes, les MAC sont un de ces environnements quelque part mais bon, c'est un peu trop « après coup » à mon goût. Ça conserve toutefois son utilité mais ce n'est pas une manière de résoudre convenablement le problème des buffer overflows.

        Je n'ai rien contre le C en soi, j'ai contre le C utilisé là où il n'est pas adapté, juste parce que quelqu'un a dit un jour que « le C c'est bien, tout doit être en C ».

        Et perso je pense que pas mal de serveurs seraient bien moins pénibles à maintenir de manière sûre (c-à-d sans nouveau bugs apparaissant à chaque patch) si ils étaient développés dans un langage/environnement de plus haut niveau que le C comme Erlang ou autre.

        Après c'est une question de choix : vaut-il mieux gagner 2% de perfs en échange de beaucoup d'instabilité ? Ça dépend.

        • [^] # Re: Buffer overflows ...

          Posté par  (site web personnel) . Évalué à 10.

          Bon, comme ça je suis plus d'accord.
          Le problème, c'est qu'on ne gagne pas 2 % de perfs. Les performances requises pour un Apache sur un serveur chargé ne peuvent être assurées que par le C, au point de devoir coller quelques routines dans le noyau pour aller plus vite. Le gain réalisé en faisant du C est considérable, et en se restreignant à des règles de codage strictes, les inconvénients que tu cites sont fortement diminués.

          De même, dans le domaine de la simulation numérique, tu ne peux pas te permettre de bouffer 50 % de mémoire en plus et de perdre en performances.

          Enfin, l'utilisation d'un langage plus haut niveau, qui est censé te protéger (entre autres) des débordements de tampon, ne te met pas complètement à l'abri de failles, en particulier à cause des bugs du compilateur ou de l'interpréteur. Et ces failles-là sont certes plus rares, mais elles sont beaucoup plus difficiles à traquer.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 0.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Buffer overflows ...

              Posté par  (site web personnel) . Évalué à 4.

              Bah désolé, mais la simulation numérique, j'en fais pas mal, et je connais le Fortran et le C, alors autant te dire tout de suite que le Fortran est complètement dépassé dans ce domaine. Tu mets 3 fois plus de temps à écrire le même programme, la gestion de la mémoire est inexistante, les fonctions intégrées sont complètement foireuses et il faut aller taper dans des bibliothèques à 2000 $ la licence, et ne parlons même pas des performances...

        • [^] # Re: Buffer overflows ...

          Posté par  (site web personnel) . Évalué à 4.

          Bonsoir,

          [Code plus maintenable avec le langage Erlang]

          Quel est le volet que ça résoud exactement ?

          Pour moi le plus gros problème semble être au niveau des tests de validation et des spécifications. Pour le choix du langage, dès qu'on a
          - du typage;
          - des pointeurs de fonction;
          - un préprocesseur correct (et/ou des templates);
          on arrive à faire le boulot sans trop souffrir et c'est plutot secondaire.

          PS: c'est la première fois que je vois un troll dans un CV: C ou Perl => !orienté objet :o)

          --
          Ueimor

          • [^] # Re: Buffer overflows ...

            Posté par  . Évalué à -2.

            Dès qu'il y a des pointeurs, il y a tout ce qu'il faut pour se tirer dans le pied.

            Sinon, je ne comprends pas ton PS. Quel CV ? Si tu parles du mien, oui, j'ai mis C et Perl en tant que langages impératifs. Bien sûr, on peut être orienté objet avec n'importe quel langage (assembleur y compris, ceux qui ont eu un certain K.P. comme prof à Nancy savent ce que je veux dire) mais le langage n'est pas orienté objet pour autant, juste la méthode (pour Perl c'est négociable).

            Bref, blabla perso -> -1

            • [^] # Re: Buffer overflows ...

              Posté par  (site web personnel) . Évalué à 4.

              > Dès qu'il y a des pointeurs, il y a tout ce qu'il faut pour se tirer dans le pied.

              La position debout est également casse-gueule les premiers mois. On ne vit néanmoins pas à quatre
              pattes bien longtemps.

              Je n'ai pas été clair: en quoi Erlang (ou un autre langage que le C ou X ou Y) facilite-t-il la maintenance ?
              Ou, pour ce qui me semble le plus pénible/couteux au niveau maintenance: qu'est ce qui lui permet
              d'être plus économique pour les volets spécification et validation ?

              --
              Ueimor - Cousot Ru13z

              • [^] # Re: Buffer overflows ...

                Posté par  . Évalué à 0.

                Il y aurait bien une technique qui permettrai d'éviter les buffer overflow (du moins en partie, pas tous) même lorsque le langage a des pionteurs. C'est par l'analyse statique et l'interpretation abstraite (on combine les deux méthodes).

                Mais, ça il ne faut pas compter trouver des gens ici qui aient une quelconque connaissance dans ce domaine (n'est-il pas ?). :-)

                --
                Alan_T - Cousot Ru13z aussi

                • [^] # Re: Buffer overflows ...

                  Posté par  . Évalué à 2.

                  C'est par l'analyse statique et l'interpretation abstraite (on combine les deux méthodes).

                  Au lieu de faire ton malin avec ta dernière phrase, tu pourrais expliquer en quelques phrases de quoi il s'agit...

                  • [^] # Re: Buffer overflows ...

                    Posté par  (site web personnel) . Évalué à 4.

                    De façon très schématique on établit des correspondances entre les composants du langage
                    source et des opérations mathématiques qui permettent de garantir une évaluation d'un graphe
                    associé à celui du programme en une durée limitée.
                    Suivant la correspondance choisie, on obtient des indications sur tel ou tel type de propriétés du code.

                    Après c'est Google/Cousot.
                    Les articles de 76 sont accessibles avec un bagage mathématique minimal (interdit aux moins de 16 ans :o) ).

                    --
                    Ueimor

                    • [^] # Re: Buffer overflows ...

                      Posté par  . Évalué à -3.

                      Il suffit juste de comprendre ce qu'est une correspondance de Gallois ! ;-) Hop, -1, parceque je fais encore mon malin.

      • [^] # Re: Buffer overflows ...

        Posté par  . Évalué à 4.

        Evidemmment, qui c'est qui marche dedans ?

        En replaçant les balises troll, pour éviter de relancer les polémiques entre langages (c'est sale, c'est propre, c'est robuste, c'est adapté à...), l'argument de JyB, c'est que ce n'est pas en plaçant des garde fous autour du trou que tu limites au mieux les accidents. Ce qu'il faut, c'est reboucher le trou.

        Là où est le troll, c'est que le C permet d'écrire du code très sale, probablement plus facilement que beaucoup d'autres langages, et que les conséquences de cette légèreté sont catastrophiques, justement et surtout parce que, à tort ou à raison, le C est LE langage système...

        -1 parce que l'on trolle HS.

        • [^] # Re: Buffer overflows ...

          Posté par  (site web personnel) . Évalué à 3.

          Le tort est à mon avis dans ceux qui programment comme des porcs. Avec des règles de programmation strictes, les seuls problèmes que j'ai en C sont dus à des erreurs de syntaxe.

          Donc je suis d'accord, il ne devrait pas y avoir besoin de tels garde-fous, mais d'une part, une sécurité supplémentaire n'est jamais à négliger, et d'autre part, le code crade existe, et tout réécrire, c'est long.

        • [^] # Re: Buffer overflows ...

          Posté par  . Évalué à 6.

          le C permet d'écrire du code très sale, probablement plus facilement que beaucoup d'autres langages

          Disons que comme le compilateur C ne génère pas de code qui contrôle les dépassements de tableau ou de mémoire (comme ADA par ex), on peut facilement tout saloper.

          Par contre, en codant avec certaines règles, on peut totallement éviter les dépassements mémoires, qui viennent quasiment toujours des strcpy et sprintf. J'ai 100% confiance dans mon code par exemple. On peut aussi développer une petite lib comme Daniel Bernstein pour qmail, pour gérer les chaînes sans soucis.

          • [^] # Re: Buffer overflows ...

            Posté par  (site web personnel) . Évalué à 2.

            Je me pose en personne bete et naive.

            Si c'est si simple pourquoi on trouve encore de temps en temps des failles ? et meme dans des softs tres répendus, prévus pour la sécurité et audités (type ssh ssl et autres)
            C'est bien que ... les problemes sont toujours possible meme quand on fait trs attention et qu'un paquet de gens vérifient derriere toi.

            Meme en ayant confiance à 100% dans son code (AMHA c'est une erreur car il doit bien y avoir des bugs qu'on trouve dans des codes certifiés à 100% par leur auteurs) quel mal y a t'il a chercher un langage qui rend impossible (ou tres difficile) les erreurs ? c'est tout benef non ?

            • [^] # Re: Buffer overflows ...

              Posté par  . Évalué à 5.

              Si c'est si simple pourquoi on trouve encore de temps en temps des failles ?

              Oui je sais, c'est d'autant plus choquant quand on trouve des failles dans des programmes censés être très vérifiés comme SSH et SSL. A mon avis, c'est que ces programmes n'ont pas été bien vérifiés, et que des contributeurs pas "top niveau" ont bossé dessus.

              Pour parler de code sûr à 100%, il y a celui de QMail dont l'auteur a promis 500 dollars (et un LUG 1000) à celui qui y trouverait une faille. On n'en a pas encore trouvé, depuis plusieurs années. Autant il est difficile d'avoir zéro bug, autant on devrait pouvoir éviter les trous de sécurité.

      • [^] # Re: Buffer overflows ...

        Posté par  . Évalué à 2.

        >Il y a des applications pour lesquelles le python >et le java sont faits

        Non java c'est fait pour faire des prototypes
        Des applications surement pas

        • [^] # Re: Buffer overflows ...

          Posté par  (site web personnel) . Évalué à 3.

          Si tu veux partir dans un troll Java, ça va me plaire, je suis le premier à penser que ce n'est qu'un effet de mode.

          M'enfin bon ça n'empêche pas qu'à la base Java a été fait pour réaliser un certain type d'applications.

          • [^] # Re: Buffer overflows ...

            Posté par  . Évalué à 4.

            >ça n'empêche pas qu'à la base Java a été fait pour >réaliser un certain type d'applications.

            Oui au début c'était de l'embarqué.
            Ensuite des applets
            puis des gui

            A chaque fois on a vu que c'était pas viable

            Maintenant c les serveurs d'applications Web :-)

            Bon ca marche pas bien non plus mais bon il reste plus que ca.

            • [^] # Re: Buffer overflows ...

              Posté par  . Évalué à 5.

              Maintenant c les serveurs d'applications Web :-)
              Bon ca marche pas bien non plus mais bon il reste plus que ca.

              En quoi ça ne marche pas bien ? Tu as des exemples concrets ?

              D'ailleurs ce n'est pas parce que les applets n'ont pas eu autant de succès que prévu que "ça ne marche pas". J'ai vu des GUI très bien faites en Java.

          • [^] # Re: Buffer overflows ...

            Posté par  . Évalué à -5.

            >ça n'empêche pas qu'à la base Java a été fait pour >réaliser un certain type d'applications.

            Oui au début c'était de l'embarqué.
            Ensuite des applets
            puis des gui

            A chaque fois on a vu que c'était pas viable

            Maintenant c'est les serveurs d'applications Web :-)

            Bon ca marche pas bien non plus mais bon il reste plus que ca.

    • [^] # Re: Buffer overflows ...

      Posté par  . Évalué à 0.

      Je suis d'accord avec toi. Il existe bien souvent des solutions alternatives (ocaml, python par exemple) aussi puissantes que le langage C/C++. En outre, on accède plus facilement à des fonctionnalités de plus niveau, ce qui permet dans un sens de mieux coder (on ne réinvente pas la roue).
      Côté performance, je crois que cet un point litigieux. Un programme C codé comme de la m... ira sans doute bien moins vite qu'un programme bien codé en python, par exemple. Les benchmarks sur les différents langages sont difficiles à apprécier pour ce genre de raison (http://www.bagley.org/~doug/shootout/(...)).

      Pour en revenir au sujet, les problèmes de "buffer-overflows" on les retouve dans tous les langages et doivent être éviter quelque soit le langage utilisé.

      -1 parce qu'on séloigne du sujet

      • [^] # Re: Buffer overflows ...

        Posté par  (site web personnel) . Évalué à 3.

        Un programme C codé comme de la m... ira sans doute bien moins vite qu'un programme bien codé en python, par exemple.

        Ça, c'est bien le problème. Comme je le répète souvent, le C c'est très bien, mais il faut savoir ce qu'on fait avec.

  • # Grsecurity

    Posté par  . Évalué à 7.

    Juste pour signaler l exisctance de cet excelent module kernel qui permet de gerer les ressources tres finements ( acl ), qui contre des ataques de type buffer overflow, race condition... ( contre le l execution des pages memoire, ...). Plus pleins de methode d audit. Existe pour Linux et OpenBSD

    http://www.grsecurity.org(...)

  • # On a battu Slashdot!

    Posté par  . Évalué à -1.

    Slashdot vient de faire une nouvelle sur MicroBSD. Chouette, LinuxFr est sur la pointe, ils arrivent même à battre Slshdot !!!

    ;-)

    -1 parceque, bon.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.