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: John.McDermott@xxxxxxxxxxxx
Subject: Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
From: "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>
Date: Tue, 05 Sep 2006 15:00:39 -0400
Cc: Chris Wright <chrisw@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 05 Sep 2006 11:59:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44FDA506.1090803@xxxxxxxxxxxxxxxx>
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> <44FDA506.1090803@xxxxxxxxxxxxxxxx>
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2006-09-05 at 12:25 -0400, John McDermott (U.S. Navy Employee)

> 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.

I want to make a few points to clarify the value of XSM for Xen.  I
think the value goes well beyond prototyping and research.

1) XSM itself is small.  Do not confuse XSM with XSM and any particular
security module.  XSM has actually made Xen smaller by encapsulating
existing security code into a module that is not part of Xen.  XSM
without a module does not add security value to Xen.  XSM can only
provide security value in the presence of a security module.  In fact,
if you wish to have no security in Xen, XSM allows that too through the
selection of the dummy module.

2) Any arguments about Xen's size and assurance needs to include Xen
with a security module and what the security module is doing for Xen.
Discussion about particular security functionality can now be done in
the context of a particular module not Xen.  This adds value because we
can now reason about what a particular security module is doing for Xen.

3) Analysis of Xen as a security kernel is only appropriate in the
context of a particular security model.  Whether that model is
implemented in an XSM module or littered about Xen is immaterial.  
One might argue that XSM now creates a well defined internal security
interface for Xen and makes it easier to reason about Xen as a security

4) Security in user-space needs a secure foundation.  XSM allows that to
be created on Xen with an appropriate choice of module.  No one is
arguing that all security should be implemented as an XSM module.  XSM
modules should only incorporate security functionality appropriate for
the hypervisor; the remainder should be implemented in user-space.


> Sincerely,
> John

Xense-devel mailing list