[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |