Renseignements sur la sécurité de Debian

Support Debian
#1

Bonjour à vous,

J’ai une petite question, vu qu’il semble y avoir des connaisseurs de Debian : comment se fait la gestion de la sécurité de Debian pour des logiciels d’utilisation quotidienne pour bureau ?

C’est pas très clair, je m’explique : J’ai Lenny sur un système et en 1 an d’utilisation, il ne me propose pas de mise à jour de sécurité pour des logiciels comme Firefox, Thunderbird (leurs noms équivalent Debian), Pidgin, etc… . La version a beau être ancienne comment se fait-il qu’il n’y ait pas beaucoup correctif à télécharger ?

Comme exemple, je vais prendre un moment un peu vieux maintenant (à l’époque de Etch stable) : la faille mondiale qui a touché SSL (pas celle de Debian qui est plus récente). Je me souviens que tous les gros “morceaux d’Internet” se sont transmis le message en toute confidentialité pour sortir un patch à leur produit à peu près en même temps… Je me souviens que sous Debian Etch , il n’y a jamais eu de mise à jour pour SSL (pourtant stable), ce qui fait que l’accès à Gmail (enter autre) m’a dès lors toujours été refusé avec mon navigateur Iceweasel 1.5 je crois à l’époque.

Et de manière générale, il y a peu de mise à jour proposées. Évidemment le fait que ce soit une version stable y est pour quelque chose, mais n’est pas un argument valable pour des failles de sécurité (médiatisées, je connais que ceux-là) découverts après la sortie de ladite version stable (le bug n’a pas pu être corrigé)… Les seules mises à jour que je vois sur Debian c’est des trucs internes comme Linux, libc6, etc…

Alors que ce passe-t-il ? manque de suivi de la part de Debian ? Ou alors, ai-je loupé quelque chose ? (plus probable à mon avis).
J’ai pourtant le dépôt de sécurité dans mon sources.list tel qu’ajouté de base par l’installateur et signalé dans la plupart des tuto sur Internet que j’ai consulté.

Si dans la Squeeze qui va sortir avec MoFo 3.5.12, une faille de sécurité est découverte et aucune mise à jour n’est proposée par Debian, le système reste-t-il sensible à cette faille ?

Debian stable est-ce alors une bonne solution longue durée pour un PC connecté au Web ?

La comparaison ne va peut-être pas plaire mais c’est ce qui ressemble le plus à Debian, Ubuntu propose bien des mises à jours quelques jours après la déclaration de la faille (par exemple la faille de SSL avait été corrigée par Ubuntu). Je ne critique pas Debian, je souhaite comprendre le fonctionnement et pallier à ce problème plutôt :slightly_smiling:

Merci d’avance pour vos explications. :smiley:

#2

Salut,

Ben comme ça http://www.debian.org/security/,
comme ça http://www.debian.org/security/faq,
et notamment comme ça http://www.debian.org/security/faq#version.

Si tu n’as pas vu de mises à jour de sécurité sur ta lenny relativement récente, c’est que les failles ont été colmatées au fur et à mesure des évolutions de lenny. On en est à la version 5.0.5 de lenny. Les évolutions de lenny intègrent naturellement ces correctifs.
Parmi des logiciels que tu cites, les mises à jour de sécurité ont été d’abord introduites dans les dépôts security puis dans les dépôts “standards”.

Sur ma sid avec un “gros” sources.list, quelques exemples (j’ai mis uniquement les lignes concernant la stable):[quote]apt-cache policy iceweasel icedove pidgin
iceweasel:
3.0.6-3 0
700 security.debian.org stable/updates/main Packages
700 ftp2.fr.debian.org stable/main Packages

icedove:
2.0.0.24-0lenny1 0
700 security.debian.org stable/updates/main Packages
700 ftp2.fr.debian.org stable/main Packages

pidgin:
2.4.3-4lenny7 0
700 security.debian.org stable/updates/main Packages
700 ftp2.fr.debian.org stable/main Packages
[/quote]

J’espère que c’est à peu près clair ce que je raconte :119 :030 :laughing:

#3

Tu as bien les lignes que te donne Talogue, dans ton sources.list :question:

#4

Salut,

