|
|
|
|
|
|
|
|
|
|
xen-devel
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
|
|
|
|
|