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

["Li, Yin" <yin.li.th@xxxxxxxxx>]

Hi Reiner,

 

Great thanks for your information!

 

I have looked into the brief introduction to secure hypervisors project you are (maybe) working on, which is a very interesting and amazing job ;-) I need more time to go through the related materials and before that let me ask a fast question: From the definition of virtualization, the guest OSes should be absolutely isolated, where the communication among guest OSes through shared resources (memory, network, etc.) are prohibited, to guarentee the security and portability. While for consideration of performance and maybe other requirements, we need to implement the mechanisms to support inter-domain communication directly or indirectly through the shared system resources. And therefore we need to enforce the security, in another word, access control for the communications, and that is the main purpose of the secure enhancement for hypervisors (Xen, etc.). Is it right?

 

Thanks and regards,

Yin

 

On 4/17/06, Reiner Sailer <sailer@xxxxxxxxxx> wrote:

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