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

[Reiner Sailer <sailer@xxxxxxxxxx>]

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