[Sécurité] Les dépots

[toma222]

Bonsoir,

J'utilise Arch depuis maintenant pas loin d'un an et je suis totalement fan de cette distribution.

Il y a malheureusement une chose qui me chagrine et qui est liée à la sécurité. En effet, aucun contrôle n'est fait lorsqu'on se connecte à un serveur de paquets. Donc rien ne prouve que quand je fais mes mises à jour sur ftp://ftp.archlinux.org/ (ou http://repo.archlinux.fr/) je sois réellement connecté à ces serveurs. Il n'existe pas de clé GPG comme sous Debian ou Ubuntu par exemple.

Le sujet a été discuté sur le forum officiel et une feature request a été déposée il y a plus d'un an (et à laquelle Phrakture a déclaré il y a peu de temps qu'ils avaient d'autres priorités), mais il ne semble rien y avoir en cours.

J'aurais simplement voulu savoir ce que vous en pensiez et si comme moi vous trouviez cela assez inquiétant ?

[marc[i1]]

Salut,

il existe une solution que propose Slubman sur son blog :
http://www.slubman.info/ticket/15/vrifi ... ar-pacman/

[toma222]

Ah oui, effectivement j'avais déjà lu cet article (et l'avais oublié au passage...).

En effet, c'est une solution intéressante, mais est-ce que dans la pratique les serveurs permettent de vérifier leurs authenticités par les clients ?

[toma222]

J'essaie d'utiliser cette méthode, mais je rencontre un soucis avec le dépôt community. J'ai cette erreur sur la plupart des serveurs :

Code : Tout sélectionner

curl: (64) Requested SSL level failed

et :

Code : Tout sélectionner

curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). The default
 bundle is named curl-ca-bundle.crt; you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Finalement il semble réussir à se connecter sur un serveur (je ne sais pas trop lequel) mais ce dernier ne semble pas être à jour. Il me dit que les versions locales sont plus récentes que celles du dépôt en question.

Est-ce que cela siginifie que la plupart des dépôts community ne gèrent pas SSL ?

Sinon, si cette solution est réellement efficace, est-ce qu'il ne serait pas possible de l'ajouter par défaut à Yaourt (tant qu'il n'y a rien de fait au niveau de Pacman) ?

[warnaud]

Franchement je trouve balaise de faire des repos avec des paquets "non sécurisés" (avec de vils trojans etc...) c'est possible mais super gavant à faire! Il faut se charger les milliers de pkg en démonter un et y glisser du code malfaisant, puis regénérer la db pour pacman c'est quand même s'énerver pour rien non? Je dis pas qu'un peu de sécurité serait pas mieux, mais la plupart du temps, les problèmes viennent du fait que les pkgs ne fonctionnent pas ou que la db n'est pas à jour. J'ai vraiment jamais entendu parlé de piratage de dépôt même sur des grosses distribs.

</mon opinion >

[toma222]

Justement, de mon point de vue c'est relativement simple (surtout avec des "petits" dépôts tel que core, ou le votre, en particulier en x86_64). Un paquet avec "la commande qui va bien" et de nombreux utilisateurs se retrouve avec un système vierge par exemple... Le seul soucis serait bien sûr de réaliser une redirection du DNS.

Ca n'est jamais arrivé sur une "grosse" distrib car à ma connaissance elles intègrent un système de vérification de l'identité des serveurs de dépôt. Et il me semble qu'un serveur Debian s'est déjà fait piraté (même si il n'y avait pas eu de dégâts).

Mon point de vue vous semble peut-être un peu parano, mais il provient d'une discussion récente avec un packageur Ubuntu/Debian qui trouvait cette absence aberrante.

[vincentxavier]

Si la sécurité t'obsède à ce point, il ne te reste qu'à installer une OpenBSD en relisant tous les Makefile un par un et dès que tu as fini de l'installer, tu te déconnectes vite fait du Net !

Oui, la redirection DNS est facile à mettre en place surtout sur des petits dépots etc … mais encore une fois de plus, tant qu'il n'y a que peu d'utilisateur, ca n'intéresse pas vraiment les pirates. Debian a été attaquer car c'est une grosse organisation qui fournit des packages à des milliers de personnes, donc le jeu en vaut la chandelle. Il est plus facile de s'attaquer directement à une machine que d'usurper l'identité d'un dépot d'Arch Linux !

[toma222]

Je ne suis pas obsédé à ce point par la sécurité . Et je suis parfaitement d'accord avec toi, en pratique le risque est faible, d'autant plus que Arch n'est pas vraiment une distrib orientée serveur. Et il existe de nombreux autres endroits où la sécurité peut être mise à défaut.

Mais si une solution simple comme celle proposée par Slubman peut-être mise en place et être un minimum efficace (ce que je cherche maintenant à vérifier), pourquoi ne pas l'utiliser ?

Enfin je voulais simplement avoir votre point de vue sur cette question, merci pour vos réponses.

[nik11]

FreeBSD a un système de port et son système de package binaire n'intègre pas ce genre de vérification, et pourtant c'est un système très utilisé pour les serveurs. Et aussi, quel idiot s'embêterait à lire un code source pour changer quelques fonctions