From mboxrd@z Thu Jan 1 00:00:00 1970 From: "John McDermott (U.S. Navy Employee)" Subject: Re: [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM Date: Tue, 05 Sep 2006 12:25:42 -0400 Message-ID: <44FDA506.1090803@itd.nrl.navy.mil> References: Reply-To: John.McDermott@nrl.navy.mil Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Reiner Sailer Cc: Chris Wright , xen-devel@lists.xensource.com, xense-devel@lists.xensource.com, "George S. Coker, II" List-Id: xen-devel@lists.xenproject.org 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. Sincerely, John -- J.P. McDermott building 12 Code 5542 mcdermott@itd.nrl.navy.mil Naval Research Laboratory voice: +1 202.404.8301 Washington, DC 20375, USA fax: +1 202.404.7942