Re: [Xen-devel] [RFC] [PATCH] [XEN] [ACM] Enable updating policy on running system

[Stefan Berger <stefanb@xxxxxxxxxx>]

Keir Fraser <keir@xxxxxxxxxxxxx> wrote on 04/20/2007
11:28:26 AM:

> Is there now some consensus on how to add security features to XenAPI
that
> does not cause conflict between XSM and ACM?

We are only supporting a single policy on the system
and that may either be an ACM or a Flask policy. When someone sets the
policy, he has to choose between either one of them and the API supports
setting this policy and making modifications to it later on, at least for
the ACM implementation the code behind the API does that.

> 
> Anyway, in response to your main question, I wonder what you actually
need
> to serialise against? Is it sufficient to just sync against domain
creation
> -- what if event channels or grant mappings are also occurring during
the
> policy change? Is there some specific part of domain creation you
need to
> serialise against?

While the policy update is happening, a domain could
be created with a label that is about to be modified or even deleted as
part of the policy update.

For serializing against event channel and grant mappings
I hold the write-lock to the current policy. The functions that evaluate
whether two domains may establish an event channel or grant mappings run
into acm/acm_simple_type_enforcement_hooks:share_common_type() function
where they try to grab the read-lock to the current policy. So this is
going to block them until it's clear what policy will be on the system.
I'd say an update of a policy does not happen all that frequently, so this
blocking won't happen very often.

   Stefan

> 
>  -- Keir
> 
> On 20/4/07 16:58, "Stefan Berger" <stefanb@xxxxxxxxxx>
wrote:
> 
> > Keir,
> > 
> >   as part of the effort to make ACM functionality available
via the
> > Xen-API, we are adding further functionality to the ACM module
in the
> > hypervisor. One of these functions is to be able to update a
running
> > system with a modified policy. The update is happening in several
steps:
> > relabeling of the domains, testing against the current state
of the
> > system, committing the changes. During that time it is necessary
that no
> > other domain be created. I am currently using the domlist_update_lock
> > (see DOM_CREATE_LOCK define in the patch) to prevent other domains
from
> > being added to the system while the update is happening. This
is not the
> > correct lock to use, though, and I'd rather like to use domctl_lock
in
> > do_domctl, because that will prevent a domain from being 'created'
and
> > not just 'added to the list'. So would it be possible to make
this lock
> > globally available since it is currently a local lock only accessible
> > from within do_domctl or are there other ways to achieve this?
> > 
> >  Thanks.
> >     Stefan
> > 
> > Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxx>
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel