[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel][Xense-devel][PATCH][1/4] Xen Security Modules: XSM
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 Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |