Existe-il un moyen de cr=E9er un environnement cloisonn=E9(plus l=E9ger que=
la
virtualisation) pour =E9viter la contamination de syst=E8me (debian) si je =
dois
installer un binaire propri=E9taire ?
Il existe aussi des binaires propri=E9taire en paquet debian, mais le
probl=E8me est le m=EAme...
<div dir=3D"ltr"><div><div><div>Bonjour =E0 tous, <br><br></div>Existe-il u=
n moyen de cr=E9er un environnement cloisonn=E9(plus l=E9ger que la virtual=
isation) pour =E9viter la contamination de syst=E8me (debian) si je dois in=
staller un binaire propri=E9taire ?<br>
Il existe aussi des binaires propri=E9taire en paquet debian, mais le probl=
=E8me est le m=EAme...<br><br></div>Merci d'avance.<br><br>-- <br></div=
>Beno=EEt<br><div><div>=A0 <br></div></div></div>
--bcaec548aadf75953904e124ec04--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/CAK_7-eS4+qKQvRL9c+L9RGs_HGa==+9-ZZtLg6sDorc92Am91w@mail.gmail.com
On Wed, Jul 10, 2013 at 08:59:59PM +0200, admini wrote:
et bien, d'un point de vu sécuritaire, c'est au contraire, plus simple à gérer. les stacks sont identiques, il faut bien sur mettre à jour tous les jails et le serveur hébergeur. moyennant un reboot bien entendu. mais le boulot est le même si les serveurs font tourner la même version d'apache. en cas de découverte d'une faille, tous les serveurs apache doivent être mis à jour.
Ok, donc pas d'intérêt par rapport à une éventuelle vulnérabilité dans la stack,
l'autre avantage du jail au stack indépendant (c'est le cas sous BSD, et très probablement sous debian), c'est qu'on peut firewaller, donc gérer les politiques de sécurité de façon totalement indépendante pour chacun des jail, flager les options du stack (QoS, Vlans, interface virtuelle pour les SAN...) selon les besoins de chacun.
mais une configuration plus simple dans la mesure où on configure n fois un système simple, au lieu de 1 fois un système complexe. Ça se défend.
d'ailleurs, les failles de sécurité touchant le stack de BSD .... à part ces fameuses backdoors de FBI dans IPsec, pour peu que quelqu'un se serve encore de ca dans le monde libre, j'en connais pas.
Le fait qu'on n'en connaisse pas ne veut pas dire qu'il n'y en a pas :-) Garantir une absence de vulnérabilité, c'est très, très difficile.
l'autre avantage du jail, est la perfe. [...]
C'est clair, pas de problème là dessus (je suis moi-même nettement plus fan de LXC que de Xen pour la même raison).
Y.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
On Wed, Jul 10, 2013 at 08:59:59PM +0200, admini wrote:
et bien, d'un point de vu sécuritaire, c'est au contraire, plus
simple à gérer. les stacks sont identiques, il faut bien sur mettre
à jour tous les jails et le serveur hébergeur. moyennant un reboot
bien entendu. mais le boulot est le même si les serveurs font
tourner la même version d'apache. en cas de découverte d'une faille,
tous les serveurs apache doivent être mis à jour.
Ok, donc pas d'intérêt par rapport à une éventuelle
vulnérabilité dans la stack,
l'autre avantage du jail au stack indépendant (c'est le cas sous
BSD, et très probablement sous debian), c'est qu'on peut firewaller,
donc gérer les politiques de sécurité de façon totalement
indépendante pour chacun des jail, flager les options du stack (QoS,
Vlans, interface virtuelle pour les SAN...) selon les besoins de
chacun.
mais une configuration plus simple dans la mesure où on
configure n fois un système simple, au lieu de 1 fois
un système complexe. Ça se défend.
d'ailleurs, les failles de sécurité touchant le stack de BSD .... à
part ces fameuses backdoors de FBI dans IPsec, pour peu que
quelqu'un se serve encore de ca dans le monde libre, j'en connais
pas.
Le fait qu'on n'en connaisse pas ne veut pas dire qu'il n'y
en a pas :-) Garantir une absence de vulnérabilité, c'est
très, très difficile.
l'autre avantage du jail, est la perfe. [...]
C'est clair, pas de problème là dessus (je suis moi-même
nettement plus fan de LXC que de Xen pour la même raison).
Y.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20130710214813.GG17718@naryves.com
On Wed, Jul 10, 2013 at 08:59:59PM +0200, admini wrote:
et bien, d'un point de vu sécuritaire, c'est au contraire, plus simple à gérer. les stacks sont identiques, il faut bien sur mettre à jour tous les jails et le serveur hébergeur. moyennant un reboot bien entendu. mais le boulot est le même si les serveurs font tourner la même version d'apache. en cas de découverte d'une faille, tous les serveurs apache doivent être mis à jour.
Ok, donc pas d'intérêt par rapport à une éventuelle vulnérabilité dans la stack,
l'autre avantage du jail au stack indépendant (c'est le cas sous BSD, et très probablement sous debian), c'est qu'on peut firewaller, donc gérer les politiques de sécurité de façon totalement indépendante pour chacun des jail, flager les options du stack (QoS, Vlans, interface virtuelle pour les SAN...) selon les besoins de chacun.
mais une configuration plus simple dans la mesure où on configure n fois un système simple, au lieu de 1 fois un système complexe. Ça se défend.
d'ailleurs, les failles de sécurité touchant le stack de BSD .... à part ces fameuses backdoors de FBI dans IPsec, pour peu que quelqu'un se serve encore de ca dans le monde libre, j'en connais pas.
Le fait qu'on n'en connaisse pas ne veut pas dire qu'il n'y en a pas :-) Garantir une absence de vulnérabilité, c'est très, très difficile.
l'autre avantage du jail, est la perfe. [...]
C'est clair, pas de problème là dessus (je suis moi-même nettement plus fan de LXC que de Xen pour la même raison).
Y.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
