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][PATCH][1/4] Xen Security Modules: XSM

To: Derek Murray <Derek.Murray@xxxxxxxxxxxx>, "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel][Xense-devel][PATCH][1/4] Xen Security Modules: XSM
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Wed, 09 May 2007 15:23:16 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 09 May 2007 07:21:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <37BDD058-CD33-46BC-8CC6-B0214A45925C@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceSRZVi07MHbP44EduwogAX8io7RQ==
Thread-topic: [Xen-devel][Xense-devel][PATCH][1/4] Xen Security Modules: XSM
User-agent: Microsoft-Entourage/
On 9/5/07 15:04, "Derek Murray" <Derek.Murray@xxxxxxxxxxxx> wrote:

> For disaggregation of the domain builder, we would like to be able to
> delegate this privilege to a small, trusted domain (domB): it seems
> to me that XSM would be the cleanest way to do this. Would it
> therefore be possible to add a hook in set_foreigndom() on the !
> IS_PRIV(d) branch, or is there some security consequence that I am
> overlooking?

Better to get rid of the IS_PRIV() altogether? If we're adding these hooks
all over the place we may as well get some benefit from them, even if it
means adding extra ones. Only question then is whether conflating security
constraints required for correct operation of the Xen platform (i.e.,
capabilities of the disaggregated dom0 domains) with the constraints
required for domU's, and trying to express these in the same security policy
module actually makes sense. It might make sense to 'shim in' a static
built-in policy at those hook points as a pre-filter on the
dynamically-loaded policy for ordinary domUs.

 -- Keir

Xen-devel mailing list

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