[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] XSM/FLASK questions

On 星期四, 三月 14, 2013 12:55 am, Daniel De Graaf wrote:
On 03/13/2013 09:52 AM, baozeng@xxxxxxxxxxxxxxx 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) 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:


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 
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, 
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 
XSM/ACM? I know that XSM/ACM supports Chinese Wall policy well, can we use 
to implement Chinese Wall policy? Thanks.

ps. In Xen 4.1.0, I enabled XSM/ACM module and loaded a Chinese Wall policy. 
dom0 created a domU, it always caused the machine reboot , I do not know why 
there is a bug in XSM/ACM for Xen 4.1.0?) and so I have to turn to XSM/FLASK 
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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.