Xen devel - Apr 2007 - [RFC] [PATCH] [XEN] [ACM] Enable updating policy on running system

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

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?

 -- Keir

On 20/4/07 16:58, "Stefan Berger" <stefanb@us.ibm.com> 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@us.ibm.com>
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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@us.ibm.com>





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <keir@xensource.com> 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@us.ibm.com>
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@us.ibm.com>
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 20/4/07 17:02, "Stefan Berger" <stefanb@us.ibm.com> wrote:
>> > 
>> > 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.
When a label is associated with a domain, doesn¹t that call into ACM code?
In which case you could define your own locking against that event.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <keir@xensource.com> wrote on 04/20/2007 12:46:40 PM:
> On 20/4/07 17:02, "Stefan Berger" <stefanb@us.ibm.com>
wrote:
> > 
> > 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. 
> 
> When a label is associated with a domain, doesn?t that call into ACM
> code? In which case you could define your own locking against that 
event.

Actually the easiest solution would be to grab the read-lock of the acm 
policy in do_domctl() before acm_pre_domctl() and release it after 
acm_post_domctl() or acm_fail_domctl(), which are both at the end of 
do_domctl(). All of these functions grab and release the read lock 
individually in some subfunction, but the lock is not being held 
permanently which is what bothers me for the update. 

   Stefan
> 
>  -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel