WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] Xen Security

To: "Jonathan Tripathy" <jonnyt@xxxxxxxxxxx>
Subject: Re: [Xen-users] Xen Security
From: Bart Coninckx <bart.coninckx@xxxxxxxxxx>
Date: Fri, 16 Jul 2010 12:21:02 +0200
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 16 Jul 2010 03:22:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <46C13AA90DB8844DAB79680243857F0F0AFDBC@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <4C3F905E.9030100@xxxxxxxxxxx> <201007161203.10272.bart.coninckx@xxxxxxxxxx> <46C13AA90DB8844DAB79680243857F0F0AFDBC@xxxxxxxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.12.4 (Linux/2.6.31.12-0.2-desktop; KDE/4.3.5; x86_64; ; )
On Friday 16 July 2010 12:12:45 Jonathan Tripathy wrote:
> Jonathan, I will "psychologically" shortcut your question :-)   : you
>  actually really want to do this and you need approval by someone of the
>  list. This is not a good way to handle this matter. Think of the
>  consequences of a security breach, then think about the expenses to avoid
>  this and then come to a conclusion. What you are doing is bottom-up: you
>  have your infrastructure and you wonder if you can bend it in such a way
>  it will give you peace of mind.
> 
> ---------------------------------------------------------------------------
> ---------------------------------------------------------------------------
> -----------
> 
> Bart, I'm asking here because I am not aware of any Xen exploits and
>  breechs, and I am trying to do research. I can't find anything useful on
>  Google. I really do feel that even if I did seperate everything onto
>  seperate boxes, the matter still woudn't be resolved, as if one customer
>  "broke out" of their VM, they could steal other customer's data. Infact, I
>  would nearly say that would be worse than if my data was stolen, as if it
>  were my data that was stolen, I would only have myself to blame...
> 
> Even seperating storage woudn't really help in this matter, as storage
>  would still be shared among several VMs.
> 
> It gets to the stage where the only secure thing to do is to avoid Xen
>  altogether, and offer dedicated servers. Of course, this is not the thing
>  that I want to do.
> 
> There are many people on this list that offer VPS hosting services to
>  untrusted customers, and I'm trying to guage what measures they take (if
>  any) to prevent such exploits. From what I gather, no one does anything,
>  except keep their network secure. As someone mentioned, Amazon EC2 use
>  Xen, and if there was an exploit, we would have heard about it by now...
> 

I think the challenges are bigger than with separate physicals boxes. You have 
to approach from a theoretical point of view. It's not that because there are 
no breaches or exploits today, that there will never be. The theory is this: 
maximum seclusion is maximum security. Two separate boxes in two separate 
networks in let's say two separate buildings (physical security is also part 
of the game)  will be the most secure. Xen presents an exception to this: the 
seclusion is created by software. In theory it is the same thing as physical 
seclusion, until the software fails or is compromised. 
Another thing is human error: you WILL make mistakes. One of those mistakes 
may open open the wrong port, erase the wrong LUN, bridge the wrong NIC. I've 
done quite some security in my time and the biggest problem is always human 
error. We need to humbly acknowledge this. 
In short: it's certainly a bigger risk, but the consequences of compromising 
your server might lead you to accept this risk.



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>