Re: [Xen-devel] [PATCH 03/15] flask/policy: move user definitions and constraints into modules

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 06/17/2016 11:28 AM, Konrad Rzeszutek Wilk wrote:
> > diff --git a/tools/flask/policy/modules/modules.conf 
> > b/tools/flask/policy/modules/modules.conf
> > index d875dbf..9aac6a0 100644
> > --- a/tools/flask/policy/modules/modules.conf
> > +++ b/tools/flask/policy/modules/modules.conf
> > @@ -34,6 +34,13 @@ nomigrate = on
> >  nic_dev = on
> >
> >  # This allows any domain type to be created using the system_r role.  When it 
> > is
> > -# disabled, domains not using the default types (dom0_t and domU_t) must use
> > -# another role (such as vm_r) from the vm_role module.
> > +# disabled, domains not using the default types (dom0_t, domU_t, dm_dom_t) must
> > +# use another role (such as vm_r from the vm_role module below).
> >  all_system_role = on
> > +
> > +# Example users, roles, and constraints for user-based separation.
> > +#
> > +# The three users defined here can set up grant/event channel communication
> > +# (vchan, device frontend/backend) between their own VMs, but cannot set up a
> > +# channel to a VM under a different user.
> > +vm_role = on
> So should this be off? As by default we would want all_system_role ?
>
> Ah wait, it can be loaded - even if not used.
Yes, enabling both of these modules gives you flexibility to use either or
both types for domains.  Enabling only one would be useful to enforce its
use, and disabling both doesn't make much sense unless you were adding
another module.

--
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel