Re: [Xen-devel] [User Question] Correct XSM/FLASK ruleset for oxenstored

[tech mailinglists <mailinglists.tech@xxxxxxxxx>]

Hey,

okey so I will see that I can modify it that it would work with 4.2.1. I have two questions about that:

What is currently not supported by 4.2.1 and is there a way I can validate that the compiled files are compatible with the installed Xen version?

Best Regards

2013/1/15 Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>

On 01/15/2013 09:16 AM, tech mailinglists wrote:
> Hello Daniel,
>
> thanks for your reply to my question.
>
> Do you think this also would work with Xen 4.2.1 and Linux 3.7.1? And
> in which file it must be placed xen.if or xen.te and does I need both
> files or only one?
>
> Best Regards

Not as-is, but it should give you an idea for how to write it for that
version. This goes in the .te file. You need to compile the policy to
load in the hypervisor, and both files are used in the compilation.

> 2013/1/14, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>:
>> On 01/13/2013 01:17 AM, tech mailinglists wrote:
>> [...]
>>>
>>> Hello all,
>>>
>>> I am actually working on Dom0 disaggregation and wan't to use an
>>> oxenstored
>>> stubdomain. But I have a problem to write the needed XSM/FLASK
>>> rule/rules.
>>> So I understood that this rules are written like SELinux rules so a
>>> defined
>>> application has a defined right. And for oxenstored the domctl
>>> getdomaininfo right must be given. So I have builded the oxenstored
>>> stubdom
>>> already like explained here:
>>> http://www.openmirage.org/blog/xenstore-stub-domain and I am also running
>>> on Linux 3.7.1 with pv_ops enabled. So I just need help to get good
>>> XSM/FLASK files. Would be great to see an example for such a rule or
>>> something like that.
>>>
>>> Best Regards****
>>>
>>> Hello,
>>>
>>> its a Question about XSM/FLASK and oxenstored, details in the messages
>>> above. I also have forwarded this to the xen-users mailinglist but got no
>>> reply and the documentation of XSM/FLASK in the wiki is very short so I
>>> am
>>> realy unsure how to do it right.
>>>
>>> Best Regards
>>>
>>>
>>
>> This is the xenstore domain policy that I have been using to test. It is
>> based on the patches currently in xen 4.3-unstable-staging and has only
>> been tested with the C xenstore stubdom, although I expect it to work with
>> the mirage oxenstored stubdom.
>>
>> ################################################################################
>> #
>> # 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 };
>>
>>
>> --
>> Daniel De Graaf
>> National Security Agency
>>


--
Daniel De Graaf
National Security Agency

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