Et j’ajoute que main contrib non-free à moins d’avoir été très rigoureux lors des installations est une bonne chose en mise à jour car je ne suis sûr que certains paquets soient absolument “purs”

#5

[quote=“ggoodluck47”]Salut,

Et j’ajoute que main contrib non-free à moins d’avoir été très rigoureux lors des installations est une bonne chose en mise à jour car je ne suis sûr que certains paquets soient absolument “purs”[/quote]

bonjour,

peux tu expliquer un peu plus je ne comprends pas ta phrase.

merci.

#6

C’est bizarre l’histoire avec SSL car dès qu’une faille est détectée elle est généralement corrigée et mise à disposition dans les dépôts de sécurité dans les 2-3 jours qui suivent. Donc je ne sais pas ce qui a pu se passer. Peut être que c’était tout simplement le protocole en tant que tel qui était défaillant et donc qu’il aurait carrément fallu changer de version de SSL ? (comme pour les clés WEP : on peut mettre à jour autant qu’on veut le logiciel qui gère les clés, la clé WEP reste merdique, il faut utiliser un autre type de clé à la place, le WPA ; je pense que c’était le même problème ici : si SSL vX est cassé à cause de sa conception et pas de son implémentation, il faudra passer à la version SSL vX+1 pour résoudre le problème)

Il y a peu de mises à jour de sécurité car la Stable a été testée et retestée pendant longtemps par beaucoup de monde avant de sortir, et la conception de Linux permet d’avoir une sécurité intrinsèque, donc les failles sont limitées.

#7

[quote=“mksmn”][quote=“ggoodluck47”]Salut,

Et j’ajoute que main contrib non-free à moins d’avoir été très rigoureux lors des installations est une bonne chose en mise à jour car je ne suis sûr que certains paquets soient absolument “purs”[/quote]

bonjour,

peux tu expliquer un peu plus je ne comprends pas ta phrase.

merci.[/quote]

A moins d’avoir passé juste avant ce fameux paquet (dont le nom m’échappe) de Stallman détectant que tu n’as rien installé de non-free et contrib il vaut mieux les avoir également en mise à jour. Eux aussi sont susceptibles d’avoit des trous de sécurité :slightly_smiling:

#8

bonjour,

ok merci de ta réponse.

#9

@talogue : Ouais tout est bien configuré comme tu l’indiques, cependant je n’ai pas beaucoup de mises à jour (les rares fois où je connecte mon PC au Web pour faire des majs). Mais merci donc de me confirmer que c’est normal (c’est moi qui fait du zèle avec la sécurité :033 ). Je m’inquiète peut-être pour rien, je trouve juste étrange de pas voir autant de mises à jour pour les même logiciels sur Ubuntu que sur Debian stable…

Regarde, quand je vais sur le site de Debian, en bas de la page il y a les annonces de sécurité, pourquoi aucune de ces majs ne me sont proposées (le problème ne semble pas venir du fait que le paquet n’a pas encore été reconstruit, vu que des liens le proposent au téléchargement des versions corrigées suivant les différentes architectures) ? Ai-je choisi un mauvais dépôts lors de la netinstallation (ftp2.debian.fr) ?

Autre solution possible : Je me demandais aussi une chose : mettre en place le système de backports pour les logiciels anciens qui ont rapport au Web sur une Debian stable, ça peut peut-être régler les histoires de versions trop anciennes et peut-être faillibles pour les logiciels connectés au Web non ?

@ggoodluck47 : Ouais c’est bien activé, même si je n’utilise pas de logiciels proprio (à part les pilotes Nvidia)

@Cluxter : L’histoire de SSL il me semble remonte à 2008, voila un lien qui explique à peu près : lyoba.ch/lagruyere/article293.htm
Debian n’a jamais proposé de majs (pourtant tous les dépôts étaient bien configurés), ce qui fait que Google me refusait la connection à Gmail à l’époque (il me parlait d’une maj de SSL à faire avant de pouvoir se connecter).

@ggoodluck47 : le nom du paquet c’est VRMS

#10

bjr ubuntu est plus basé sur une testing , ubuntu grosso modo propose autant de mises a jour qu’une squeeze sous debian

quant a savoir si une lenny est complètement sécurisée je laisseles specialistes entre eux , a priori je dirais plutot oui

#11

