Fwd: [User Question] Correct XSM/FLASK ruleset for oxenstored

Fwd: [User Question] Correct XSM/FLASK ruleset for oxenstored

[tech mailinglists]

[-- Attachment #1.1: Type: text/plain, Size: 2011 bytes --]

---------- Forwarded message ----------
From: tech mailinglists <mailinglists.tech@gmail.com>
Date: 2013/1/11
Subject: Fwd: [User Question] Correct XSM/FLASK ruleset for oxenstored
To: xen-users@lists.xen.org




---------- Forwarded message ----------
From: Dave Scott <Dave.Scott@eu.citrix.com>
Date: 2013/1/11
Subject: RE: [User Question] Correct XSM/FLASK ruleset for oxenstored
To: tech mailinglists <mailinglists.tech@gmail.com>, "
cl-mirage@lists.cam.ac.uk" <cl-mirage@lists.cam.ac.uk>


Hi,****

** **

Unfortunately I’ve not had a chance to play with XSM/FLASK just yet so I
don’t have an XSM configuration lying around.****

** **

I recommend asking over on xen-users@lists.xen.org ****

** **

Good luck!****

** **

Dave****

** **

*From:* cl-mirage-bounces@lists.cam.ac.uk [mailto:
cl-mirage-bounces@lists.cam.ac.uk] *On Behalf Of *tech mailinglists
*Sent:* 11 January 2013 9:28 AM
*To:* cl-mirage@lists.cam.ac.uk
*Subject:* [User Question] Correct XSM/FLASK ruleset for oxenstored****

** **

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

[-- Attachment #1.2: Type: text/html, Size: 5121 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Daniel De Graaf]

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

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

[tech mailinglists]

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

2013/1/14, Daniel De Graaf <dgdegra@tycho.nsa.gov>:
> 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
>

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

[Daniel De Graaf]

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@tycho.nsa.gov>:
>> 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

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

[tech mailinglists]

[-- Attachment #1.1: Type: text/plain, Size: 3556 bytes --]

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@tycho.nsa.gov>

> 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@tycho.nsa.gov>:
> >> 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
>

[-- Attachment #1.2: Type: text/html, Size: 4889 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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