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:44:19 +0200
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 16 Jul 2010 03:45:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <46C13AA90DB8844DAB79680243857F0F0AFDBE@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> <201007161239.15313.bart.coninckx@xxxxxxxxxx> <46C13AA90DB8844DAB79680243857F0F0AFDBE@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:41:23 Jonathan Tripathy wrote:
> ________________________________
> 
> From: Bart Coninckx [mailto:bart.coninckx@xxxxxxxxxx]
> Sent: Fri 16/07/2010 11:39
> To: Jonathan Tripathy
> Cc: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-users] Xen Security
> 
> On Friday 16 July 2010 12:27:46 Jonathan Tripathy wrote:
> > 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.
> >
> > -------------------------------------------------------------------------
> >-- -----------------------------
> >
> > I 100% agree with you on this :) By splitting things up, you can limit
> > the "damage zone".  And I can see what you mean about the human area -
> > you really need your head screwed on when working with all this stuff!
> >
> > Do people on this list generally trust Xen with their private data, mixed
> >  with public VMs? The folks over at Slicehost, Amazon etc.. seem to...
> 
> I would be surprised if Amazon does this. Only their management stuff will
>  be connected to the pulbic infrastructure.
> 
> 
> ---------------------------------------------------------------------------
> --------------------------------------------------
> 
> Ah, sorry I wasn't suggesting that Amazon's web shop runs on their EC2
>  cloud. I was just simply stating that Amazon seem to trust Xen with a
>  mixture of customer VMs, that's all
> 

Well, I suppose it's somewhere in their general conditions that their 
liability will be limited. 

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

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