Bertrand Yvain a écrit 6 commentaires

/*
* exploit for x86_64 linux kernel ia32syscall emulation (again)
* rediscovered by ben hawkes
* with help from robert swiecki and tavis ormandy
*
* original vulnerability discovered by Wojciech Purczynski
*
* original exploit by
* Robert Swiecki <robert_at_swiecki.net>
* Przemyslaw Frasunek <venglin_at_freebsd.lublin.pl>
* Pawel Pisarczyk <pawel_at_immos.com.pl>
*
* kernel priv escalation code borrowed from spender
*
*/

Mais :

/*

Ac1dB1tch3z Vs Linux Kernel x86_64 0day

Today is a sad day..

R.I.P.
Tue, 29 Apr 2008 / Tue, 7 Sep 2010

a bit of history:
MCAST_MSFILTER Compat mode bug found... upon commit! (2 year life on this one)

author David L Stevens <dlstevens@us.ibm.com>
Tue, 29 Apr 2008 10:23:22 +0000 (03:23 -0700)
committer David S. Miller <davem@davemloft.net>
Tue, 29 Apr 2008 10:23:22 +0000 (03:23 -0700)
This patch adds support for getsockopt for MCAST_MSFILTER for
both IPv4 and IPv6. It depends on the previous setsockopt patch,
and uses the same method.

Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
------------------------------------------------------------

Thank you for signing-off on this one guys.

This exploit has been tested very thoroughly
over the course of the past few years on many many targets.

Thanks to redhat for being nice enough to backport it into early
kernel versions (anything from later August 2008+)

Ac1dB1tch3z would like to say FUCK YOU Ben Hawkes. You are a new hero! You saved the
plan8 man. Just a bit too l8.

PS:
OpenVZ Payload / GRsec bypass removed for kidiots and fame whores. (same thing right ;))

*/

Sauf erreur, Eucalyptus et Enomaly s'attachent à rester compatibles avec l'API d'EC2. Pour les détails d'architecture, je n'ai pas vraiment approfondi pour donner une réponse intéressante :-]

Pas de support de Xen prévu, mais les patches seront examinés avec la plus grand objectivité dont nous sommes capables.

Je n'ai nullement dit que libvirt ne supporte pas KVM (je viens de constater que qumranet a rejoint Redhat, merci pour l'info). libvirt propose une abstraction des différentes solutions de virtualisation, notamment Xen, au prix d'une certaine lourdeur. C'est par ailleurs une belle initiative qui retrouvera peut-être sa place dans nos projets à l'avenir. Pas pour l'instant, seulement...

Comme je te répondais sur une de nos ML (http://lists.src.ielo.net/pipermail/niftyname-users/2009-March/000005.html), le principale problème que nous avons rencontré en utilisant libvirt est que libvirtd ne peut contrôle que ses processus fils (par héritage de file descriptors si je me souviens bien). Si, pour une raison ou pour une autre, libvirtd meurt (crash, restart, etc) les machines virtuelles deviennent incontrôlables, à moins de les tuer (méchamment, grrr) et de les relancer. En terme de gestion, c'est beaucoup trop pénalisant.

Une application cliente peut instancier tout type de ressources en se servant de l'API XML-RPC : http://src.ielo.net/embedded/zinn/index.html

La modification à chaud d'une machine virtuelle est limitée par les capacités de QEMU : ajout/retrait de volumes de stockages pour l'instant. Cela ne fait pas beaucoup de sens de gérer la modification des processeurs et de la mémoire à chaud car le support par le guest est loin d'être généralisé.

Oui, une VM est instanciée sur un nœud. La migration à chaud est cependant supportée.

La redondance intrasite du stockage est déjà implémentée. Les scenarii de redondance intersite sont esquissés mais il y a encore beaucoup de code à faire. En matière de sécurité, cela dépendra surtout des OS guest, mais les précautions ont été prises pour éviter tout type de spoofing sur les vlans publics (notamment avec ebtables). Pour le load-balancing, cela sera géré par les nœud d'accès au réseau, avec LVS sans doute.

Si vous êtes intéressés par ces aspects de haute disponibilité et allocation dynamique de ressources, essentiels pour les phases à venir du projet, je vous invite à participer.

Nous avons renoncé à utiliser libvirt qui pose de nombreux problèmes dans un environnement de production. De plus, libvirt supporte principalement Xen, que nous avons écarté aussi, trouvant KVM plus prometteur.

C'est toi.

D'après mon expérience (avec EC2, du moins) la notion de machine virtuelle est fondamentale : http://aws.amazon.com/ec2/#instance

Quant à l'attribution automatique de ressources en fonction des besoins, ce n'est pas encore dans NiftyName, mais ça va venir.