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

[Ronald Perez <ronpz@xxxxxxxxxx>]

Lin,

I think your summary/question is fairly
accurate (instead of "prohibited", perhaps "controlled"
is a better term), although access control is just one aspect of "security"
in regards to hypervisors. Integrity, authentication and attestation, reliably
controlling the consumption of local resources (e.g., preventing certain
denial-of-service attacks), and minimizing the trusted computing base (or
at least making it more modular), are some other areas we and others in
the community are working on. But there's no lack of opportunity in Xen
for others to get involved :-)

-Ron

"Li, Yin" <yin.li.th@xxxxxxxxx>
Sent by: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx

04/18/2006 09:48 AM

To	Reiner Sailer/Watson/IBM@IBMUS
cc	Xense-devel@xxxxxxxxxxxxxxxxxxx
Subject	Re: [Xense-devel] What's the status for this project?

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

_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel