Journal Sécurité et noyau linux, c'est pas la fète...

Posté par  .
Étiquettes : aucune
0
4
août
2004
Le 2.4.27 est sorti en RC5 hier, corrigeant cinq failles de sécurité. http://kerneltrap.org/node/view/3578(...)
L'alerte la plus importante : http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0415(...)
Les distributions ont normalement toutes fourni des mises à jour du noyau corrigé. Certaines de ces failles concernent aussi le 2.6.

A titre personnel, je me demande une chose : les noyaux récents et stables sur kernel.org contiennent tous à l'heure actuelle des failles de sécurité. Va-t-on devenir obligé de ne passer que par les sources fournies par les distributions, ou aura-t-on un jour un site recensant les patchs de sécu applicables aux noyaux de kernel.org et ne contenant que la correction de la faille de sécurité ?

  • # Cycle de release ?

    Posté par  . Évalué à 6.

    Je vais faire part de mon experience personnelle :-)
    Je pense que le probleme ne vient des failles ou des distributions, mais principalement du modus operandi des projets.
    Actuellement, la mode est a la technique de "il y une faille de securite, je sors une nouvelle release plus tot que prevu". En tant que packager, il m'est souvent arrive d'avoir a upgrader en urgence un package, sous pretexte que la version precedente contenait une faille de secu, et parfois avec des resultats bizarre a l'arrivee.
    De moins en moins de projet proposent des versions intermediaires ou des backports de patches pour les releases _stables_.
    Les interdependances sont devenus nombreuses et/ou certains utilisateurs (admins dans mon cas) attendent une statibilite dans les packages.
    J'ai 2 choix:
    - backporter le fix
    - mettre a jour la release
    Dans la plupart des cas, faire un backport n'implique pas de changements massif, mais il m'est arrive de passer du temps a backport un patch car toutes les fonctions avaient change.
    Plus je passe de temps dessus, plus la faille est exploitable.
    En gros, il faut 12h pour que le fix soit commit (parfois c'est fait 1h apres, parfois le lendemain matin ;)). Ca laisse une fenetre exploitable.
    Ce que j'essaye de faire le plus souvent est de backport le patch, faire un bump de la version, et mettre a jour, histoire de contenter les plus frileux.

    My 2 cents.

    • [^] # Re: Cycle de release ?

      Posté par  . Évalué à 4.

      C'est facile à faire un backport (question de béotien) ?
      Ce que j'aimerais vraiment, même si je me demande si c'est possible, c'est un site qui référence ces backports. Genre, je suis en 2.4.22, je télécharge le patch de sécu correspondant, et ça roule ! Pourquoi ne pas passer à la nouvelle version de noyau me direz-vous ? Tant qu'au niveau fonctionalité, j'ai ce qu'il me faut et ça marche avec le 2.4.22, je ne veux pas avoir à changer.

      • [^] # Re: Cycle de release ?

        Posté par  . Évalué à 3.

        dans 95% des cas le backport est simple... sauf si le code a change. Les distribs fixent genarelement leur kernel au lieu d'upgrade, mais je ne pense que ca soit forcement leur boulot.

Suivre le flux des commentaires

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