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
 
   
 

xense-devel

Re: [Xense-devel] What's the status for this project?

To: "Li, Yin" <yin.li.th@xxxxxxxxx>
Subject: Re: [Xense-devel] What's the status for this project?
From: Reiner Sailer <sailer@xxxxxxxxxx>
Date: Mon, 17 Apr 2006 10:52:34 -0400
Cc: Xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 17 Apr 2006 07:52:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <214321a60604162328i33eec1eak2390d3ec8ab1fa9e@xxxxxxxxxxxxxx>
List-help: <mailto:xense-devel-request@lists.xensource.com?subject=help>
List-id: "A discussion list for those developing security enhancements for Xen." <xense-devel.lists.xensource.com>
List-post: <mailto:xense-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx

xense-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 04/17/2006 02:28:15 AM:

> Hi guys,

>  
> I am a new comer to Xen and very interested in how to enhance the
> security of Xen platform. Could anybody here tell me where we are
> now? I am really confused by the inactive of this maillist.


Hi Yin,

I will give here a short status quo for the sHype access control framework in Xen (http://www.research.ibm.com/ssd_shype). There are many other security mechanisms in Xen. Others might reply to your request regarding those projects.  

Access Control in Xen consists of two components: (i) The Access Control Policy (ACP) defines security labels and access rules based on these labels. (ii) The Access Control Module (ACM) makes access control decisions by interpreting the policy when domains require to communicate or to access resources. The Xen access control has sufficient mechanisms in place to enforce the access decisions even against maliciously acting user domains (mandatory access control).

Access rights for domains in Xen are determined by the domain security label only and not based on the domain Name or ID. The ACP specifies security labels that can then be assigned to domains and resources. Every domain must be assigned exactly one security label, otherwise access control decisions could become indeterministic. ACPs are distinguished by their name, which is a parameter to most of the subcommands described below.

Currently, the ACP specifies two ways to interpret labels

(1) Simple Type Enforcement: Labels are interpreted to decide access of domains to communication means and virtual or physical resources. Communication between domains as well as access to resources are forbidden by default and can only take place if they are explicitly allowed by the security policy. The proper assignment of labels to domains controls the sharing of information (directly through communication or indirectly through shared resources) between domains. This interpretation allows to control the overt (intended) communication channels in Xen.

(2) Chinese Wall: Labels are interpreted to decide which domains can co-exist (be run simultaneously) on the same system. This interpretation allows to prevent direct covert (unintended) channels and mitigates risks caused by imperfect core domain isolation (trade-off between security and other system requirements). For a short introduction to covert channels, please refer to http://www.multicians.org/timing-chn.html.

--> more info in the source documentation (tools/security/*.txt) or http://www.acsa-admin.org/2005/papers/171.pdf

Very recently submitted patches to this framework (not yet active in the devel tree) will add
(3) xm command and man page extensions for labeling domains, making and loading policies, and other security management tasks
(4) security label support (and checks) for resume and migration of labeled domains
(5) simplified policy specification

Ongoing work focusses on controlling shared resources (network, disks), through which domains can share information indirectly:
(6) extending Xen access control into the networking in Dom0 to control indirect network traffic between domains according to the hypervisor (only local traffic)
(7) extending Xen access control into the hosting domain for disks and label virtual disks as well as enforce the access control at the binding time of disks to domains
(8) enabling secure (labeled, protected) tunnels between labeled domains on different platforms over insecure networks
   --> http://domino.research.ibm.com/library/cyberdig.nsf/papers?SearchView&Query=RC23865&SearchMax=10

We will have enforcement coverage in Xen for shared disks and local network traffic by the end of the year or earlier. We also aim at a preliminary solution to secure labeled tunnels over insecure networks to enable protected sharing between labeled domains on different hardware platforms.

> Thanks and regards,
> Yin

Thanks for your interest
Reiner
>  _______________________________________________
> Xense-devel mailing list
> Xense-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xense-devel
_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel