Re: securité et sources.list
* OLIVIER LAMBERT [EMAIL PROTECTED] [2003-01-09 00:55] : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Je me posais une petite question sur la sécu... Comment est gérée la sécurité quand on a diverses entrées dans son sources.list ? Je m'explique.. : A titre d'exemple, si je mets le lien de marillat pour Mplayer (c'est juste un exmple), comment je suis sûr que d'autres packages sont pas mis à jour si je ne spécifie pas de liste de packages autorisés (ce dont je ne suis pas sur que ce soit possible). Tu peut utiliser le principe du Apt-pinning pour n'autoriser que certaines mises à jour pour certains paquets. (voir par exemple le APT-HOWTO du paquet apt-howto ou en ligne, http://www.debian.org/doc/manuals/apt-howto/). Sachant tout de même que si la sécurité te concerne, il est préférable de ne pas avoir de sources exotiques car il suffit d'un seul paquet pour mettre par terre un système tout entier (pense, par exemple, à un postinst qui ferait un rm -Rf /). Après, tout dépend de la confiance que tu accordes à l'empaqueteur et à l'importance que tu donnes à ton système (pour un système de production, il faut être plutôt trop paranoïaque que trop laxiste). Ensuite, il existe le Securing Debian Manual (http://www.debian.org/doc/manuals/securing-debian-howto/ et disponible dans le paquet harden-doc), malheureusement pas encore en français (d'après le CVS, une traduction serait en cours), mais très intéressant. Fred
Re: securité et sources.list
OLIVIER LAMBERT [EMAIL PROTECTED] writes:
[...]
A titre d'exemple, si je mets le lien de marillat pour Mplayer (c'est juste
un
exmple), comment je suis sûr que d'autres packages sont pas mis à jour
si je ne spécifie pas de liste de packages autorisés (ce dont je ne suis
pas sur que ce soit possible).
Je ne sais pas si j'ai été très clair, mais je ne voudrais pas que des vers
soient introduits par une mise à jour...
Pour info mon site supporte la signature gpg des fichiers Packages{gz}
comme ceux des paquets officiels.
Pour l'installation :
http://free2.org/d/
Autrement en ce qui concerne les paquets non-officiels il n'y a aucun
moyen de savoir si ils sont fiables ou non, et le mieux est de ne pas
mettre ses adresses ton le sources.list
Christian
Re: securité et sources.list
Pour info mon site supporte la signature gpg des fichiers Packages{gz}
comme ceux des paquets officiels.
Juste par curiosité, quel est le rapport entre la signature gpg et la
protection contre l'occurence (certainement ;-) involontaire d'un rm
-rf / dans un script quelconque... ??
(on peut imaginer un rm -rf /temp dans un postrm avec un CR mal placé
juste derrière le /, avant de sauvegarder, d'empaqueter et de livrer le
.deb tout beau)
Autrement en ce qui concerne les paquets non-officiels il n'y a aucun
moyen de savoir si ils sont fiables ou non, et le mieux est de ne pas
mettre ses adresses ton le sources.list
La véritable sécurité octroyée par le fait qu'il y ai un site officiel
n'a rien à voir (dans ces cas là) avec la signature gpg mais juste par
le fait que le site officiel tombera avant la machine du
pov'utilisateur, et encore en supposant que la machine qui recompile (et
qui exécutera la bombe, quelle que soit la nature de cette dernière)
soit en amont de celle qui sert les paquets.
Un site officiel peut être vu comme un super-fusible...
Et encore, si j'ai bien compris les paquets i386 ne passent (toujours)
pas par les autobuilders donc le temps qu'on s'aperçoive d'un problème
quelques utilisateurs de Sid tomberont dans les pommes.
Les clés pgp ne sont pas des _protections_ mais simplement des éléments
de traçabilité et d'intégrité. S'il y a un pépin, on a des chances de
remonter à la source et c'est donc paraît-il dissuasif. De même, si un
mainteneur Debian fait une bourde, le fait de signer son paquet ne va
pas virer la bourde ... (si j'ai bien compris gpg, évidemment)
PS : Avant de crier à la désinformation éhontée, merci de passer par la
case debian-devel et d'y retrouver la discussion concernant les moyens à
mettre en oeuvre pour protéger les machines officielles de ce genre de
mésaventures.
(same player, chroot again ;-)
PS2 : évidemment, tout dépend de la définition que l'on donne à
fiable.
A+
--
mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06
INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59
BP 317 -- 59666 Villeneuve d'Ascq
http://www3.inrets.fr/estas/mariano
Re: securité et sources.list
On Thu, Jan 09, 2003 at 16:19:36 +0100, Raphaël SurcouF wrote: A la rigueur, on peut mettre une sarge ou testing, les 15 jours de quarantaine permettent de se prémunir de ce genre de risques: un paquet ne doit pas avoir eu de bug majeur reconnu durant 15 jours avant de passer dans la série testing. Le problème est que les paquets de testing ont des trous de sécurité. En effet, les trous de sécurité sont corrigés pour les versions stables et pour sid (unstable), mais généralement pas pour testing. Il faut donc attendre que les versions de sid passent dans testing, mais ça peut prendre des mois! En effet, tant qu'il y a une dépendance à un paquet unstable (e.g. en ce moment la libc), le paquet ne peut pas passer en testing. Bref, je suis en testing, et quand il y a un trou de sécurité, je downgrade ou j'upgrade le paquet concerné en unstable. Je ne fais plus d'upgrade automatique (apt-get upgrade), car les paquets downgradés seraient automatiquement upgradés en testing et se retrouveraient de nouveau avec le trou de sécurité. Donc je fais un apt-get upgrade -s, puis un apt-get install les paquets que je veux. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Re: securité et sources.list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Tu peut utiliser le principe du Apt-pinning pour n'autoriser que - -- certaines mises à jour pour certains paquets. (voir par exemple le - -- APT-HOWTO du paquet apt-howto ou en ligne, - -- http://www.debian.org/doc/manuals/apt-howto/). je vais jetter un coup d'oeil... malheureusement, les todo commencent à s'entasser sur mon emploi du temps... :p - -- Sachant tout de même que si la sécurité te concerne, il est préférable - -- de ne pas avoir de sources exotiques car il suffit d'un seul paquet - -- pour mettre par terre un système tout entier (pense, par exemple, à un - -- postinst qui ferait un rm -Rf /). Après, tout dépend de la confiance - -- que tu accordes à l'empaqueteur et à l'importance que tu donnes à ton - -- système (pour un système de production, il faut être plutôt trop - -- paranoïaque que trop laxiste). Je suis d'accord avec toi, et dans les sytèmes en prod, je reste assez parano... :p Mais la portée de ma question est légèrement différente... La question pour moi est relativé à la portée des actions du semi-newbi (comme moi :p) qui commence à importer des sources (pour le jdk, par ex), mais qui n'a pas encore l'expérience nécessaire pour blinder son système... Et je voulais savoir les fusibles dont disposait une débian de base (comme quoi, je commence à devenir un vrai utilisateur conscient de sécurité :D) Merci, Olivier -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 -- QDPGP 2.65 Comment: http://community.wow.net/grt/qdpgp.html iQA/AwUBPh4a325Gr56w0qKDEQIcdQCfYUit6P/J1pvufTmJ7NSGCIVelDYAnA1R oOxtFV+n7AxUFAyDxUcbvZll =AjZ6 -END PGP SIGNATURE-
securité et sources.list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Je me posais une petite question sur la sécu... Comment est gérée la sécurité quand on a diverses entrées dans son sources.list ? Je m'explique.. : A titre d'exemple, si je mets le lien de marillat pour Mplayer (c'est juste un exmple), comment je suis sûr que d'autres packages sont pas mis à jour si je ne spécifie pas de liste de packages autorisés (ce dont je ne suis pas sur que ce soit possible). Je ne sais pas si j'ai été très clair, mais je ne voudrais pas que des vers soient introduits par une mise à jour... Alors ? Merci de vos éclairaiges, Olivier -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 -- QDPGP 2.65 Comment: http://community.wow.net/grt/qdpgp.html iQA/AwUBPhy6e25Gr56w0qKDEQKKigCeJe+jv/3ZStqGF5HVWfR4hh3EZUcAoPtv XCiNj2dEq2ursOsyYlv4aRUu =sGcb -END PGP SIGNATURE-
