Trusted Debian 1.0

Posté par . Modéré par Fabien Penso.
Tags :
0
22
avr.
2003
Debian
Trusted Debian est une version orientée sécurité de la Debian, qui vient de sortir en version 1.0.
Elle inclut un grand nombre de patchs noyau (PaX, propriétés anti-buffer overflow, pile non exécutable, propriétés aléatoires) et de fonctionnalités spécifiques: FreeS/wan, RSBAC (contrôle d'accès), GCC modifié...
La Trusted Debian est disponible sous forme d'une source supplémentaire pour APT qui vient remplacer les paquets officiels debian (elle n'est pour l'instant pas installable directement, se servir d'une Woody fraîchement installée puis indiquer les sources TrustedDebian)

Aller plus loin

  • # Re: Trusted Debian 1.0

    Posté par . Évalué à 10.

    Vivement la version installable en stand-alone....
    Ceci dit, pourquoi ce travail ne serait-il pas intégré à la version par défaut ? Ca ne ferait pas de mal d'avoir toutes ces bonnes choses, ceux qui les veulent s'en servent, et ca reste dispo pour tous ceux qui voudraient utiliser IPsec ou autres plus tard...
  • # Re: Trusted Debian 1.0

    Posté par . Évalué à 10.

    C'est tres interessant notamment la page demo
    http://www.trusteddebian.org/demo.html(...)
    ces fonctionnalités sont celles qui commencent à être installé sur openbsd aussi, parfois de maniere un peu differente.
  • # Re: Trusted Debian 1.0

    Posté par (page perso) . Évalué à 5.

    J'avais toujours des doutes si j'allais(quand mon vieux pc sera a nouveau sur pied) y mettre une debian ou une mandrake(je vois le fou rire vous prendre amis debianneux :) ) pour me servir de passerelle/firewall.... Avec ce projet, mes doutes sont estompés, C'est une très bonne nouvelle, j'installe ca de ce pas sur le serveur de test.... Par contre, a part refaire la demonstration, pas grand chose a faire pour voir la difference, a moins ce que quelqu'un connaisse l'adresse d'un site du style : "Comment hacker une woody..." mais ce doit pas exister ce genre de chose, en principe c'est plutot : "Comment cliquer sur le bouton ok de winnuke et devenir un gros rebel du clavier", donc rien de bien interressant pour tester cette trusted debian...
    • [^] # Re: Trusted Debian 1.0

      Posté par (page perso) . Évalué à 2.

      Si tu veux mon avis, ce surplus de sécurité n'est en fait pas nécessaire sur un réseau privé ou les utilisateurs sont fiables et où les communications avec l'extérieur ne sont quasiment que sortantes.

      Si c'est dispo et que ça ne coute pas, pourquoi pas - bien sur. Mais à mon avis ces paquets préparés spécialement pour la sécurité doivent être surtout utile sur les machines qui sont très exposées... Les serveurs sur internet, qui à la différence d'un serveur sur un réseau local ne peuvent se permettre de tout envoyer balader par défaut. Les serveurs sur les réseaux d'administrations, d'entreprise, qui ont des utilisateurs aux intentions hostiles.

      Pour ton installation, il n'y a pas de « fou rire » à choisir une distrib plutôt qu'une autre. Il n'y pas une solution faite que d'avantages et une solution faite que d'inconvenient. C'est à toi de voir.
      • [^] # Re: Trusted Debian 1.0

        Posté par . Évalué à 1.

        JE crois que les attaques sont plus frequentes de l'interieur
        a moins que tu sois seule sur ton reseau.
        • [^] # Re: Trusted Debian 1.0

          Posté par (page perso) . Évalué à 2.

          Ce que tu dis correspond au second cas que j'ai évoqué, « Les serveurs sur les réseaux d'administrations, d'entreprise, qui ont des utilisateurs aux intentions hostiles ».

          A priori, sur un réseau qui concerne 10 personnes ou moins qui se connaissent, les risques d'attaque de l'intérieur sont très limitées. Et si j'ai bien suivi, gnumdk parle de ce type de réseau.
          • [^] # Re: Trusted Debian 1.0

            Posté par . Évalué à 6.

            Mon sentiment est que pour un gros ou petit réseau, local ou non, ce n'est pas très utile.

            J'ai regardé la démo. Il y a la pile, le tas, etc qui changent de place, mais il est possible de connaitre leur position (comme le montre la démo:-)). Ce n'est pas très utile.
            Dans la démo, il donne un exemple concret où c'est un "plus". S'ils pouvaient donné plus exemple... Les trous de sécurité sur une année se comptent en dizaine.

            Si c'était très utile, debian.org tournerait sous Trusted Debian. Je me demande s'il y a beaucoup de site (web, base de donnée, etc), même uniquement parmis les plus importants, qui utilisent ce niveau de "protection".

            Puis il y a le problème du support. S'il y a un trou de sécurité dans le noyau (type ptrace) et qu'il faut attendre 2 semaines de plus car il y a moins de mainteneurs de la version spécialisée, ce n'est pas cool. Si ce noyau spécialité est moins utilisé, il est peut-être aussi moins audité.
            • [^] # Re: Trusted Debian 1.0

              Posté par (page perso) . Évalué à 0.

              tu as besoin de ca sur un serveur avec plein d'utilisateur avec acces shell, pour un pov serveur web ou de BDD un firewall / IDS font l'affaire.
              • [^] # Re: Trusted Debian 1.0

                Posté par . Évalué à 4.

                > tu as besoin de ca sur un serveur avec plein d'utilisateur avec acces shell
                Pourquoi ? Tu as moins de chance de voir les fichiers de configuration modifiés avec ça ? Tu as moins de chance d'accéder aux mots de passes dans /etc/shadow ? Sans ça, tu peux "sniffer" le mot de passe root lorsque l'admin se loggue. Évidement, root ne doit pas se logguer sous X11 ou avec rsh, mais ça c'est un problème de configuration. Et si l'admin est bête au point de se logguer avec rsh, il faut avant tout changer d'admin et non de distribution.

                Je connais les réponse...

                > pour un pov serveur web ou de BDD un firewall / IDS font l'affaire.

                Si ton serveur est un serveur web faut bien que le firewall laisse passer les requêtes http vers le serveur web. Donc le firewall ne protège pas ton serveur web. Ce serveur web, même "dernière" un firewall, doit être bien configuré et à jour.
                Donc le firewall n'est pas LA solution. Si tu as un script php mal foutu, tu peux être dans la merde avec ou sans "Trusted Debian".

                Je trouve bien que des gens bossent en avance sur la sécurité. Pour des serveurs critiques c'est toujours ça de pris. Mais de là à dire que "j'ai besoin" de trusted debian (ou équivalent)...
                • [^] # Re: Trusted Debian 1.0

                  Posté par (page perso) . Évalué à 9.

                  exemple : un serveur a la Fac avec 200 utilisateur avec acces shell car ils font leur TPs C++.

                  tu va bien en avoir dans le tas pour essaier un buffer overflow ou un truc comme ca.

                  c'est la que c'est utile, plus pour les exploits locaux que 'remote'
                  et puis tu l'installe si tu en as le besoin, c'est pour ca que c'est une option sur woody
                  • [^] # Re: Trusted Debian 1.0

                    Posté par . Évalué à 3.

                    > tu va bien en avoir dans le tas pour essaier un buffer overflow ou un truc comme ca.

                    Ben ça va être un exploit dans le compte de l'utilisateur. Au pire il peut faire un équivalent de "rm -rf /". Mais il n'a pas besoin de faire un exploit pour le faire, ni d'utilise gcc.
                    C'est un problème de configuration machine et ça demande un bon admin.

                    Si c'est un programme d'échange de programme entre utilisateur, gpg est plus indiqué pour ne lancer que les programmes des personnes "de confiance" (et à l'occasion connaitre celui qui t'a fait une crasse et, si l'envi te démange, de lui casser la gueule). C'est de la responsabilité des utilisateurs.

                    > c'est la que c'est utile, plus pour les exploits locaux que 'remote'

                    Ça ne change rien si tu as un serveur MySQL uniquement accessible en local par 200 utilisateurs, ce n'est pas plus critique que qu'un serveur MySQL accéssible à distance par 2000 personnes.
                    • [^] # Re: Trusted Debian 1.0

                      Posté par . Évalué à 6.

                      Ben ça va être un exploit dans le compte de l'utilisateur
                      Non, il va faire ça sur un prog suid root.
                      Et le type se retrouve root sur la machine.

                      C'est donc en effet utile sur un serveur avec beaucoup de comptes de pouvoir eviter les buffer overflow.
                      • [^] # Re: Trusted Debian 1.0

                        Posté par . Évalué à 1.

                        > Non, il va faire ça sur un prog suid root.

                        Si le programme suid root a un trou de sécurité et si les "extensions" de "trusted debian" permet d'éviter ce trou de sécurité (ce qui n'est pas garanti, voir par exemple ptrace et les bugs modprobe pour les plus gros problème, voir aussi le dernier problème sendmail qui est aussi un exploit local), c'est un plus. Mais il y a des si.

                        Je préfère m'appuier sur une distribe réactive sur les problèmes de sécurité et n'installer que des paquets signés. D'ailleur j'aimerais bien que rpm propose une options de configuration qui interdit par défaut l'installation de programmes dont la signature (pgp) n'a pas été validée.

                        J'aimerai aussi que l'on me trouve un page web avec quelques statistiques. Exemple :
                        - trou de sécurité pour 2002 : 50 dont 20 inhibés par l'extension bidule.

                        Hors j'ai rien vu jusqu'à maintenant qui montre que statistiquement c'est un avantage significatif.
                        • [^] # Re: Trusted Debian 1.0

                          Posté par . Évalué à 7.

                          Donc pour toi, la recherche de plus de sécurité est inutile? Si on te propose un patch qui améliore la sécurité de ton noyau, tu ne l'appliques pas parce que tu sais que tu es un bon admin?
                          J'ai l'impression que tu te bas contre des moulins à vent là.
                          Les méchants misent sur tes "si" et tes négligences.

                          Concernant leur manque de réactivité, leur travail s'effectue surtout au niveau du noyau et de quelques patchs spécifiquent. De ce fait, les audits de code s'additionnent et profitent à tous.
                          • [^] # Re: Trusted Debian 1.0

                            Posté par (page perso) . Évalué à 9.

                            moi ce que je me pose comme question c'est pourquoi il ne sotn pas intégrés dans les noyeaux actuels.

                            Ca fait tout de meme longtemps qu'on entend parler des patchs pourune pile non exécutable. Je me dis (betement ?) que si c'etait si simple ca serait par défaut partout depuis longtemps.

                            reste à savoir où j'ai fait une erreur dans mon raisonnement
                            • [^] # Re: Trusted Debian 1.0

                              Posté par . Évalué à 8.

                              Parce qu'il n'y a pas que la sécurité qui compte. Il y a aussi les performances. Demain Debian va sortir :
                              - "Trusted Palladium Debian"
                              et ça va marcher...
                            • [^] # Re: Trusted Debian 1.0

                              Posté par (page perso) . Évalué à 5.

                              c'est une option, donc c'est bien ca laisse le choix.

                              si tu utilise ton PC comme outil bureatique ou dans un cluster de calcul tu preferrera les perfs
                              • [^] # Re: Trusted Debian 1.0

                                Posté par . Évalué à -2.

                                De toute façon pour ce genre d'utilisations la Suse est indispensable, on ne peut pas se permettre d'utiliser un produit semi-professionnel comme Debian, Lindows ou Redhat.
                          • [^] # Re: Trusted Debian 1.0

                            Posté par . Évalué à 6.

                            > Donc pour toi, la recherche de plus de sécurité est inutile?

                            Rappel de mon post plus haut ( http://linuxfr.org/comments/197678,1.html(...) ) :
                            - "Je trouve bien que des gens bossent en avance sur la sécurité. Pour des serveurs critiques c'est toujours ça de pris. Mais de là à dire que "j'ai besoin" de trusted debian (ou équivalent)..."

                            > Si on te propose un patch qui améliore la sécurité de ton noyau, tu ne l'appliques pas parce que tu sais que tu es un bon admin?

                            C'est quoi ce propos ?
                            Je ne suis pas réfractaire à ce qui améliore la sécurité. Mais il faut faire des compromis (sécurité/fonctionnalité/performance/complexité) et se concentrer sur les fondamentaux.

                            Et dans les fondamentaux, il y a la supression des trous de sécurité. Ajouter un patch (de la complexite en plus et dont potentiellement des trous de sécurité en plus) n'est pas FORCÉMENT un gros avantage même si ça peut inhiber quelques cas de trou de sécurité. Car dans la pratique ça ne répond qu'à quelques cas bien peu nombreux de trou de sécurité (et encore faut-il qu'il y ait un trou de sécurité). Si ces patchs étaient "magnifiques", ils seraient depuis longtemps dans le noyau officiel.

                            Je ne remet pas en cause leur existance ! Mais pour en avoir BESOIN, il faut fournir un service très très très critique. Et avant que ces patchs soient significativement intéressants, il faut faire un grosse travail de configuration et d'audit de ton service (par exemple les scripts php développés pour ton service doivent être contrôlés. Il faut définir qui a autorité pour valider des modifications, mettre en place des tests d'attaque, mettre en place un gestionnaire de version pour revenir en arrière rapidement si une connerie est faite, bétonner les sauvegardes, proposer un mode dégradé mais bétonné côté sécurité (pas d'écriture, données confidentielles inaccessibles) lorsqu'un trou de sécurité est découvert, etc...).
                            J'ai simplement dit que l'emploi de ces patchs, extensions sont réservés à un ensemble de personne/organisme très restraint.
                    • [^] # Re: Trusted Debian 1.0

                      Posté par (page perso) . Évalué à -2.

                      Ben ça va être un exploit dans le compte de l'utilisateur. Au pire il peut faire un équivalent de "rm -rf /". Mais il n'a pas besoin de faire un exploit pour le faire, ni d'utilise gcc.
                      C'est un problème de configuration machine et ça demande un bon admin.

                      Je vois tu n'y comprend rien en fait :)
                  • [^] # Re: Trusted Debian 1.0

                    Posté par . Évalué à 4.

                    exemple : un serveur a la Fac avec 200 utilisateur avec acces shell car ils font leur TPs C++.
                    c'est la que c'est utile

                    Et comment tu fais actuellement ?
                    Tu réinstalles le système toutes les semaines ?
                    Et comment a fait Unix pour faire parti des OS les plus sûrs sans ces "goodies" ?

                    Je trouve qu'il y a beaucoup de frime dans cette course à l'armement qui n'est pas argumentée.

                    Je n'ai pas envis de me faire chier avec des trucs qui font passer le niveau de sécurité de mon système de 97 à 98 sachant que dès que je fais une connerie de configuration, il peut chuter à 20.
                    • [^] # Re: Trusted Debian 1.0

                      Posté par . Évalué à 3.

                      > Je trouve qu'il y a beaucoup de frime

                      Non non, du pragmatisme.
                      S'il suffisait d'installer une bécane (2h), appliquer les mises à jour (1h), puis configurer (2h), faire deux scripts dans cron pour nettoyer les "conneries" des édutiants (qui bien que édutiants ont toutes les compétances pour craquer un système d'exploitation type Unix qui a pourtant une solide réputation de sécurité)(2h car il faut ajouter la pose café entre potes), les administrateurs seraient démystifiés.

                      Alors oui, pour que des étudiants compilent des programmes C++ (car les autres language ne posent pas de problème !?!) il faut le dernier cri de la technologie en terme de sécurité sinon tu es dans une merde noir.
                    • [^] # Re: Trusted Debian 1.0

                      Posté par . Évalué à 3.

                      Je ne suis pas sûr qu'Unix soit un des OS les plus sûrs, ou alors par défaut de compétition. Si tu as fait ta scolarité dans une école ou une fac d'informatique, tu sais que les abus sont fréquents, simplement ils sont rarement rendus publics et sanctionnés car il s'avère généralement que les étudiants sont aussi forts que les administrateurs salariés, donc il vaut mieux passer l'éponge (l'exemple caricatural étant celui d'une certaine école à la réputation sulfureuse dans laquelle un élève a réussi à prendre la place de l'admin sys en crackant son réseau et en faisant échouer toutes ses tentatives de reprendre le contrôle...).
                      • [^] # Re: Trusted Debian 1.0

                        Posté par . Évalué à 5.

                        > Je ne suis pas sûr qu'Unix soit un des OS les plus sûrs, ou alors par défaut de compétition.

                        Pas claire cette phrase.
                        Je prend une RedHat par exemple (je ne connais pas les autres). Je l'installes et je crées un compte utilisateur (j'ai pris soit de mettre un mot de passe au bios et à grub, j'ai un détecteur de métal pour que tu ne sortes pas le PC de la pièce, le boîtier est soudé pour que tu ne puisses pas le démonter). Tu fais quoi avec le compte utilisateur ? Il y a le "while(1) fock() ;" (faut paramétrer ulimit et c'est réglé), saturer le disque dur (il faut ajouter des quotas), limiter les performances en fesant des tonnes de requête sur les services disponibles (ça peut aussi être un moyen dérivé pour saturer le disque dur), bouffer de la mémoire vive, les descripteurs de fichiers etc (il y a encore ulimit pour limiter les dégats).
                        Les possibilités sont pas épaisses. Le mieux est de partir avec le disque dure sous le bras (si c'est possible) pour ajouter tranquillement chez toi un trou de sécurité, un sniffer. Après tu le réinstaller dans la bécane "ni vu ni connu", et tu attends que l'admin t'envoie le mot de passe root.

                        > les abus sont fréquents

                        Ouais mais il faut reconnaitre que c'est souvent sur des bécanes installés rapidement. Genre tu as le prompt lilo et tu peux booter en runlevel 1 ou avec "init=/bin/bash". Il n'y a pas de mot de passe sur le bios et tu peux booter sur une disquette. La bécane n'a pas été mise à jour depuis 3 ans, c'est très courrant même sous Unix/Linux, et il reste un énorme trou de sécurité (genre "ping -i 'eth0; chmod +s /bin/bash'" avec modprobe (c'est pas un problème d'overflow :-], c'est une erreur de conception), pas de /etc/shadow et un mot de passe qui se casse en 2 heures maximum, etc...).
                        Puis il y a tout les trucs classiques de l'admin qui fait un ftp ou rsh sur une bécane et sous le compte root (mot de passe en claire). Qui ne signe pas ces mails avec pgp et du coup tu peux usurper son identité pour demander le mot de passe root de la nouvelle becane, qui a un postit avec plein de mot de passe sur son bureau car il n'a pas de mémoire, qui tape au clavier à une lenteur effroyable et tu as tout le temps de noter le mot de passe root lorsqu'il se logue, qui téléphone à quelqu'un pour faire une manip urgente sous root et donne le mot de passe, qui une foi sur deux oublit de se délogguer lorsqu'il qu'il son bureau, etc...

                        C'est bien plus souvent un problème d'admin que d'OS et les mauvais exemples que j'ai donné je les ai vécu. La sécurité globale est égale au maillon le plus faible. Et c'est plus souvent l'admin que OS le maillon faible.

                        Je vais te donner un autre exemple "rigolo". J'étais dans une petite boîte, et je m'installe une RedHat 6.2 (ça doit être applicable à n'importe quelle distribution un minimum maintenu). A bout de quelques mois, ma bécane est très utilisée (c'était la seule bécane sous Linux), j'utilise bind, squid, ssh, apache/php, samba, mysql, posgresql. Tous les services sont accessibles de l'extérieur. Il y a deux admins qui s'amusent à sniffer ma bécane et détecte les services qui tournent et leur version. Fort de ce constat, il me chient un pendule et disant que certains services ne sont pas sûrs et que de tout de manière la RH est moins "secure" qu'une Debian. Donc il me demande de passer sous Debian. RedHat ou Debian, je me branle mais la raison donnée, c'est n'importe quoi. De plus ça allait me faire du boulot pour refaire la configuration. Je suis un peu énervé et je leur lance un défit. Je leur dit que je passe sous débian s'il me prouve qu'ils se sont introduit dans ma bécane (hors compte des autres utilisateurs) ou utilisé un exploit d'un service.
                        Ben, il ne s'est rien passé.

                        Les admins, c'est comme le reste, il y en a des bons et des ... moins bons. J'ai connu des admins très pointus, organisés et pragmatiques. Je ne mets pas tous les admins dans le même panier.
                        • [^] # Re: Trusted Debian 1.0

                          Posté par . Évalué à 3.

                          Tu fais quoi avec le compte utilisateur ?

                          Je passe en revue tous les trous de sécu existants sur les softs et bibliothèques installés, y compris les services réseau que je peux interroger. Enfin, pas moi, vu que je ne suis pas un cracker.

                          Quand on voit le nombre de trous qu'il y a par an sur les outils traditionnellement livrés avec les différents Unix (voire dans les noyaux des Unix eux-mêmes, comme le noyau Linux, ou dans les bibliothèques les plus fondamentales comme la glibc), Unix n'est pas un système "sûr". Donc si c'est l'un des plus sûrs, c'est bien par défaut.
                          • [^] # Re: Trusted Debian 1.0

                            Posté par . Évalué à 1.

                            > Unix n'est pas un système "sûr". Considérer si Unix est un système "sûr" ou non, il faut regarder par domaine. Si je compare à mon auto-radio, Unix n'est pas sûr. > Donc si c'est l'un des plus sûrs, c'est bien par défaut. Tu veux dire que c'est "par hazard". Que le fait que chaque programme a sa mémoire virtuel, que les mots de passe sont cryptés, qu'il y a un système de protection de fichier, etc... n'avaient pas pour but de faire un système "sûr" ? Je suis relativement d'accord pour dire qu'Unix n'est pas "sûr". Comme tous les OS a usage général. Et pour preuve que ce n'est pas sûr, il faut un admin pour "surveiller" la bécane, la mettre à jour. Mais sous-entendre que c'est la fruit du hazard...
                • [^] # Re: Trusted Debian 1.0

                  Posté par (page perso) . Évalué à 3.

                  « Si ton serveur est un serveur web faut bien que le firewall laisse passer les requêtes http vers le serveur web. Donc le firewall ne protège pas ton serveur web.
                  Ce serveur web, même "dernière" un firewall, doit être bien configuré et à jour.
                  Donc le firewall n'est pas LA solution. Si tu as un script php mal foutu, tu peux être dans la merde avec ou sans "Trusted Debian". »

                  Concrêtement, le firewall ne fait pas forcement du tout ou rien. C'est à dire que même en laissant passer les requêtes, il peut toujours avoir un rôle (interdire certain types de requêtes, car toutes ne sont légitimes... ).
                  Donc le firewall protège le serveur web, en partie.

                  Bien entendu, si t'as un script php qui est une faille de sécurité, ça peut poser problème. Par exemple, si ton script php devoile le contenu de /etc/shadow, ça peut poser problème, si quelqu'un trouve le moyen d'avoir un shell sur cette machine (effectivement, craignos si le ssh est ouvert et qu'il accepte les mots de passe.

                  Mais ce problème là est toujours vrai. Si t'as un programme en C (qui ne passe pas par le serveur web) qui donne le contenu de shadow... Mais à ce niveau là, n'est-ce pas le système qui est mal configuré ? (www-data ne peut pas lire /etc/shadow en théorie).
    • [^] # Re: Trusted Debian 1.0

      Posté par . Évalué à 10.

      Tu peux tjs essayer de lancer un nessus dessus.
      cf www.nessus.org
      La aussi tu as juste à cliquer sur le bouton ok (j'exagère à peine) et tu te retrouves avec une grosse baterie de tests et un rapport de vulnérabilités.
  • # Re: Trusted Debian 1.0

    Posté par . Évalué à 10.

    Peut-être suis-je hors sujet mais est-ce que Trusted Debian se rapproche d'OpenWall Project ?

    http://www.openwall.com/Owl/(...)

    OpenWall est basé sur RedHat mais est une distribution orientée vers la sécurité avec aussi une gestion des buffer overflow par exemple.

    Peut-être (si ça n'existe pas déjà) qu'il serait bon d'avoir une page quelque part qui reprendrait les distributions Linux (je sais qu'il y en a énormément) classée par catégorie selon leur fonction première (peut-être suis-je utopiste).
    • [^] # Re: Trusted Debian 1.0

      Posté par . Évalué à 4.

      sur distrowatch, tu as un peu ca, avec des pages différentes pour les distrib sur CD, les distrib spéciales firewall, les distribs sources
      • [^] # Re: Trusted Debian 1.0

        Posté par . Évalué à 4.

        Pour ma part, le meilleur site listant les distrib par fonctions c'est linux.org :
        http://www.linux.org/dist/list.html(...)

        openwall. j'ai fait quelleques jours dessus. Je ne conteste pas la qualité, je n'ai pas eu le temps de me faire un avis, mais, si je ne me trompe pas, elle utilise un kernel 2.2 (2.2.25-ow1 me dit leur "Change logs"): iptables..., tous les drivers ne compilent pas (mon modem ne marche pas).
        En plus, leur site internet et en .com; Trusted Debian lui en .org (bien sûr)
  • # Re: Trusted Debian 1.0

    Posté par (page perso) . Évalué à 3.

    La Trusted Debian, elle est compatible TCPA ?

    Merci à sam qui osait pas la poster :-)
    • [^] # tcpa sa sux

      Posté par . Évalué à -10.

      <troll distrib mode=intelligence minimum>
      Debian étant une version libre et kimarche de la mandrake, tu devrais avoir la réponse... ;)
      • [^] # Re: tcpa sa sux

        Posté par . Évalué à -5.

        "Debian étant une version libre et kimarche de la mandrake"

        tiens moi je croyais que c'était une version gratuite de windows
  • # La question que tout le monde se pose (surtout sam) :

    Posté par . Évalué à -6.

    Es-ce que la debian est compatible TCPA ?



    Ah, on me souffle dans l'oreille qu'il s'agit de sécurité pour la machine, et pas pour les maisons de disques qui crient très fort.
  • # Re: Trusted Debian 1.0

    Posté par . Évalué à 8.

    MDK fournis un kernel sécurisé (généralement appelé kernel-secure), est-ce du même gabarit que trusted debian ?
    • [^] # Re: Trusted Debian 1.0

      Posté par (page perso) . Évalué à 2.

      Ben non, refléchit.
      La réponse est simple :
      si c'est pas Debian, c'est mal(tm).
      Le noyau patché, c'est mal(tm), sauf si c'est fait par debian.


      Plus sérieusement.
      Le kernel de mandrake inclut le patch grsecurity, et la sécurisation se fait via msec, qui, par exemple, restorent les permissions, vérifient les logs etc.

      La, par contre, il y a peu prés les mêmes patches, et des bianires compilés avec une version de gcc. Par contre, la partie sécurisation doit se faire comme sur une distrib normal.


      Pour finir, je trouve que ces méthodes ne sont pas de vrai solution en profondeur, contrairement au audit de sécurité que OpenBSD subit réguliérement.
      • [^] # Re: Trusted Debian 1.0

        Posté par (page perso) . Évalué à 3.

        | Le kernel de mandrake inclut le patch grsecurity, et la sécurisation se fait via
        | msec, qui, par exemple, restorent les permissions, vérifient les logs etc.

        Le patch grsecurity est d'ailleurs un vrai régal à appliquer et régler sur Debian.
        Le site de grsecurity a des présentations très intéressantes sr le deal perfo/sécurité.

        Quand aux autres outils, ils sont présent en abondance dans la Debian normal.
        Pour s'en persuader, et puisque personne n'en à parlé, je donne l'URL indispensable pour accompagner cet article : http://www.debian.org/doc/manuals/securing-debian-howto/.(...)
        Ne me remerciez pas, tout le plaisir a été pour moi :-)
    • [^] # Re: Trusted Debian 1.0

      Posté par . Évalué à 1.

      y'a pas que le noyau qui peut avoir des trous.
      • [^] # Re: Trusted Debian 1.0

        Posté par (page perso) . Évalué à 3.

        A priori, aucun paquet distribué n'est censé être troué.

        A priori, il y'a là des patchs de sécurité en plus - pas des correctifs de trous absent ailleurs, sinon c'est que « ailleurs » est défectueux.
  • # Et concernant les Maj de securité ?

    Posté par (page perso) . Évalué à 6.

    Les mises à jours de sécurité de la woody couvrent également cette distrib ?

    J'ai pas vu ça dans la FAQ. J'espére que la réactivité sera bonne, meilleur que celle comme pour la mise à jour de openssl .

    http://www.debian.org/security/2003/dsa-288(...) => 17/04
    http://www.linuxsecurity.com/advisories/redhat_advisory-3099.html(...) => 01/04
    http://www.linuxsecurity.com/advisories/suse_advisory-3112.html(...) => 04/04
    http://www.linuxsecurity.com/advisories/gentoo_advisory-3042.html(...) => 24/03
    • [^] # Re: Et concernant les Maj de securité ?

      Posté par (page perso) . Évalué à 2.

      « Les mises à jours de sécurité de la woody couvrent également cette distrib ? »

      Ca paraitrait étonnant, puisque ces paquets ne sont pas inclus dans l'arbre debian.
    • [^] # Re: Et concernant les Maj de securité ?

      Posté par . Évalué à 0.

      L'idée étant d'être moins sensible aux problèmes de sécurité, ils ne sont pas obligés d'être très réactifs sur les maj de sécurité.
      • [^] # Re: Et concernant les Maj de securité ?

        Posté par (page perso) . Évalué à 3.

        C'est moi ou cette remarque est parfaitement incohérente ?
        • [^] # Re: Et concernant les Maj de securité ?

          Posté par . Évalué à 2.

          « L'idée étant d'être moins sensible aux problèmes de sécurité, ils ne sont pas obligés d'être très réactifs sur les maj de sécurité.»

          Je ne vois pas où est la merde, pour moi ça veut dire:
          si ils sont moins reactifs, on rentre plus facilement.
          Mais si, une fois rentré, on ne peut presque rien faire ce n'est pas tres grave.
          (le on est un pronom indéfini, il n'est pas egale à je)
        • [^] # Re: Et concernant les Maj de securité ?

          Posté par . Évalué à 3.

          Un des objectifs de TrustedDebian est de patcher le compilo et le noyau de manière à fournir des paquets pour lesquels :
          - les vulnérabilités découvertes ne seront pas exploitables
          - ou bien elles le seront plus difficilement, en tout cas pas aussi facilement que sur un système "classique"

          => Il n'est pas nécessaire de mettre à jour une application "trouée" immédiatement puisque le trou n'est pas exploitable (ou beaucoup plus difficilement).
          • [^] # Re: Et concernant les Maj de securité ?

            Posté par . Évalué à 1.

            Ce raisonnement est du même ordre que : "je ne me lave pas car je suis propre".
            • [^] # Re: Et concernant les Maj de securité ?

              Posté par . Évalué à 1.

              Moi je dirais, "je ne suis pas obligé de me laver toutes les heures car je suis propre, mais je me lave tous les jours".
              J'ajouterais que les maj de sécurité des paquets ne corrigent que les failles connues.
              Comme l'a posté Michael Scherer un peu plus bas, mettre à jour les paquets ayant des failles connues ne suffit pas à sécurisé ton système. Ce n'est qu'un élément parmi d'autres.
          • [^] # Re: Et concernant les Maj de securité ?

            Posté par . Évalué à 7.

            C'est beau la confiance.
            Même Microsoft n'est pas arrivé à rendre leurs utilisateurs aussi bêt^H^H^H attendrissants.
        • [^] # Re: Et concernant les Maj de securité ?

          Posté par . Évalué à -2.

          Je crois en effet qu'elle a sa place dans un bêtisier ;)
      • [^] # Re: Et concernant les Maj de securité ?

        Posté par (page perso) . Évalué à 5.

        Mhh, dois je comprendre, que, parce que tu as un firewall, tu as pas besoin d'utiliser les tcp wrappers ?
        Que, sous le prétexte que tu as un antivirus, tu peut te permettre de lancer tout les executables du monde ?

        La sécurité est un processus, pas un produit.
  • # Re: Trusted Debian 1.0

    Posté par (page perso) . Évalué à 4.

    Bon j'étais entrain d'essayer openBSD pour envisager l'utilisation d'un OS orienté sécurité pour mon FW, maintenant va falloir que m'interesse aussi à Trusted Debian (cool).

    Vive la diversité :)
    • [^] # Re: Trusted Debian 1.0

      Posté par . Évalué à 5.

      A noter que Gentoo Linux inclue exactement les memes choses (PaX dans le noyau, GCC avec propolice de base) depuis longtemps. C'est juste à toi de décider si tu veux les activer ou pas.

      Ca te fait un choix supplémentaire, huhu :)
  • # Re: Trusted Debian 1.0

    Posté par . Évalué à 1.

    une petite allusion à TrustedBSD ??
    http://www.trustedbsd.org(...)

Suivre le flux des commentaires

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