[+] warning : troll inside

• [+] [^]Re: warning : troll inside

  Posté par Pierre Tramo (page perso, ) le 05/02/2005 à 16:10. (lien). Évalué à -2.

  10ans ? le temps d'implémenter le support des partitions de plus de 2 Go avec L4

  [+] [^]Re: warning : troll inside

  Posté par LLG () le 05/02/2005 à 16:10. (lien). Évalué à -2.

  une petite estimation du jour où je pourrais faire tourner kde + oOo.org dessus ?
  
  Dans pile deux mois après banner!

  [^]sécurité des serveurs

  Posté par free2.org (page perso, ) le 05/02/2005 à 21:05. (lien). Évalué à 9.

  Je pense que la petite taille du noyau et le petit nombre d'appels systèmes (environ 10 pour l4 je crois) seront aussi très utiles pour la sécurité des serveurs: c'est plus facile d'auditer un petit noyau qu'un gros !
  
  L4 est si petit qu'on peut même envisager d'en faire une preuve formelle (ou au moins démontrer qu'il n'y a pas de faille de sécurité dedans).

  • [^]Re: sécurité des serveurs

    Posté par reno () le 05/02/2005 à 23:18. (lien). Évalué à 4.

    Ahem, pas d'accord: ce qui n'est plus implémenté dans le nano-noyeau mais au dessus doit quand même être audité.
    
    Ca te fait une belle jambe si la faille vient d'une surcouche plutot que du noyau..

    • [^]Re: sécurité des serveurs

      Posté par Manuel Menal (page perso, ) le 06/02/2005 à 00:11. (lien). Évalué à 10.

      Euh, autant je suis d'accord sur la quantité de code à auditer, autant je ne le suis absolument pas sur la seconde phrase. Le risque d'une faille dans le noyau se situe à deux niveaux : d'une, sous Unix, ce qui est dans le noyau est tout ce qui est "commun à toutes les applications", et donc ce qui est globalement vital au système ; de deux, tout ce qui est dans le noyau tourne avec les privilèges spéciaux sur le matériel. Pour le premier, on est d'accord, ça ne change rien. Si il y a un DoS potentiel sur, disons, la couche de gestion de la mémoire physique, on entraîne tout le système. Pour le second, en revanche, ça change tout. Je peux certes entraîner le système, éventuellement gagner des droits root, mais je ne peux pas me hisser dans le kernel space comme ça se voit assez régulièrement.
      
      De façon plus générale : en séparant les parties qui peuvent l'être, en définissant clairement quelles sont leurs relations et séparations, on permet plusieurs choses :
      
      Tout ce qui n'est pas purement vital au système, s'il se retrouve attaqué, n'entraîne que lui. La pile TCP/IP n'est pas vitale au système. Le driver son l'est encore moins. Chacun étant des applications tournant dans leur propre espace d'adressage, utilisant leur propre mémoire, elles n'entraîneront qu'elles-mêmes dans leur chute. On l'a vu, d'ores et déjà, il y a quelques années, quand un serveur Web sous GNU/Hurd avait subi un /.age en règle : la pile TCP/IP s'était vautrée un nombre incalculable de fois, la machine pas.
      
      On peut réellement réfléchir aux permissions nécessaires à telle ou telle application. Sous Unix, la tradition veut que la plupart des parties considérées comme "centrales" se retrouvent intégrées dans le noyau. Souvent par besoin, du fait de sa conception. Parfois par commodité. Certaines parties se trouvent avoir besoin de permissions spéciales, et en effet certains serveurs sont très privilégiés sous GNU/Hurd (ils tournent en root, et L4 ne leur restreint aucun appel système). Ces serveurs sont sensibles, et facilement identifiables comme tels. Mais un grand nombre d'autres (et je pense aux pilotes de périphérique, par exemple) ne nécessitent "que" de tourner en root (et encore, pas tous !). Ces parties deviennent de suite moins critiques. Il y a donc un double gain : un gain de clarté pour l'identification des parties centrales, sensibles ; un gain de sécurité lié aux privilèges donnés concrètement aux applications.
      
      C'est une évidence, mais il est bien plus facile d'auditer un code entièrement organisé en composants indépendants qu'un code "monolithique". Les effets de bord sont bien moins complexes, d'une part. On a souvent vu des horreurs comme des off by one dans un bout de code aboutir à une erreur de calcul assez embêtante de la taille d'un tableau, qui avec l'arrondi nécessaire se retrouvait assez pour être exploitable, ou potentiellement exploitable. Inutile de dire qu'une telle erreur est quasiment indétectable, et qu'un audit qui irait jusqu'à les rechercher prendrait des années. D'autre part, la séparation claire et revendiquée amène à faire quelque chose que Linus Torvalds s'est toujours refusé à faire pour Linux : concevoir des interfaces, stables tant que possible. La série de failles locales récentes découvertes dans Linux étaient liées à des comportements erratiques lorsque telle option était à telle valeur, tel pointeur à telle autre, etc., etc. Avoir des interfaces en mouvement constant, tandis que le code les utilisant l'est pas forcément du tout, n'aide pas à prévenir ce genre de problèmes. Je sais d'expérience que je me rends compte du comportement lors des cas limites principalement lorsque je documente mes fonctions/interfaces attentivement. Chose qu'évidemment, je ne ferai pas si elles sont destinées à être modifiées dans deux mois. Et chose qui n'est pas faite avec Linux. Les interfaces du Hurd, elles, sont stables. Il n'y a eu globalement qu'un changement qui a tout cassé (cassé l'ABI) depuis la première stabilisation. Bien entendu, on ne peut pas exclure qu'il y en ait d'autres, mais elles seront très, très limitées. Plus de clarté, à mon sens, c'est plus de sécurité, et c'est aussi une meilleure utilisation de ces interfaces, donc moins prône aux erreurs.
      
      Pour exemple, le coeur du système d'authentification du Hurd, représente 358 lignes de code (comptées par sloccount ;-). C'est LA partie du système qui nécessite de tourner en root, et qui nécessite d'être complètement et entièrement de confiance. 358 lignes, je pense que c'est faisable de l'auditer. Bon courage pour faire la même chose sur un Unix ;-)

      • [^]L4 pour applications simples sécurisées indépendantes d'une couche POSIX

        Posté par free2.org (page perso, ) le 06/02/2005 à 12:41. (lien). Évalué à 3.

        En effet, les applications les plus simples (et donc les plus faciles à auditer) n'ont pas besoin des nombreux appels systèmes définis par la norme ISO POSIX qui sont fournis par les nombreux serveurs de HURD.
        
        Par exemple un programme demandant une passphrase à l'utilisateur lors du boot et utilisant ensuite cette passphrase pour décrypter une quantité limitée de fichiers ou de clés privées (on lui fournit des données cryptées en entrée, il les fournit décryptées en sortie). Ce programme peut s'appuyer directement sur les appels systèmes de L4 (et/ou sur un nombre restreint de serveurs du HURD choisis parmis les plus simples et les plus faciles à auditer).
        
        Une fois L4 bien audité, on aura la garantie que la passphrase ne sera jamais accessible à aucun autre programme. Et que seuls un nombre limité de fichiers ou de clés seront accessibles en clair à un éventuel intrus ayant réussi à compromettre un des serveurs du HURD.

        [^]Re: sécurité des serveurs

        Posté par PasChauve PasOunet () le 08/02/2005 à 16:55. (lien). Évalué à 2.

        On l'a vu, d'ores et déjà, il y a quelques années, quand un serveur Web sous GNU/Hurd avait subi un /.age en règle : la pile TCP/IP s'était vautrée un nombre incalculable de fois, la machine pas.
        
        Quel est l'interêt vu au final ca revient au même , la page web ne s'affiche pas.

        • [^]Re: sécurité des serveurs

          Posté par free2.org (page perso, ) le 08/02/2005 à 17:28. (lien). Évalué à 3.

          L'intéret est ici dans un nombre incalculable de fois !
          C'est à dire qu'on peut relancer indéfiniment la pile TCP/IP sans dommage pour le reste du noyau, et bien plus rapidement que si on doit rebooter une machine à la main (et même les reboot automatiques, quand ils sont possibles, ne sont pas très rapides non plus)

          • [^]Re: sécurité des serveurs

            Posté par Manuel Menal (page perso, ) le 08/02/2005 à 19:48. (lien). Évalué à 4.

            Et qu'elle se relance automatiquement, qui plus est, translators passifs obligent. Sans aucun dommage pour les systèmes de fichiers, pour les autres services en cours, etc., etc.

            • [^]solution actuelle pour OO.org et applis complexes: L4 Linux realtime

              Posté par free2.org (page perso, ) le 11/02/2005 à 15:36. (lien). Évalué à 4.

              Pour ceux qui veulent faire cohabiter dès aujourd'hui des applications Linux complexes (OO.org) avec de petites applications sécurisées pour L4/Hurd, ils peuvent essayer la cohabitation de Hurd avec le port de Linux pour L4:
              
              http://os.inf.tu-dresden.de/L4/LinuxOnL4/(...)
              
              PS: si je me souviens bien, la plupart des versions vraiment realtime de Linux sont en fait des ports de linux sur un micronoyau temps réel. Et L4 est temps réel.