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

[Xen-users] Re: Live Migration Config

To: <xen-users@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-users] Re: Live Migration Config
From: "Alan Greenspan" <alan@xxxxxxxxxxx>
Date: Sun, 30 Oct 2005 08:31:22 -0500
Delivery-date: Sun, 30 Oct 2005 13:28:37 +0000
Envelope-to: www-data@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/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <E1EWBr4-0000Al-Sy@host-192-168-0-1-bcn-london>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Network security is usually policy driven by the IT department. I don't think Xen can mandate a network security model - VPNs, VLANs, etc.. Some organizations don't need strict network security, but still need to protect against bugs or control certain types of access within an unprotected network segment. It's unreasonable to require firewalling or VPNs as a prerequisite to installing Xen.

My subnet is generally open. However, that doesn't mean I configure my machine to allow my neighbors to rsync or NFS mount my disks. I'm more worried about mistakes rather than security. I certainly don't want the guy next door to type "xm migrate ...", finger fumble an IP address and shoot my machine with a domU that inadvertently scribbles on my disks.

Most, if not all inet services provide some level of access control within their own config files and/or via host_access(5). You'd hard pressed to find a service that didn't do this, but punted to the IT department for protection instead.

The following configurable controls should be implemented for Xen migration.

1. The migration port.
2. The network interface(s) that the migration service listens on.
3. The maximum # of allowed concurrent incoming migrations from a foreign host. 4. Observance of the /etc/hosts.allow and /etc/hosts.deny access controls (or the same within a Xen config file).
5.  Some simple way to turn off incoming migration completely.

Alan

Message: 2
Date: Sat, 29 Oct 2005 22:00:00 -0500
From: Charles Duffy <cduffy@xxxxxxxxxxx>
Subject: [Xen-users] Re: Live Migration Config
To: xen-users@xxxxxxxxxxxxxxxxxxx
Message-ID: <43643730.50407@xxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed

Mark Williamson wrote:
Xend trusts anything the incoming config tells it...  Could get nasty
very
quickly from both security and DoS perspectives.

I haven't heard objections raised to my suggestion of running a VPN over
your regular network for the purpose. This allows encryption, validation
and access control; the thing it lacks is *fine-grained* control -- a
Dom0 is either part of the VPN or it isn't -- but this shouldn't be a
concern if your Dom0s are adequately secured. Ideally, they should be
accessible *only* via VPN connections or via direct console
communication. If you need remote administration, do that -- but guard
the key zealously.

Since your Dom0s are accessible *only* via console or VPN access from
another system, and the other VPNned systems are likewise only
accessible via console or VPN (except for your administrative system),
there's not much by way of risk that one of your Dom0s *can* be
penetrated, so long as your console access is physically secure.


So -- so long as your Dom0s are secured via a VPN with a firewall
preventing all non-VPN access, I really don't see the concern being as
substantial as you make it to be.




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