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-users] XenSE - any info available?

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] XenSE - any info available?
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Tue, 28 Jun 2005 16:10:36 +0100
Cc: Wesley Parish <wes.parish@xxxxxxxxxxxxxxx>
Delivery-date: Tue, 28 Jun 2005 15:09:32 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <200506290008.49464.wes.parish@xxxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <200506290008.49464.wes.parish@xxxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.7.1
> I came across this article and was wondering if anyone had any additonal
> information:
> Xen Developers Focus on Security
> Enhanced virtual desktop could protect remote consumer transactions.
> http://www.pcworld.com/news/article/0,aid,121624,00.asp

Lightning overview:
* The XenSE project is *not* there to patch security issues, etc.  It's aim is 
to add a Mandatory Access Control Framework to Xen itself.
* Security policies will be set by a user tool but then enforced by Xen.  
Because Xen has a very small codebase, it can be audited thoroughly to 
achieve high assurance that the policy is correctly enforced.  This is 
required for high level security accreditation (eg. EAL).
* will enable policies such as:
  - Chinese Wall : don't allow domains from two different groups to run on the 
same machine.  You might use this if you are renting domains to competing 
  - Type enforcement : only allow communication (eg. event channels, shared 
memory) between domains with the same "type".  Type could be "owner" or it 
could be "security level" (eg. "top secret" may only talk to "top secret" 
  - etc.
* As part of the system, we aim to break down "dom0" into multiple smaller 
functional units.  This allows us to reduce the Trusted Computing Base, again 
allowing easier audit.

The end result should be a virtual machine system that splits its functions up 
between multiple virtual machines with restricted privileges.  As a whole 
this should achieve an (even) higher assurance level than is possible for 
(eg) monolithic SELinux.  As a bonus, it should have higher resilience to 
driver failures, etc.

Initial code for MAC has been contributed by IBM and is in the unstable tree 
now.  The project will be ongoing for some time - more or less "full" XenSE 
support is planned for 4.0.

There's a XenSE mailing list, if you're interested.  Not much happening on it 
right now, though.


Xen-users mailing list

<Prev in Thread] Current Thread [Next in Thread>