Debian (APT) Comment obtenir certains package spécifique Unstable "temporairement" dans une version Stable

[theggbce]

Bonjour,

J'ai un défi de plus en plus présent avec la sécurité de mes installations... et l'équilibre des versions des distributions Linux. Il m'est techniquement impossible d'utiliser des distro en version Unstable (sid) ou Testing (Next Stable) pas nécessairement du fait que ces versions ne sont pas "stable/fiable" mais malheureusement incompatible avec certains produits... Les fabricants de certains logiciels, les plateformes de services infonuagiques, etc. n'offrent pas toujours une compatibilité avec ces versions (voir même rarement et également avec les versions "Stable" dès leur sortie... Il faut parfois attendre quelques mois avant que les nouvelles stables soient disponibles.)

Ceci dit, vu l'enjeu de mettre en place des plateformes offrant des services sur le nuage, ces mêmes plateformes sont les plus exposées, les plus vulnérables, les plus ciblées ! Il est donc primordiale d'appliquer les correctifs de sécurité le plus rapidement possibles lorsque des failles 0-day sont exploitées et/ou des failles de niveau critique sont découvertes !

Les fabricants des logiciels sont tout de même assez répondant rapidement pour relâcher des versions corrigées. Je pense surtout aux produits sollicités dans le monde des services Internet (Apache HTTP Server, OpenSSH, OpenVPN, OpenSSL, Postfix, etc.)... Le hic c'est la réponse de la disponibilité de ces logiciels corrigés sous les distributions "stable" (de catégorie de "production").

Nous pouvons parfois mettre en place des mitigations, mais la plupart du temps la seule solution est la mise en place d'une version plus récente...

Comme mentionné précédemment, il est impensable voir impossible d'utiliser des distributions "sid" ou "testing". Les backports ou les proposed-updates sont également rarement en répons rapide pour se protéger 😞

L'autre solution que certains pourraient proposer est de compiler les logiciels depuis les sources directement... Mais comme vous le savez, effectuer cette tâche pour un environnement de "production", maintenir à long terme un mélange hydride de paquets gérés par des sources compilées manuellement et d'autres paquets provenant de la distribution sur des dizaines, centaines ou milliers d'installation, devient impensable. 

Alors, je pose la question:

Est-ce que vous connaissez un moyen d'utiliser une version "stable", mais pour des cas particuliers lors de failles de sécurité critique, pouvoir configurer des sources "partielles" provenant des versions "unstable" ou "testing" ... Et de manière temporaire. Ne pas faire en sorte de toujours tenter de récupérer les paquets depuis ces sources. 

Exemple concret:

Sous Debian 11 (old stable), la version de OpenSSH la plus récente est 8.4p1, sous Debian 12 (stable) c'est 9.2p1... Qui sont 2 versions tout autant vulnérables de manière critique (CVSS 9.8)... depuis plus de 2 mois !

Sous Debian 13 (testing), OpenSSH 9.4p1 est disponible et il corrige les failles de sécurité.

Dans 2-3 mois, il pourrait arriver une nouvelle version OpenSSH 9.5 mais qui ne me serait pas utile pour corriger une nouvelle faille critique... Donc pour ce moment futur je ne voudrais pas obtenir une autre nouvelle version car la version 9.4p1 pourrait me satisfaire à cet instant...

En parallèle et fortement possible durant cette période de temps, le produit OpenSSH 9.4p1 pourrait être devenu disponible pour Debian 11 ou 12 via les backports... C'est comme si je voudrais m'abonner "partiellement" à des versions rapides pour des contextes de criticité seulement.

Laissez-moi vos idées ?

Modifié le 26 septembre 2023 par theggbce

[brice.wernet]

Il y a 8 heures, theggbce a dit :

Est-ce que vous connaissez un moyen d'utiliser une version "stable", mais pour des cas particuliers lors de failles de sécurité critique, pouvoir configurer des sources "partielles" provenant des versions "unstable" ou "testing" ... Et de manière temporaire. Ne pas faire en sorte de toujours tenter de récupérer les paquets depuis ces sources. 

On ne mixe pas les canaux. C'est une très mauvaise idée: on ne récupère pas un bout de paquet, mais le paquet et ses dépendances -> on peut tout faire s'écrouler sur un apt install...

Solution possible:

• séparer le frontal sécurité des services
  • frontal: Le mettre en niveau minimal de fonctionnalités (par exemple avec un reverse proxy très simple et très à jour mais qui s'occupe de la sécu - pas d'accès SSH mais un accès console via un bastion)
  • services: serveurs apache en HTTP (non S) derrière sur des debian 10,11 ou autre

Le frontal doit être recréable par script, histoire de ne pas être trop lié à une distro.

[L33thium]

Regarde les bulletins de sécurité Debian, ils appliquent les patchs de sécurité sur stable et oldstable sans modifier la version du paquet de base.

C'est ce que veux stable pour Debian, stabilité fonctionnelle : il n'y a pas d'ajout ou de retrait de fonctionnalités dans la branche stable. Ils modifient si nécessaire les patchs upstream pour parvenir à cette fin. D'où les années de discordes avec Mozilla au sujet de Firefox.

Donc pour le besoin de sécurité, Debian est tout à fait aux normes et réactive.
Si on a besoin de "fraicheur" sur une Debian stable il y a les containers docker ou podman, les VM, les paquets flatpak, snap, ...
Tout ça mettra beaucoup moins le système en peril que mixer stable avec testing ou unstable

Pour rappel les nouveaux paquets entrent dans unstable et passent dans testing après 10 jours sans rapport de bug critique.
Tous les 3 ans il y a un grand freeze de testing pour corriger tous les bugs avant de passer en stable.
En stable, seules les mises à jour de sécurité sont appliquées pour avoir un système au comportement qui ne bougera plus pendant des années.
Les mainteneurs de paquets Debian sont des développeurs qui vont modifier les patchs pour porter le correctif de sécurité d'openssh 9 vers la 8 pat exemple si nécessaire.