This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM

To: Reiner Sailer <sailer@xxxxxxxxxx>
Subject: Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
From: "John McDermott (U.S. Navy Employee)" <mcdermott@xxxxxxxxxxxxxxxx>
Date: Tue, 05 Sep 2006 12:25:42 -0400
Cc: Chris Wright <chrisw@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 05 Sep 2006 09:27:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <OFB0C8B799.998B0D14-ON852571DD.000F8315-852571DD.001474E6@xxxxxxxxxx>
List-help: <mailto:xense-devel-request@lists.xensource.com?subject=help>
List-id: "A discussion list for those developing security enhancements for Xen." <xense-devel.lists.xensource.com>
List-post: <mailto:xense-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=unsubscribe>
References: <OFB0C8B799.998B0D14-ON852571DD.000F8315-852571DD.001474E6@xxxxxxxxxx>
Reply-to: John.McDermott@xxxxxxxxxxxx
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923)
Reiner Sailer wrote:

XSM would effectively replace the small set of hooks that the sHype/ACM module introduced with a more generic mediation framework. sHype would use the XSM hook framework to control the same operations that it controls now. The way users interact with sHype(XSM) (tools, policies, labeling, ...) would not be affected by XSM. Instead of being both hooks and security module, sHype(XSM) would be a security module and XSM would offer the hooks.

Ideally, XSM would be a standardized and generic Xen interface that offers the possibility for researchers to easily experiment with proprietary security modules. At the same time, it must have very low performance overhead and be effective to support enterprise security on highly utilized platforms.

It is very good for starting the discussions that George and team succeeded to submit their code before the Xen Summit. Thank you!

The XSM concept looks good for prototyping and research but any security-related additions to Xen should be done in a way that does not increase the _minimum_ size of the code base. A small code base is essential for high assurance; having the flexibility of XSM is good but it should be possible to build a Xen with something smaller than XSM. If XSM or other security enhancements become too deeply associated with the core of Xen then we loose the chance to build high-assurance Xen-based products.

This is really an issue about what kind of security the hypervisor should enforce and what should be enforced by trusted or untrusted (wrt the hypervisor) mechanisms outside the hypervisor.



J.P. McDermott                  building 12
Code 5542                       mcdermott@xxxxxxxxxxxxxxxx
Naval Research Laboratory       voice: +1 202.404.8301
Washington, DC 20375, USA       fax:   +1 202.404.7942

Xense-devel mailing list