[quote=“Heliox”]Je m’inquiète peut-être pour rien, je trouve juste étrange de pas voir autant de mises à jour pour les même logiciels sur Ubuntu que sur Debian stable…[/quote]Parceque la stable n’évolue principalement que pour mettre en place les correctifs de sécurité.
Je m’explique avec comme exemple iceweasel.
La version présente dans le main stable est la 3.0.6-3 0.
C’est la même dans le main security 3.0.6-3 0 où elle a été introduite en premier.
Oui elle intègre les correctifs de sécurité nécessaire. La faq explique que [quote]Au lieu de passer à une nouvelle version, nous réalisons un rétroportage (“backport”) de la rustine de sécurité vers la version fournie dans la distribution stable. La raison pour laquelle nous faisons cela est qu’une version publiée (“release”) change aussi peu que possible[/quote]
Mais ce n’est pas un backport au sens des nouvelles fonctionnalités présentes dans le dépôt backport/lenny. C’est simplement un portage de la rustine de sécurité vers la version de lenny. C’est le security debian et non le dépôts backport !!!

Autre chose, si lorsque tu installe ta lenny, tu prends la dernière version en date soit la 5.0.5, elle intègre déjà les correctifs de sécurité. C’est même pour ça qu’elle existe cette version. Du coup le dépôt standard, lorsque sort la lenny 5.0.5, possède la même version de iceweasel que le security. Donc, il n’est plus à mettre à jour !!!

#12

[quote]@Cluxter : L’histoire de SSL il me semble remonte à 2008, voila un lien qui explique à peu près : lyoba.ch/lagruyere/article293.htm
Debian n’a jamais proposé de majs (pourtant tous les dépôts étaient bien configurés), ce qui fait que Google me refusait la connection à Gmail à l’époque (il me parlait d’une maj de SSL à faire avant de pouvoir se connecter).[/quote]
C’est ce que je t’ai expliqué : une Stable intègre une certaine version maximale de chaque logiciel. Ainsi, si un problème de conception est découvert dans un protocole de version 1 par exemple, et qu’il faut passer à la version 2 pour le résoudre (par exemple passer du WEP au WPA), dans ce cas il n’y aura pas de mise à jour de sécurité dans la Stable qui pourra résoudre ce problème. Les mises à jour de sécurité ne concernent que les problèmes d’implémentation des protocoles (comprendre : les mises à jour de sécurité peuvent résoudre les bugs de sécurité mais ne sont pas là pour réécrire un protocole mal conçu).

#13

C’est sympa çà, mais ça existe déjà et ça s"appelle deb security.debian.org/ lenny/updates main contrib non-free. :wink:
A ne pas pas confondre avec http://www.backports.org/ qui explique justement que [quote]Q: Is there security support for packages from backports.org?

A: Unfortunately not.[/quote]

#14

Bon ben je fais un test alors :
Je vais donc là http://www.debian.org/security/#DSAS et choisis au hasard http://www.debian.org/security/2010/dsa-2076
Je lis que [quote]For the stable distribution (lenny), this problem has been fixed in version 2.0.9-3.1+lenny1.[/quote].
Je constate en effet que [quote=“apt-cache policy gnupg2”]
gnupg2:
Installé : (aucun)
…ceci concernait testing et unstable
J’ai supprimé ces lignes pour plus de lisibilité…
2.0.9-3.1+lenny1 0
700 security.debian.org stable/updates/main Packages
2.0.9-3.1 0
700 ftp2.fr.debian.org stable/main Packages[/quote]
Le patch de sécurité est bien arrivé dans le security de la stable.
Si dans quelques temps sort la lenny 5.0.6, le patch sera alors inclu dans la version de gnupg2 des dépôts main stable. En attendant, c’est la ligne security de ton sources.list qui assure la sécurité.
C’est clair non ?
Où est le problème alors ? qu’est ce que tu ne comprends pas ??

#15

[quote=“Cluxter”][quote]@Cluxter : L’histoire de SSL il me semble remonte à 2008, voila un lien qui explique à peu près : lyoba.ch/lagruyere/article293.htm
Debian n’a jamais proposé de majs (pourtant tous les dépôts étaient bien configurés), ce qui fait que Google me refusait la connection à Gmail à l’époque (il me parlait d’une maj de SSL à faire avant de pouvoir se connecter).[/quote]
C’est ce que je t’ai expliqué : une Stable intègre une certaine version maximale de chaque logiciel. Ainsi, si un problème de conception est découvert dans un protocole de version 1 par exemple, et qu’il faut passer à la version 2 pour le résoudre (par exemple passer du WEP au WPA), dans ce cas il n’y aura pas de mise à jour de sécurité dans la Stable qui pourra résoudre ce problème. Les mises à jour de sécurité ne concernent que les problèmes d’implémentation des protocoles (comprendre : les mises à jour de sécurité peuvent résoudre les bugs de sécurité mais ne sont pas là pour réécrire un protocole mal conçu).[/quote]
Donc la Stable serait sensible aux failles sur ledit logiciel ? Etonnant :119

On se calme là, j’ai bien compris ce que tu voulais dire. Je demandais juste si le choix du dépôt backport était une solution viable pour à la fois corriger les failles et profiter de nouvelles fonctions pour des logiciels liés au Web :023 .

[quote=“talogue”]A ne pas pas confondre avec backports.org/ qui explique justement que

[quote]Q: Is there security support for packages from backports.org?

A: Unfortunately not.[/quote][/quote]
OK merci, voila ce que je cherchais, merci

Edit :

[quote]C’est clair non ?
Où est le problème alors ? qu’est ce que tu ne comprends pas ??[/quote]
Rien, apparemment j’avais bien compris depuis le début. Y a juste des mises à jour que j’ai pas… Mais bon, merci de m’avoir réexpliqué le fonctionnement. Maintenant je sais que le problème doit venir de la configuration,j’ai pas mon PC sous la main là, mais dès que je l’ai je recherche :wink:

#16

Oui. Si tu utilises une clé WEP sur ta Stable et que tu te fais pirater ton réseau Wi-Fi, tu peux faire tout ce que tu veux comme patchs de sécurité ça ne sert à rien car ce n’est pas un problème d’implémentation mais un problème de conception du protocole. Il faudra utiliser du WPA à la place. Et ça, ce n’est pas à la team Debian de choisir quoi installer sur ton ordi :wink: Si l’utilisateur final souhaite utiliser un protocole en mousse, c’est son problème. C’est pareil pour SSL : s’il souhaite utiliser la v1 toute moisie parce que les mathématiciens n’ont pas pensé l’algorithme correctement :mrgreen: on ne va pas le forcer à utiliser la v2 qui est d’une conception totalement différente et incompatible avec la v1.

#17

Oui. Si tu utilises une clé WEP sur ta Stable et que tu te fais pirater ton réseau Wi-Fi, tu peux faire tout ce que tu veux comme patchs de sécurité ça ne sert à rien car ce n’est pas un problème d’implémentation mais un problème de conception du protocole. Il faudra utiliser du WPA à la place. Et ça, ce n’est pas à la team Debian de choisir quoi installer sur ton ordi :wink: Si l’utilisateur final souhaite utiliser un protocole en mousse, c’est son problème. C’est pareil pour SSL : s’il souhaite utiliser la v1 toute moisie parce que les mathématiciens n’ont pas pensé l’algorithme correctement :mrgreen: on ne va pas le forcer à utiliser la v2 qui est d’une conception totalement différente et incompatible avec la v1.[/quote]
OK? bon je t’embête, mais c’est la dernière fois :033
Sans parler de Wi-fi, juste l’utilisation lors d’une connection d’un serveur à un client avec un chiffrement SSL, pourquoi Debian n’a pas proposé de maj de SSL pour la version Etch (à l’époque) ? Bien que tu donnes tu explications défendant le fait de garder la v1 au cause des risques d’incompatibilité d’une v2 pour une version stable (c’est vrai ça ferait tache). Mais pourquoi pour la version LTS d’Ubuntu, une maj a été proposée et réglait le problème avec Gmail ? Debian préfererait-elle ne pas prendre le risque de mettre à jour vers une version nouvelle (aka incompatibilités possibles) quitte à garder une grande vulnérabilités d’un point de vue sécurité ?

Je me souviens avoir quitté le navire une semaine après, vu que Debian ne proposait rien devant le risque de sécurité non-négligeable (très médiatisé à l’époque) et que je ne pouvais consulter mes mail, j’étais reparti sur mon Ubuntu…

