Re: [Xense-devel] Labeling in XSM/Flask

["George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>]

On 7/4/08 5:11 PM, "Hayawardh V" <hayawardh@xxxxxxxxx> wrote:

> Hi George, 
> 
> I applied the patch update-xsm-061908-xen-17826.diff to Xen and specified
> (xsm_module_name flask)
> 
> in xend-config. 
> 
> I am now able to boot into dom0 in enforcing mode.
> 
> However, when I boot a domU, it has not been labeled, and does not create.
> 
> 1. How do I add labels to objects in XSM/Flask? Where will the labels be
> stored (like SELinux stores them in extended attributes in the file system) ?
> 

Labels are managed through the individual domain configuration files.  Add
the following attribute to a domU config file,

access_control = [³policy=,label=system_u:object_r:domU_t²]

domU_t is a valid type in the sample policy.  You can modify the policy to
add new types and use them accordingly.

An attribute in the config file is the closest thing that we have today to
an extended attribute for domains.  This approach has minimized the amount
of integration between the guest security and hypervisor security systems
but at the cost of reducing the guarantees that can be made over the doamin
security attributes.  Closer integration with the guest or dom0 security
environment would allow the platform security to be independent of domain
configuration files and separate protection of the security attributes from
the configuration data.  There may be other config attributes that can
effect the platform security, so my comments here are limited to the scope
of the access_control attribute.

> 2. The avc denial when I try to boot a domU is:
> (XEN) avc: denied  { create } for domid=0
> (XEN) scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:unlabeled_t
> (XEN) tclass=domain
> 
> (It has type unlabeled_t).
> 

This should be fixed by following my response to item 1.  Let me know
because this would indicate something else is wrong.

> 3. Should the initial context have been system_u:system_r:xen_t? If yes, how
> did it transition to system_u:system_r:dom0_t?
> 

This is correct.  There currently isn't support for a domain transition ala
SELinux, but that functionality will be forthcoming.

Because the initial behavior of the hypervisor is hard coded to create Dom0,
the system is built on a small collection of initial sids and a few core
policy statements designed to support getting Dom0 up and running in working
order.

The initial sids are xen_t for the hypervisor and dom0_t for the first guest
(in this case, Dom0).  The setting of the sid for the hypervisor is hard
coded in flask_domain_alloc_security and so is the sid for dom0_t through
the implicit behavior of hypervisor under xen_t.

> 4. When dom0 boots, there is a denial :
> (XEN) avc:  denied  { firmware } for domid=0
> (XEN) scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:xen_t
> (XEN) tclass=xen
> 

This is probably a platform policy nit and now that I'm back in the office I
should be able to sort this out.

> Thanks and regards,
> Hayawardh
> 
> 
> 
> _______________________________________________
> Xense-devel mailing list
> Xense-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xense-devel


-- 
George S. Coker, II <gscoker@xxxxxxxxxxxxxx>



_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel