On Fri, 2006-10-13 at 16:48 +0100, Robin Bowes wrote:
Robin Bowes wrote:
On other problem I've noticed is that the xendomains init script didn't start the domains at boot, or from the command-line. I've copied the new one from https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120075 but I was seeing this error:
# service xendomains start Starting auto Xen domains:Error: Disk isn't accessible
This is the context of that file:
-rwxr-xr-x root root system_u:object_r:initrc_exec_t xendomains
I copied xendomains to xendomains.new so it has this context:
-rwxr-xr-x root root root:object_r:etc_t xendomains.new
And the script now works.
Again, is this the (or a) correct fix? Any security problems with this?
Hmmm. xendomains is not starting the guest instances at reboot.
I see this error in send.log:
[2006-10-13 16:34:28 xend] ERROR (XendBootloader:36) Disk isn't accessible
I also get new AVC msgs:
allow xm_t fixed_disk_device_t:blk_file read;
When I add this to the policy file, i.e.:
class blk_file read; type fixed_disk_device_t; type xm_t; allow xm_t fixed_disk_device_t:blk_file read;
I get this error when loading the compiled policy:
# semodule -i $xen.pp libsepol.check_assertion_helper: assertion on line 0 violated by allow xm_t fixed_disk_device_t:blk_file { read }; libsepol.check_assertions: 1 assertion violations occured libsemanage.semanage_expand_sandbox: Expand module failed semodule: Failed!
Any suggestions as to how to fix this?
The assertion is to prevent accidental granting of read access to a raw disk device. Is that truly required here? To allow it, you need to use the interface for it, e.g. storage_raw_read_fixed_disk(xm_t) That interface is defined in kernel/storage.if. In addition to allowing the permission, it adds a type attribute to the type that excludes from the assertion.