| Message ID | 1464015933-26891-5-git-send-email-dgdegra@tycho.nsa.gov (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, May 23, 2016 at 11:05:32AM -0400, Daniel De Graaf wrote: > This adds the xenstore_t type to the example policy for use by a > xenstore stub domain. Is there a link somewhere or docs that oultines how to how create/build such stub domain? The docs/misc/stubdom.txt sadly does not have any data? > > Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> > --- > tools/flask/policy/modules/modules.conf | 3 +++ > tools/flask/policy/modules/xenstore.te | 21 +++++++++++++++++++++ > 2 files changed, 24 insertions(+) > create mode 100644 tools/flask/policy/modules/xenstore.te > > diff --git a/tools/flask/policy/modules/modules.conf b/tools/flask/policy/modules/modules.conf > index 2dfc011..8ffd00e 100644 > --- a/tools/flask/policy/modules/modules.conf > +++ b/tools/flask/policy/modules/modules.conf > @@ -33,6 +33,9 @@ nomigrate = on > # Example device policy. Also see policy/device_contexts. > nic_dev = on > > +# Xenstore stub domain. > +xenstore = on > + > # Allow all domains to use system_u:system_r: instead of requiring explicit > # roles. This is not required for dom0_t, domU_t, and dm_dom_t. > default_role = on > diff --git a/tools/flask/policy/modules/xenstore.te b/tools/flask/policy/modules/xenstore.te > new file mode 100644 > index 0000000..2ae7a1d > --- /dev/null > +++ b/tools/flask/policy/modules/xenstore.te > @@ -0,0 +1,21 @@ > +################################################################################ > +# > +# Xenstore stubdomain > +# > +################################################################################ > +declare_singleton_domain(xenstore_t) > +create_domain(dom0_t, xenstore_t) > +manage_domain(dom0_t, xenstore_t) > + > +# Xenstore requires the global VIRQ for domain destroy operations > +allow dom0_t xenstore_t:domain set_virq_handler; > +# Current xenstore stubdom uses the hypervisor console, not "xl console" > +allow xenstore_t xen_t:xen writeconsole; > +# Xenstore queries domaininfo on all domains > +allow xenstore_t domain_type:domain getdomaininfo; > + > +# As a shortcut, the following 3 rules are used instead of adding a domain_comms > +# rule between xenstore_t and every domain type that talks to xenstore > +create_channel(xenstore_t, domain_type, xenstore_t_channel) > +allow event_type xenstore_t: event bind; > +allow xenstore_t domain_type:grant { map_read map_write unmap }; > -- > 2.5.5 >
On 06/07/2016 03:44 PM, Konrad Rzeszutek Wilk wrote: > On Mon, May 23, 2016 at 11:05:32AM -0400, Daniel De Graaf wrote: >> This adds the xenstore_t type to the example policy for use by a >> xenstore stub domain. > > Is there a link somewhere or docs that oultines how to how > create/build such stub domain? The docs/misc/stubdom.txt sadly does not > have any data? I believe it is built by "make stubdom" unless you passed the --disable-xenstore-stubdom to configure. Starting the stubdom has to be done using init-xenstore-domain from tools/helpers.
On Tue, Jun 07, 2016 at 03:48:02PM -0400, Daniel De Graaf wrote: > On 06/07/2016 03:44 PM, Konrad Rzeszutek Wilk wrote: > >On Mon, May 23, 2016 at 11:05:32AM -0400, Daniel De Graaf wrote: > >>This adds the xenstore_t type to the example policy for use by a > >>xenstore stub domain. > > > >Is there a link somewhere or docs that oultines how to how > >create/build such stub domain? The docs/misc/stubdom.txt sadly does not > >have any data? > > I believe it is built by "make stubdom" unless you passed the > --disable-xenstore-stubdom to configure. Starting the stubdom > has to be done using init-xenstore-domain from tools/helpers. Thanks! Let me try that out!
Hi, Default XSM policy doesn't allow the use of unlabeled PCI resources that have been passed through to target domain. xen.te # Resources must be declared using . resource_type neverallow * ~resource_type:resource use; It allows the resource to be added and removed by the source domain to target domain, but its use by target domain is blocked. The resource can be used only if it has been labeled using flask-label-pci command which needs to be rerun after every boot and after every policy reload. The above approach reduces the flexibility and necessitates admin intervention to give passthrough rights after host has booted. Also, in general if I want to allow all domUs to have PCI passthough access to all PCI device, I have no other way apart from disabling the "neverallow" rule. Given that what we ship is just a sample default policy for reference which is expected to be permissive in most of the scenarios so that it doesn't affect the basic functionalities, is this "neverallow" rule needed ? Thanks Anshul Makkar
On 07/06/2016 11:34 AM, anshul makkar wrote: > Hi, > > Default XSM policy doesn't allow the use of unlabeled PCI resources that have been passed through to target domain. > > xen.te > # Resources must be declared using . resource_type > neverallow * ~resource_type:resource use; > > It allows the resource to be added and removed by the source domain to target domain, but its use by target domain is blocked. This rule only mandates the use of resource_type for resource types. If you are creating a new resource type, follow the example in nic_dev.te. > The resource can be used only if it has been labeled using flask-label-pci command which needs to be rerun after every boot and after every policy reload. Yes; this gives the most control over what resources can be delegated. Policy reloads are supposed to be rare (on a production system) and you already need special boot scripts (or parameters) to set up the device for passthrough, so this can be added there. However, I agree this can be more work than a "default" FLASK policy should require. > The above approach reduces the flexibility and necessitates admin intervention to give passthrough rights after host has booted. Also, in general if I want to allow all domUs to have PCI passthough access to all PCI device, I have no other way apart from disabling the "neverallow" rule. Try adding a module with the following rules, which should allow domU to use unlabeled devices: use_device(domU_t, irq_t) use_device(domU_t, ioport_t) use_device(domU_t, iomem_t) use_device(domU_t, device_t) If this works, that module could be added to the default policy. > Given that what we ship is just a sample default policy for reference which is expected to be permissive in most of the scenarios so that it doesn't affect the basic functionalities, is this "neverallow" rule needed ? > > Thanks > Anshul Makkar The neverallow rules are just there to ensure that the attributes are being used correctly.
On 06/07/16 16:59, Daniel De Graaf wrote: > On 07/06/2016 11:34 AM, anshul makkar wrote: >> Hi, >> >> >> It allows the resource to be added and removed by the source domain to >> target domain, but its use by target domain is blocked. > > This rule only mandates the use of resource_type for resource types. If > you are creating a new resource type, follow the example in nic_dev.te. Agreed, but inherently it means that "use" of any unlabeled resource be it irq, ioport or iomem or nic_dev is restricted. > >> The resource can be used only if it has been labeled using >> flask-label-pci command which needs to be rerun after every boot and >> after every policy reload. > > Yes; this gives the most control over what resources can be delegated. > Policy reloads are supposed to be rare (on a production system) and you > already need special boot scripts (or parameters) to set up the device > for passthrough, so this can be added there. However, I agree this can > be more work than a "default" FLASK policy should require. > > Try adding a module with the following rules, which should allow domU to > use unlabeled devices: > > use_device(domU_t, irq_t) > use_device(domU_t, ioport_t) > use_device(domU_t, iomem_t) > use_device(domU_t, device_t) Yes, it does work , but I have added these in delegate_device to make it restrict to the case where there is delegation. > > If this works, that module could be added to the default policy. > >> Given that what we ship is just a sample default policy for reference >> which is expected to be permissive in most of the scenarios so that it >> doesn't affect the basic functionalities, is this "neverallow" rule >> needed ? >> >> Thanks >> Anshul Makkar > > The neverallow rules are just there to ensure that the attributes are > being used correctly. > Anshul
On 07/06/2016 12:19 PM, anshul makkar wrote: > On 06/07/16 16:59, Daniel De Graaf wrote: >> On 07/06/2016 11:34 AM, anshul makkar wrote: >>> Hi, >>> >>> >>> It allows the resource to be added and removed by the source domain to >>> target domain, but its use by target domain is blocked. >> >> This rule only mandates the use of resource_type for resource types. If >> you are creating a new resource type, follow the example in nic_dev.te. > Agreed, but inherently it means that "use" of any unlabeled resource be it irq, ioport or iomem or nic_dev is restricted. Restricted how? The fallback types have the resource_type attribute. Neverallow rules are actually not present in the binary policy; they act as compile-time assertions in the policy build. >> >>> The resource can be used only if it has been labeled using >>> flask-label-pci command which needs to be rerun after every boot and >>> after every policy reload. >> >> Yes; this gives the most control over what resources can be delegated. >> Policy reloads are supposed to be rare (on a production system) and you >> already need special boot scripts (or parameters) to set up the device >> for passthrough, so this can be added there. However, I agree this can >> be more work than a "default" FLASK policy should require. >> >> Try adding a module with the following rules, which should allow domU to >> use unlabeled devices: >> >> use_device(domU_t, irq_t) >> use_device(domU_t, ioport_t) >> use_device(domU_t, iomem_t) >> use_device(domU_t, device_t) > Yes, it does work , but I have added these in delegate_device to make it restrict to the case where there is delegation. This prevents using delegate_devices without allowing access to unlabeled devices. If you think this should be a macro, I would suggest making a new one named something like "delegate_unlabeled_devices".
On 07/07/16 16:36, Daniel De Graaf wrote: > On 07/06/2016 12:19 PM, anshul makkar wrote: >> On 06/07/16 16:59, Daniel De Graaf wrote: >>> On 07/06/2016 11:34 AM, anshul makkar wrote: >>>> Hi, >>>> >>>> >>>> It allows the resource to be added and removed by the source domain to >>>> target domain, but its use by target domain is blocked. >>> >>> This rule only mandates the use of resource_type for resource types. If >>> you are creating a new resource type, follow the example in nic_dev.te. >> Agreed, but inherently it means that "use" of any unlabeled resource >> be it irq, ioport or iomem or nic_dev is restricted. > > Restricted how? The fallback types have the resource_type attribute. Restricted if they are unlabeled. > > Neverallow rules are actually not present in the binary policy; they act as > compile-time assertions in the policy build. > Fine. >>> >>>> The resource can be used only if it has been labeled using >>>> flask-label-pci command which needs to be rerun after every boot and >>>> after every policy reload. >>> >>> >>> Try adding a module with the following rules, which should allow domU to >>> use unlabeled devices: >>> >>> use_device(domU_t, irq_t) >>> use_device(domU_t, ioport_t) >>> use_device(domU_t, iomem_t) >>> use_device(domU_t, device_t) >> Yes, it does work , but I have added these in delegate_device to make >> it restrict to the case where there is delegation. > > This prevents using delegate_devices without allowing access to unlabeled > devices. If you think this should be a macro, I would suggest making a new > one named something like "delegate_unlabeled_devices". > Agreed. That's a better approach. I believe this macro can make the default policy more flexible and useful for more general audience, so it should be there in the policy. I can submit patch for the same. Your thoughts ?
diff --git a/tools/flask/policy/modules/modules.conf b/tools/flask/policy/modules/modules.conf index 2dfc011..8ffd00e 100644 --- a/tools/flask/policy/modules/modules.conf +++ b/tools/flask/policy/modules/modules.conf @@ -33,6 +33,9 @@ nomigrate = on # Example device policy. Also see policy/device_contexts. nic_dev = on +# Xenstore stub domain. +xenstore = on + # Allow all domains to use system_u:system_r: instead of requiring explicit # roles. This is not required for dom0_t, domU_t, and dm_dom_t. default_role = on diff --git a/tools/flask/policy/modules/xenstore.te b/tools/flask/policy/modules/xenstore.te new file mode 100644 index 0000000..2ae7a1d --- /dev/null +++ b/tools/flask/policy/modules/xenstore.te @@ -0,0 +1,21 @@ +################################################################################ +# +# Xenstore stubdomain +# +################################################################################ +declare_singleton_domain(xenstore_t) +create_domain(dom0_t, xenstore_t) +manage_domain(dom0_t, xenstore_t) + +# Xenstore requires the global VIRQ for domain destroy operations +allow dom0_t xenstore_t:domain set_virq_handler; +# Current xenstore stubdom uses the hypervisor console, not "xl console" +allow xenstore_t xen_t:xen writeconsole; +# Xenstore queries domaininfo on all domains +allow xenstore_t domain_type:domain getdomaininfo; + +# As a shortcut, the following 3 rules are used instead of adding a domain_comms +# rule between xenstore_t and every domain type that talks to xenstore +create_channel(xenstore_t, domain_type, xenstore_t_channel) +allow event_type xenstore_t: event bind; +allow xenstore_t domain_type:grant { map_read map_write unmap };
This adds the xenstore_t type to the example policy for use by a xenstore stub domain. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> --- tools/flask/policy/modules/modules.conf | 3 +++ tools/flask/policy/modules/xenstore.te | 21 +++++++++++++++++++++ 2 files changed, 24 insertions(+) create mode 100644 tools/flask/policy/modules/xenstore.te