XSM/FLASK questions

XSM/FLASK questions

[baozeng]

Hello all,
    I played with Xen 4.1.0, XSM/FLASK module to see whether it works well or not. I
changed the policy file to make dom0 cannot create a domU labeled with domHU_t
type.  The policy.conf generated using "make policy" command is as the
following:
    type domHU_t, domain_type;
    allow dom0_t domHU_t:domain {max_vcpus setdomainmaxmem

                                setaddrsize getdomaininfo hypercall

                                setvcpucontext scheduler unpause

                                getvcpuinfo getaddrsize getvcpuaffinity}; //I
removed "create"

   Then I added the label domHU_t for a domU in its configure file as the following:

   access_control = ['policy=,label=system_u:system_r:domHU_t']

After that I made install the FLASK policy using "make install" and rebooted with
flask_enforcing = 1. But when I started the domU using "xm create domU.cfg", it can
still create it successfully.
   Since I removed the "create" operation in the policy, why dom0 can still create a
domU labeled with domHU_t? any idea? thanks.


      Best Regards,
               Baozeng Ding

Re: XSM/FLASK questions

[Daniel De Graaf]

On 03/13/2013 09:52 AM, baozeng@nfs.iscas.ac.cn wrote:
> Hello all,
>      I played with Xen 4.1.0, XSM/FLASK module to see whether it works well or not. I
> changed the policy file to make dom0 cannot create a domU labeled with domHU_t
> type.  The policy.conf generated using "make policy" command is as the
> following:
>      type domHU_t, domain_type;
>      allow dom0_t domHU_t:domain {max_vcpus setdomainmaxmem
>
>                                  setaddrsize getdomaininfo hypercall
>
>                                  setvcpucontext scheduler unpause
>
>                                  getvcpuinfo getaddrsize getvcpuaffinity}; //I
> removed "create"
>
>     Then I added the label domHU_t for a domU in its configure file as the following:
>
>     access_control = ['policy=,label=system_u:system_r:domHU_t']
>
> After that I made install the FLASK policy using "make install" and rebooted with
> flask_enforcing = 1. But when I started the domU using "xm create domU.cfg", it can
> still create it successfully.
>     Since I removed the "create" operation in the policy, why dom0 can still create a
> domU labeled with domHU_t? any idea? thanks.
>
>
>        Best Regards,
>                 Baozeng Ding
>

You may want to ensure that the policy is being loaded - you need to
reference it in your grub menu.lst as another module to xen. You can
verify this using xl dmesg or "xl list -Z" - with no policy loaded, dom0
is labeled "dom0" instead of the "system_u:system_r:dom0_t" as defined in
the policy. I am not familiar labeling in xm's config file, so I assume
that your syntax works in 4.1; in xl, it would need to be written as:

seclabel='system_u:system_r:domHU_t'

You may also want to check that there isn't another allow rule that you
didn't remove by running:

sesearch -A -s dom0_t -t domHU_t -c domain -p create /boot/xenpolicy.24

This will return empty output if there is no allow rule.

-- 
Daniel De Graaf
National Security Agency

Re: XSM/FLASK questions

[baozeng]

On 星期四, 三月 14, 2013 12:55 am, Daniel De Graaf wrote:
-----------------------------------------------------------------------------------
On 03/13/2013 09:52 AM, baozeng@nfs.iscas.ac.cn wrote:
> Hello all,
>      I played with Xen 4.1.0, XSM/FLASK module to see whether it works well or not. I
> changed the policy file to make dom0 cannot create a domU labeled with domHU_t
> type.  The policy.conf generated using "make policy" command is as the
> following:
>      type domHU_t, domain_type;
>      allow dom0_t domHU_t:domain {max_vcpus setdomainmaxmem
>
>                                  setaddrsize getdomaininfo hypercall
>
>                                  setvcpucontext scheduler unpause
>
>                                  getvcpuinfo getaddrsize getvcpuaffinity}; //I
> removed "create"
>
>     Then I added the label domHU_t for a domU in its configure file as the following:
>
>     access_control = ['policy=,label=system_u:system_r:domHU_t']
>
> After that I made install the FLASK policy using "make install" and rebooted with
> flask_enforcing = 1. But when I started the domU using "xm create domU.cfg", it can
> still create it successfully.
>     Since I removed the "create" operation in the policy, why dom0 can still create a
> domU labeled with domHU_t? any idea? thanks.
>
>
>        Best Regards,
>                 Baozeng Ding
>

You may want to ensure that the policy is being loaded - you need to
reference it in your grub menu.lst as another module to xen.
I added it in the grub menu.lst. I use "xl dmesg", it shows:
...
(XeN) XSM Framework v1.0.0 initialized
(XEN) Policy len  0x125d, start at 011fe000.
(XEN) Flask:  Initializing.
(XEN) AVC INITIALIZED
(XEN) Flask:  policydb table sizes (8,7) do not match mine (8,5)
(XEN) Flask:  Starting in enforcing mode.
...

I use "xl list -Z", it shows:

option `Z' not supported.
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  2211     8     r-----     316.1

I have no idea why dom0 is not labeled with the type defined in the policy.

You can
verify this using xl dmesg or "xl list -Z" - with no policy loaded, dom0
is labeled "dom0" instead of the "system_u:system_r:dom0_t" as defined in
the policy. I am not familiar labeling in xm's config file, so I assume
that your syntax works in 4.1; in xl, it would need to be written as:

seclabel='system_u:system_r:domHU_t'

You may also want to check that there isn't another allow rule that you
didn't remove by running:

sesearch -A -s dom0_t -t domHU_t -c domain -p create /boot/xenpolicy.24

This will return empty output if there is no allow rule.

I tested and there is no allow rule. Moreover, I defined a new type: domEvil_t as
the following:

  type domEvil_t, domain_type;
  neverallow dom0_t domEvil_t:domain {create max_vcpus setdomainmaxmem
                            setaddrsize getdomaininfo hypercall
                            setvcpucontext scheduler unpause
                            getvcpuinfo getaddrsize getvcpuaffinity};

This policy means that a domain labeled with domEvil_t cannot be created. But when I
tested it, this new type domain can still be created by dom0. What am I missing?

Another question is: I find that XSM/ACM was removed from the latest Xen 4.2.x, only
remaining XSM/FLASK. Does that mean XSM/FLASK can implement all the
functions/policies that XSM/ACM supports and therefore there is no need to maintain
XSM/ACM? I know that XSM/ACM supports Chinese Wall policy well, can we use XSM/FLASK
to implement Chinese Wall policy? Thanks.

ps. In Xen 4.1.0, I enabled XSM/ACM module and loaded a Chinese Wall policy. When
dom0 created a domU, it always caused the machine reboot , I do not know why (Maybe
there is a bug in XSM/ACM for Xen 4.1.0?) and so I have to turn to XSM/FLASK module.
However I find XSM/FLASK cannot work well as I expected.


--
Best Regards,
Baozeng Ding.

-- 
Daniel De Graaf
National Security Agency

-----------------------------------------------------------------------------------


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