[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] sHype Hypervisor Security Architecture for Xen



There is some work going on in this area in Intel Research, although so far we 
mostly identified problems rather then came up with a solution. In any case 
cooperation in enhancing the security of Xen would certainly be better then 
separate efforts.
I will be most interested to learn the details of sHype and then trying to 
find the way to port it to Xen.
I can be contacted directly on gm281@xxxxxxxxxx

Cheers
Gregor

> I am a member of the Secure Systems Department at IBM's TJ Watson Research
> Center (http://www.research.ibm.com/secure_systems_department/).
>
> Our group has designed and developed a security architecture for
> hypervisors (called sHype). We have implemented it on an x86-based IBM
> research hypervisor.  We now plan to contribute this to Xen by integrating
> our security architecture into it.
>
> sHype is based on mandatory access controls (MAC). This allows Xen to use
> access rules (formal policy) to control both the sharing of virtual
> resources as well as the information flow between domains. The Xen port of
> sHype will leverage the existing Xen interdomain communication mechanism
> and we expect near-zero performance overhead on the performance-critical
> paths (e.g., sending or receiving packets on a virtual network, or writing
> or reading shared memory).  The sHype access control architecture
> separates policy decisions from policy enforcement. It is modeled after
> the Flask security architecture as implemented in SELinux (
> http://www.cs.utah.edu/flux/fluke/html/flask.html).  Our design is
> targeted at a flexible medium-assurance architecture that can support
> anything from simple security domains to multilevel security (MLS) and
> Chinese Wall policies.
>
> Merging the sHype access control architecture with Xen is the first step
> toward our goal of hardening Xen to support enterprise-class applications
> and security requirements. We are working on the following items to
> achieve this goal (which we intend to contribute spread out over this
> year):
>
> * Port sHype to Xen
>
> * Add stronger security/isolation guarantees (confinement) to what is
> currently available through Xen's (and other hypervisors') address space
> separation mechanisms, e.g., to enable information flow control in Xen
>
> *  Enhance Xen to support trusted computing under Linux using
> TCG/TPM-based attestation mechanisms
>
> *  Enhance Xen to support secure resource metering, verification, and
> control.
>
> * Apply our experience in automated security analysis to Xen to make it
> more robust
>
> * Make Xen suitable for Common Criteria evaluation
>
> We are confident that our work will significantly contribute to Xen in the
> security space and that it is a good fit with the Xen roadmap. We look
> forward to interacting with the Xen community on the design and
> implementation of our architecture.
>
> Reiner
> __________________________________________________________
> Reiner Sailer, Research Staff Member, Secure Systems Department
> IBM T J Watson Research Ctr, 19 Skyline Drive, Hawthorne NY 10532
> Phone: 914 784 6280  (t/l 863)  Fax: 914 784 6205, sailer@xxxxxxxxxx
> http://www.research.ibm.com/people/s/sailer/

-- 
Quidquid latine dictum sit, altum viditur --- Anon


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.