On Sunday 05 July 2009 06:36:05 Daniel P. Berrange wrote: > > 2. For files on read-only file systems, don't do anything ... they are > > protected about as much as they can be. > > As has been mentioned in the bug you raised several days ago, this issue > should already be addressed > > https://bugzilla.redhat.com/show_bug.cgi?id=507555 I am still looking for the update libvirt to be post to updates-testing. > > > 4. For ISO files, maybe there should be a new/special file context which > > allows sharing between processes ... it would be explicit but it would > > allow sharing ... maybe something like "public_content_t". > > There is already a label for read only guest images > > system_u:object_r:svirt_image_t:s0 > > it shouldn't be much work for you to add a custom SELinux plugin that > gives httpd_t access to content labelled svirt_image_t. Ask the > fedora-selinux mailing list for assistance if needed I believe this is backwards from the way things should work. Please see my new bugzilla report: https://bugzilla.redhat.com/show_bug.cgi?id=509834 sVirt is the new kid on the block and should work with others not the reverse. Why should I need to create an SELinux plugin so that stuff that did work still does work? > > > 5. Maybe implement a switch which disables SELinux enforcing (and does > > not change the file context of ISO files) for Fedora-virtualization. > > Already present /etc/libvirt/qemu.conf , change security_driver="none" OK, I can certainly edit the config file myself (now that I am aware of it). However, shouldn't I be able to set this with either an SELinux boolean or via virt-manager's preferences? BTW, there are currently a number of SELinux booleans for "virt" but I am not sure what each does/means. > > > 6. Maybe the switch should be by guest. > > Easy enough to add - file a bug if you want this capability. Yes, something like this is desirable (IMHO). However, what I really want is to be able to define and build a guest without screwing up "other" shared files and/or devices but then be able to lock that guest down once it is built. The system settings for a guest in creation/build mode should not effect the settings of other guest virtuals already built This is analogous to development versus production environments. Gene -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