Je cherche à comprendre pourquoi pour anticiper un cas semblable futur et savoir prendre en mains mon système à cette occasion… :slightly_smiling:

Merci de ta patience

#18

Et oui. C’est à l’administrateur de veillez à ce qui est installé sur le système. S’il laisse la v1 qui a une faille intrinsèque, c’est son choix et son problème. Personne n’oserait encore utiliser par exemple une méthode de chiffrement par translation utilisée au temps de Jules César… C’est un peu pareil, sur une échelle de temps plus petite. La v2 de SSL n’a rien à voir avec la v1, c’est un autre logiciel. Donc il faut désinstaller SSL v1 et installer un autre logiciel à la place, SSL v2.

Le problème c’est que peut être que SSL v2 n’existait pas encore quand la Stable est sortie, ce qui implique qu’il ne pouvait pas être disponible par la suite pour Etch étant donné qu’une fois que la Stable est publiée on ne peut plus ajouter de nouvelles versions de logiciels. Pour cela, il faut attendre la prochaine Stable (ou utiliser Testing ou Sid). Donc effectivement on se retrouve dans une situation où la Stable est soit obligée d’utiliser un vieil algorithme en mousse, soit ne rien utiliser du tout. On est d’accord, c’est très embêtant… Mais ce qui prime, c’est la stabilité de Debian : hors de question qu’une machine qui fait tourner une usine où travaillent 150 personnes s’arrête d’un coup à cause d’un bug de stabilité provenant de SSL v2 ! Imagine les conséquences ! Le but de la Stable, c’est d’être… stable, quoiqu’il arrive, avant d’être sécurisée.

Si l’on souhaite un OS stable et sécurisé, alors on se tourne vers UNIX (pour un UNIX libre et très sécurisé : OpenBSD, ou FreeBSD à la limite). Le but de Linux n’a jamais été d’être hautement sécurisé (Linus Torvald le dit lui-même, il ne comprend pas les gens qui cherchent à tout prix à sécuriser un OS : generation-nt.com/openbsd-to … 24041.html), mais d’être libre, compatible avec les ix86 et adaptable à tout type de besoin. La Debian Stable est conçue pour ne jamais planter, quoiqu’il arrive, même si la confidentialité des données est en jeu. Ce qu’on veut, c’est une machine qui ne s’arrêtera pas.

Imagine que la seule machine qui reste pour sauver le monde tourne sous Debian (scénario ultra probable d’ailleurs) :mrgreen: pendant qu’un astéroïde géant nous fonce droit dessus :geek: avec des fourmis géantes à son bord :119 qui fument des pétards :033 et mangent de la chicorée :106 en regardant MaTrique :12 et en buvant du jus de poule pas frais :117 : tu te fous qu’on accède à tes données, tout ce que tu veux, c’est que ta machine continue de tourner, sinon c’est la perte de l’Humanité !!! :100

#19

OK, mais c’est étrange, on a toujours répété que Debian c’est top niveau sécurité…

Pour parvenir à une système semblable à Ubuntu à l’utilisation, c’est-à-dire configuré pour un utilisateurs lambda, à quelle configuration du système doit-on procéder ?

Voila à quoi je procède :

  • installation en netinstall, je coche les cases “environnement de bureau” et “système standard”
  • j’active le pare-feu (via la commande : # ufw enable)
  • j’ajoute les dépôts multimedia
  • installation des logiciels complémentaires + pilotes proprio
    Et ça roule

Voila ce que je fais lorsque je migre vers Debian.
Toi qui t’y connais,peux-tu me dire ce que je dois faire d’autre au niveau de la sécurité ou autre ? ou alors me conseiller certaines choses que j’ai oublié.
Je cherche à prendre mon système en main :slightly_smiling:
Merci

#20

Comme dit l’expression : “On est un con” ^^
C’est bien mieux que certains OS (vous devinez de quoi je parle), mais ce n’est rien comparé à UNIX niveau sécurité.

Alors là… :open_mouth:
J’essaye déjà de bien comprendre comment fonctionne Debian de A à Z, seulement après je pourrai te dire ça ! (dans quelques années donc lol)