I¹ve managed to reproduce a problem like the one you describe....I think it
is the same problem that you are having. The patch was missing a critical
file (xsm.py). This file used to be autogenerated and so an entry had been
made in .hgignore to avoid unintended commits of this file. A side effect
of this was that my changes to xsm.py were not picked up by mercurial and
included in the patch. xsm.py is no longer autogenerated but instead relies
on the xsm_module_name option in xend-config. The options for
xsm_module_name are dummy, acm, or flask.
I¹ve attached an updated patch that addresses this issue. To make sure you
don¹t have any cruft in your installation, blow away
/usr/lib/python/xen/util/xsm before performing a make install of the python
tools. Also make sure that your xend-config.sxp contains the following
entry,
(xsm_module_name flask)
The example configs have been updated with this option keyword but it is
commented out and the default is dummy.
Sorry for the broken patch. I¹ve got some policy work to do tomorrow before
I cut this patch loose for submission. Perhaps you can give me insight into
your hardware/system config because I¹ve been unable to reproduce this
issue.
> 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
George
On 7/7/08 11:24 PM, "Hayawardh V" <hayawardh@xxxxxxxxx> wrote:
>
>
> On Mon, Jul 7, 2008 at 1:22 PM, George S. Coker, II <gscoker@xxxxxxxxxxxxxx>
> wrote:
>>
>>
>>
>> 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.
>
> Thanks for this, but my config file has exactly the same line:
> kernel = "/boot/vmlinuz-2.6.18.8-xen"
> ramdisk = "/boot/initrd-2.6.18.8-xen.img"
> ...
> disk = ['file:/xen/fedora/fedora.fc8.img,sda1,w',
> 'file:/xen/fedora/fedora.swap,sda2,w',
> 'file:/xen/fedora/fedora.fc8.additional_disk,sda3,w']
> root = "/dev/sda1 ro"
> access_control = [ 'policy=,label=system_u:object_r:domU_t' ]
>
> However, the denial still shows up. Where else could I be 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>
>>
>>
>
>
--
George S. Coker, II <gscoker@xxxxxxxxxxxxxx>
update-xsm-070808-xen-17826.diff
Description: Binary data
_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel
|
Home