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