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

[Reiner Sailer <sailer@xxxxxxxxxx>]

Hi Yin,

"Li, Yin" <yin.li.th@xxxxxxxxx> wrote
on 04/18/2006 09:48:12 AM:

> 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. 

This is the "separation/isolation hypervisor"
interpretation: completely isolate virtual machines from each other.

> 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? 

Yes, to make best use of resources, a "sharing
hypervisor" approach is a good solution in distributed services commercial
environments. This is what we are aiming for.

The point is to "control this sharing among domains"
(in Xen -- direct communication: event channels, shared memory; cooperation:
virtual network, virtual block devices, etc.) according to a formal security
policy and to yield useful guarantees (e.g., viruses cannot spread from
this domain/workload to that domain/workload).

I would like to emphasize that the hypervisor is just
one layer of access control, on top of which other layers (e.g., operating
systems) can enforce finer grained security policies. The hypervisor, however,
is the first (lowest) layer that can enforce access control based on virtualized
resources (independent of platform specifics) and is consequently in a
unique position to offer a scalable, distributed, and unified security
base for upper layers relying on a minimal trusted computing base.

Regards
Reiner

> 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