I am having some problems with the design/implementation of sVirt for Fedora- virtualization on Fedora 11.
1. I am a longtime user of Fedora since FC1 and, prior to that, I used Red Hat Linux.
2. I am a big fan of SELinux and have been using it since FC3 and always run in enforcing mode. I get upset/angry when someone suggests disabling SELinux to "fix" my problems. If there is a "bug", report it and get it fixed ... do not ignore it.
3. I have also been a longtime user of VMware. However, with Fedora- virtualization on Fedora 11, I decided to "change my problem set" and give Fedora-virtualization a try ... especially since I now have an AMD Phenom II 940 which supports hardware virtualization.
I have researched and found a number of documents which provide some of the goals, etc. for sVirt. However, I have hit some undesirable characteristics and bad side effects in dealing with ISO images.
First of all, sVirt changes/sets the file context for any virtual disk, ISO image, or device (e.g., /dev/sr0) ... I am not sure what happens with LVM logical volumes because I have not tried them yet.
I understand that, with mandatory access control, a process should be denied access to all resources except those which have been explicitly permitted. I assume this is the reason for setting/changing the file context. For ISO images, this is BAD!
I have an apache (httpd) server running which has access to my repository of ISO images. After I create a virtual guest and point to an ISO image in the repository, the apache server can no longer see that ISO image! Bad, BAD! Yes, I know restorecon will fix things up but this should not happen in the first place.
Another (related) problem is that I cannot use an ISO image file on a read-only mounted file system. Why? Just what is being protected here?
As currently implemented, there is no protection between guests with respect to their individual virtual disk files. This really does need doing and it will be interesting to see how it will be done by SELinux (assuming this is protected by Fedora-virtualization applications software is not good enough).
Some suggestions:
1. I am not sure what should be done with real devices such as /dev/sr0.
2. For files on read-only file systems, don't do anything ... they are protected about as much as they can be.
3. For files in /var/lib/libvirt/images, set the file context as is now done. This is also true if I locate my read/write virtual disk (file) elsewhere.
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".
5. Maybe implement a switch which disables SELinux enforcing (and does not change the file context of ISO files) for Fedora-virtualization.
6. Maybe the switch should be by guest.
- - - - -
OK, I can see where locking down Fedora-virtualization with mandatory access control would be very interesting to some organizations such as NSA but that this would be used in a very rigidly controlled and limited system. But, this stuff has to be usable in other environments too.
- - - - - -
Finally ... IMHO, the design/implementation of SELinux for Fedora- virtualization was a bit of a quick-and-dirty approach ... do what we know how to do. I suggest that maybe some SELinux folks and some key Fedora- virtualization (especially libvirt) folks should take a week off (or maybe just a weekend), go off somewhere where you will not be bothered, and the figure out what should be done ... not "how" ... just the "should" at first. Then after some time has passed so that folks have had time to think about it, have another "session" where the "how" is considered and a roadmap is created.
Just some food for thought.
Gene
On Sat, 2009-07-04 at 12:13 -0400, Gene Czarcinski wrote:
I am having some problems with the design/implementation of sVirt for Fedora- virtualization on Fedora 11.
- I am a longtime user of Fedora since FC1 and, prior to that, I used Red Hat
Linux.
- I am a big fan of SELinux and have been using it since FC3 and always run
in enforcing mode. I get upset/angry when someone suggests disabling SELinux to "fix" my problems. If there is a "bug", report it and get it fixed ... do not ignore it.
- I have also been a longtime user of VMware. However, with Fedora-
virtualization on Fedora 11, I decided to "change my problem set" and give Fedora-virtualization a try ... especially since I now have an AMD Phenom II 940 which supports hardware virtualization.
I have researched and found a number of documents which provide some of the goals, etc. for sVirt. However, I have hit some undesirable characteristics and bad side effects in dealing with ISO images.
First of all, sVirt changes/sets the file context for any virtual disk, ISO image, or device (e.g., /dev/sr0) ... I am not sure what happens with LVM logical volumes because I have not tried them yet.
ls -alZ /dev/mapper | grep volume2 brw-rw----. root disk system_u:object_r:svirt_image_t:s0:c168,c894 vg_mybook-lv_volume2
I understand that, with mandatory access control, a process should be denied access to all resources except those which have been explicitly permitted. I assume this is the reason for setting/changing the file context. For ISO images, this is BAD!
I have an apache (httpd) server running which has access to my repository of ISO images. After I create a virtual guest and point to an ISO image in the repository, the apache server can no longer see that ISO image! Bad, BAD! Yes, I know restorecon will fix things up but this should not happen in the first place.
Another (related) problem is that I cannot use an ISO image file on a read-only mounted file system. Why? Just what is being protected here?
As currently implemented, there is no protection between guests with respect to their individual virtual disk files. This really does need doing and it will be interesting to see how it will be done by SELinux (assuming this is protected by Fedora-virtualization applications software is not good enough).
Some suggestions:
I am not sure what should be done with real devices such as /dev/sr0.
For files on read-only file systems, don't do anything ... they are protected
about as much as they can be.
- For files in /var/lib/libvirt/images, set the file context as is now done.
This is also true if I locate my read/write virtual disk (file) elsewhere.
- 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".
- Maybe implement a switch which disables SELinux enforcing (and does not
change the file context of ISO files) for Fedora-virtualization.
- Maybe the switch should be by guest.
OK, I can see where locking down Fedora-virtualization with mandatory access control would be very interesting to some organizations such as NSA but that this would be used in a very rigidly controlled and limited system. But, this stuff has to be usable in other environments too.
Finally ... IMHO, the design/implementation of SELinux for Fedora- virtualization was a bit of a quick-and-dirty approach ... do what we know how to do. I suggest that maybe some SELinux folks and some key Fedora- virtualization (especially libvirt) folks should take a week off (or maybe just a weekend), go off somewhere where you will not be bothered, and the figure out what should be done ... not "how" ... just the "should" at first. Then after some time has passed so that folks have had time to think about it, have another "session" where the "how" is considered and a roadmap is created.
Just some food for thought.
Gene
There was a libvirt/svirt test-day earlier but dwalsh was not there, and svirt was not mentioned by anyone.
I know svirt is a work in progress.
I have not tested the iso image thing but sounds like you have a good point there.
My svirt setup is very generic and i did not notice any such issues.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Sat, Jul 04, 2009 at 12:13:47PM -0400, Gene Czarcinski wrote:
- I am not sure what should be done with real devices such as /dev/sr0.
sVirt does not distinguish based on device type, rather it goes off the disk mode. Exclusive Read/write disks get a label with an mcs level specific to the guest, Read/write shared get a label with an mcs level of 0, and read-only disks get a label system_u:object_r:svirt_image_t:s0 which allows read access.
- 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
- 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
- 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"
- Maybe the switch should be by guest.
Easy enough to add - file a bug if you want this capability.
Daniel
On Sun, 5 Jul 2009 11:36:05 +0100 "Daniel P. Berrange" berrange@redhat.com wrote:
- 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
Couldn't an ISO image that's already public_content_t (or even public_content_rw_t) be left alone, as that type is already well-known and used for sharing this type of content by various means?
Paul.
On Sunday 05 July 2009 11:55:04 Paul Howarth wrote:
On Sun, 5 Jul 2009 11:36:05 +0100
"Daniel P. Berrange" berrange@redhat.com wrote:
- 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
Couldn't an ISO image that's already public_content_t (or even public_content_rw_t) be left alone, as that type is already well-known and used for sharing this type of content by various means?
Yes, exactly my point.
I believe that changing any file context should not be done. Depend on the rules in the security policy or any added with semanage apply. And then let something like public_content_t and public_content_rw_t be OK too.
Mmmm, this makes so much sense that I think I will bugzilla this.
Gene
On Mon, 2009-07-06 at 09:11 -0400, Gene Czarcinski wrote:
On Sunday 05 July 2009 11:55:04 Paul Howarth wrote:
On Sun, 5 Jul 2009 11:36:05 +0100
"Daniel P. Berrange" berrange@redhat.com wrote:
- 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
Couldn't an ISO image that's already public_content_t (or even public_content_rw_t) be left alone, as that type is already well-known and used for sharing this type of content by various means?
Yes, exactly my point.
I believe that changing any file context should not be done. Depend on the rules in the security policy or any added with semanage apply. And then let something like public_content_t and public_content_rw_t be OK too.
Mmmm, this makes so much sense that I think I will bugzilla this.
The reason that it presently relabels the disk image is that it is auto-generating a unique security context (unique category pair) for each VM, and then assigning that category pair to both the qemu-kvm process and to the disk image to isolate instances from one another. There is also a static configuration option where you can specify the desired context for the VM, in which case it shouldn't relabel the disk image.
On Monday 06 July 2009 09:29:25 Stephen Smalley wrote:
I believe that changing any file context should not be done. Depend on the rules in the security policy or any added with semanage apply. And then let something like public_content_t and public_content_rw_t be OK too.
Mmmm, this makes so much sense that I think I will bugzilla this.
The reason that it presently relabels the disk image is that it is auto-generating a unique security context (unique category pair) for each VM, and then assigning that category pair to both the qemu-kvm process and to the disk image to isolate instances from one another.
OK does this "unique security context" protect guests from each other?
I do not understand what is being protected and who are we protecting from. [with respect to ISO image files and other shared files]
I am not talking about a guest's virtual disk in /var/lib/libvirt/images (or whatever).
Regardless, I do NOT believe that sVirt should be changing file contexts. The system (security?) administrator should be controlling what contexts a file has ... it should not be happening under the sVirt covers. This is especially true when it effects other processes (my httpd example).
ISO image files should be sharable between guests as well as other processes on the system with a common file context.
Setting the file context also causes other problems when the ISO image exists in a read-only file system.
There is also a static configuration option where you can specify the desired context for the VM, in which case it shouldn't relabel the disk image.
Is there additional information somewhere about using this "static configuration option"?
I am not trying to be nit-picky about this stuff. I have and do support SELinux as a significant security improvement an applaud the efforts of NSA, Red Hat, Fedora, and others in making it a reality. I run SELinux enforcing mode and prefer that everything protected should always be the case. However, there is a difference between shared resources (files) and owned resources (files).
I am also a new fan of Fedora Virtualization and want to see it succeed. That you can run Fedora, Red Hat, Solaris, *BSDs, etc. as guests is a fantastic capability. Locking down guests with SELinux is a significant capability.
I believe I have some understanding of why organizations such as NSA and related organizations want to have locked down (restricted access) guests. However, the only true secure computer systems is an isolated one with the power off (assuming adequate physical security). We need security implemented while we "keep our sanity". The question: what is "good enough" security as oppose to "perfect" security?
When SELinux was first introduced in Fedora, the security policy was strict. Well, that turned out to be a bummer and many folks disabled SELinux. So, a targeted policy was developed and has evolved to cover more and more of the system. With Fedora 11 sVirt has been introduced as the latest evolution. But, as currently implemented, sVirt breaks protections for other (previously protected) processes. I am just saying that it needs some fine tuning or perhaps re-thinking.
Gene
On Mon, 2009-07-06 at 11:12 -0400, Gene Czarcinski wrote:
On Monday 06 July 2009 09:29:25 Stephen Smalley wrote:
I believe that changing any file context should not be done. Depend on the rules in the security policy or any added with semanage apply. And then let something like public_content_t and public_content_rw_t be OK too.
Mmmm, this makes so much sense that I think I will bugzilla this.
The reason that it presently relabels the disk image is that it is auto-generating a unique security context (unique category pair) for each VM, and then assigning that category pair to both the qemu-kvm process and to the disk image to isolate instances from one another.
OK does this "unique security context" protect guests from each other?
It provides some degree of isolation between them, yes. By default, the TE policy is being used to protect the host from the guests (by restricting what types are accessible to svirt_t), and the MCS policy is being used to isolate the guests from one another (by using unique category sets for each guest).
I do not understand what is being protected and who are we protecting from. [with respect to ISO image files and other shared files]
I am not talking about a guest's virtual disk in /var/lib/libvirt/images (or whatever).
Regardless, I do NOT believe that sVirt should be changing file contexts. The system (security?) administrator should be controlling what contexts a file has ... it should not be happening under the sVirt covers. This is especially true when it effects other processes (my httpd example).
ISO image files should be sharable between guests as well as other processes on the system with a common file context.
Setting the file context also causes other problems when the ISO image exists in a read-only file system.
There are definitely situations where relabeling should not happen. But the sVirt designers wanted some default protection out of the box, without requiring manual configuration by an admin. Thus automatic generation of MCS category pairs for each guest, with those categories applied to the process and to the virtual disk image.
There is also a static configuration option where you can specify the desired context for the VM, in which case it shouldn't relabel the disk image.
Is there additional information somewhere about using this "static configuration option"?
First, you need to use virsh edit to add/replace the seclabel entry with something like this: <seclabel type='static' model='selinux'> <label>system_u:system_r:svirt_t:s0:c1</label> </seclabel>
Note the type='static' part, which prevents libvirt from clobbering it later with a dynamically generated context.
Then you need to manually label the image file - it won't do that for you once you've defined a static label, e.g.: chcon system_u:object_r:svirt_image_t:s0:c1 /var/lib/libvirt/images/vm1.img
On 07/06/2009 12:31 PM, Stephen Smalley wrote:
On Mon, 2009-07-06 at 11:12 -0400, Gene Czarcinski wrote:
On Monday 06 July 2009 09:29:25 Stephen Smalley wrote:
I believe that changing any file context should not be done. Depend on the rules in the security policy or any added with semanage apply. And then let something like public_content_t and public_content_rw_t be OK too.
Mmmm, this makes so much sense that I think I will bugzilla this.
The reason that it presently relabels the disk image is that it is auto-generating a unique security context (unique category pair) for each VM, and then assigning that category pair to both the qemu-kvm process and to the disk image to isolate instances from one another.
OK does this "unique security context" protect guests from each other?
It provides some degree of isolation between them, yes. By default, the TE policy is being used to protect the host from the guests (by restricting what types are accessible to svirt_t), and the MCS policy is being used to isolate the guests from one another (by using unique category sets for each guest).
I do not understand what is being protected and who are we protecting from. [with respect to ISO image files and other shared files]
I am not talking about a guest's virtual disk in /var/lib/libvirt/images (or whatever).
Regardless, I do NOT believe that sVirt should be changing file contexts. The system (security?) administrator should be controlling what contexts a file has ... it should not be happening under the sVirt covers. This is especially true when it effects other processes (my httpd example).
ISO image files should be sharable between guests as well as other processes on the system with a common file context.
Setting the file context also causes other problems when the ISO image exists in a read-only file system.
There are definitely situations where relabeling should not happen. But the sVirt designers wanted some default protection out of the box, without requiring manual configuration by an admin. Thus automatic generation of MCS category pairs for each guest, with those categories applied to the process and to the virtual disk image.
There is also a static configuration option where you can specify the desired context for the VM, in which case it shouldn't relabel the disk image.
Is there additional information somewhere about using this "static configuration option"?
First, you need to use virsh edit to add/replace the seclabel entry with something like this:
<seclabel type='static' model='selinux'> <label>system_u:system_r:svirt_t:s0:c1</label> </seclabel>
Note the type='static' part, which prevents libvirt from clobbering it later with a dynamically generated context.
Then you need to manually label the image file - it won't do that for you once you've defined a static label, e.g.: chcon system_u:object_r:svirt_image_t:s0:c1 /var/lib/libvirt/images/vm1.img
I also have made a patch to virt-manager to do this from the GUI, although it has not been merged yet into Rawhide.
On Mon, 2009-07-06 at 12:31 -0400, Stephen Smalley wrote:
On Mon, 2009-07-06 at 11:12 -0400, Gene Czarcinski wrote:
On Monday 06 July 2009 09:29:25 Stephen Smalley wrote:
I believe that changing any file context should not be done. Depend on the rules in the security policy or any added with semanage apply. And then let something like public_content_t and public_content_rw_t be OK too.
Mmmm, this makes so much sense that I think I will bugzilla this.
The reason that it presently relabels the disk image is that it is auto-generating a unique security context (unique category pair) for each VM, and then assigning that category pair to both the qemu-kvm process and to the disk image to isolate instances from one another.
OK does this "unique security context" protect guests from each other?
It provides some degree of isolation between them, yes. By default, the TE policy is being used to protect the host from the guests (by restricting what types are accessible to svirt_t), and the MCS policy is being used to isolate the guests from one another (by using unique category sets for each guest).
I do not understand what is being protected and who are we protecting from. [with respect to ISO image files and other shared files]
I am not talking about a guest's virtual disk in /var/lib/libvirt/images (or whatever).
Regardless, I do NOT believe that sVirt should be changing file contexts. The system (security?) administrator should be controlling what contexts a file has ... it should not be happening under the sVirt covers. This is especially true when it effects other processes (my httpd example).
ISO image files should be sharable between guests as well as other processes on the system with a common file context.
Setting the file context also causes other problems when the ISO image exists in a read-only file system.
There are definitely situations where relabeling should not happen. But the sVirt designers wanted some default protection out of the box, without requiring manual configuration by an admin. Thus automatic generation of MCS category pairs for each guest, with those categories applied to the process and to the virtual disk image.
There is also a static configuration option where you can specify the desired context for the VM, in which case it shouldn't relabel the disk image.
Is there additional information somewhere about using this "static configuration option"?
First, you need to use virsh edit to add/replace the seclabel entry with something like this:
<seclabel type='static' model='selinux'> <label>system_u:system_r:svirt_t:s0:c1</label> </seclabel>
Thanks for the tip. Static works better for me.
system_u:system_r:svirt_t:mybookvolume2 root 2933 13.1 3.2 2420860 266352 ? Sl 19:21 0:25 /usr/bin/qemu-kvm -S -M pc -m 2047 -smp 2 -name mybookvolume2 -uuid bede1797-dea4-af3d-29c7-cf216f822f1a -monitor pty -pidfile /var/run/libvirt/qemu//mybookvolume2.pid -boot c -drive file=,if=ide,media=cdrom,index=2 -drive file=/dev/mapper/vg_mybook-lv_volume2,if=virtio,index=0,boot=on -net nic,macaddr=54:52:00:70:cc:5e,vlan=0,model=virtio -net tap,fd=17,vlan=0 -serial pty -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0 -k en-us
Note the type='static' part, which prevents libvirt from clobbering it later with a dynamically generated context.
Then you need to manually label the image file - it won't do that for you once you've defined a static label, e.g.: chcon system_u:object_r:svirt_image_t:s0:c1 /var/lib/libvirt/images/vm1.img
On Monday 06 July 2009 12:31:53 Stephen Smalley wrote:
On Mon, 2009-07-06 at 11:12 -0400, Gene Czarcinski wrote:
On Monday 06 July 2009 09:29:25 Stephen Smalley wrote:
I believe that changing any file context should not be done. Depend on the rules in the security policy or any added with semanage apply. And then let something like public_content_t and public_content_rw_t be OK too.
Mmmm, this makes so much sense that I think I will bugzilla this.
The reason that it presently relabels the disk image is that it is auto-generating a unique security context (unique category pair) for each VM, and then assigning that category pair to both the qemu-kvm process and to the disk image to isolate instances from one another.
OK does this "unique security context" protect guests from each other?
It provides some degree of isolation between them, yes. By default, the TE policy is being used to protect the host from the guests (by restricting what types are accessible to svirt_t), and the MCS policy is being used to isolate the guests from one another (by using unique category sets for each guest).
Neat!
OK, this is starting to make more sense to me. I like the idea of using the MCS policy to protect guests from each other.
As far as I can see, the MCS policy stuff has not been implemented yet ... at least with libvirt-0.6.2 ... I am still waiting for 0.6.5 to appear in Fedora 11 updates-testing. I hope this MCS policy stuff gets implemented for Fedora 11 so I can give it a try.
As far as protecting the host from guests, the act of defining a guest in the current implementation changes the host and impacts other processes (my httpd example).
I do not understand what is being protected and who are we protecting from. [with respect to ISO image files and other shared files]
I am not talking about a guest's virtual disk in /var/lib/libvirt/images (or whatever).
Regardless, I do NOT believe that sVirt should be changing file contexts. The system (security?) administrator should be controlling what contexts a file has ... it should not be happening under the sVirt covers. This is especially true when it effects other processes (my httpd example).
ISO image files should be sharable between guests as well as other processes on the system with a common file context.
Setting the file context also causes other problems when the ISO image exists in a read-only file system.
There are definitely situations where relabeling should not happen. But the sVirt designers wanted some default protection out of the box, without requiring manual configuration by an admin. Thus automatic generation of MCS category pairs for each guest, with those categories applied to the process and to the virtual disk image.
I can understand the desire to provide some protection out of the box. However, having the file contexts changed automagically should be an explicit decision by the system/security administrator ... not something done by default. If this is to be allowed, there should be an sVirt or SELinux switch which needs to be set to enable automagically setting the file context. Naturally, all this needs documentation.
BTW, when the MCS policy protection gets implemented, there needs to be something which manages the categories. When you have one, two or three guest, this can be manual but when you get a lot of guests (I currently have two defined), this can be a problem to manually manage.
I still believe that ISO image files (and perhaps other shared virtual disk files) need a special file context that allows sVirt and other processes to access the files ... make this read-only access if that is better.
Question: ... When the MCS policy stuff is implemented, will two or more guests be able to share a single ISO image file ... they should!
Yes, I know this makes things a lot more complicated but I believe it is necessary. After all, doing the targeted policy is a lot more complicated than the old strict policy but was necessary to have something actually usable.
Gene
On Mon, 2009-07-06 at 14:26 -0400, Gene Czarcinski wrote:
Neat!
OK, this is starting to make more sense to me. I like the idea of using the MCS policy to protect guests from each other.
As far as I can see, the MCS policy stuff has not been implemented yet ... at least with libvirt-0.6.2 ... I am still waiting for 0.6.5 to appear in Fedora 11 updates-testing. I hope this MCS policy stuff gets implemented for Fedora 11 so I can give it a try.
It works for me on F11 out of the box, as described in: http://fedoraproject.org/wiki/Features/SVirt_Mandatory_Access_Control#How_To...
If I start guest VMs via virt-manager or virsh, they get labeled with unique MCS category pairs and their virtual disks get labeled accordingly automatically. And when I stop them, the disks get reset to their original label and become inaccessible to any guest.
On Mon, 6 Jul 2009, Gene Czarcinski wrote:
Neat!
OK, this is starting to make more sense to me. I like the idea of using the MCS policy to protect guests from each other.
These slides from LCA should help explain the design further: http://namei.org/presentations/svirt-lca-2009.pdf
There's also a google video of the talk: http://video.google.com/videoplay?docid=5750618585157629496&hl=en
Dan Walsh is giving a talk on the topic at Linuxcon in September: http://linuxcon.linuxfoundation.org/meetings/1571
(which will be especially useful, as the code has evolved since the initial design).
On Monday 06 July 2009 18:22:42 James Morris wrote:
On Mon, 6 Jul 2009, Gene Czarcinski wrote:
Neat!
OK, this is starting to make more sense to me. I like the idea of using the MCS policy to protect guests from each other.
These slides from LCA should help explain the design further: http://namei.org/presentations/svirt-lca-2009.pdf
There's also a google video of the talk: http://video.google.com/videoplay?docid=5750618585157629496&hl=en
Dan Walsh is giving a talk on the topic at Linuxcon in September: http://linuxcon.linuxfoundation.org/meetings/1571
(which will be especially useful, as the code has evolved since the initial design).
Thank you one and all. With the provided pointers to documentation I now have a much better understanding of how sVirt is using MCS.
When I originally saw that MCS was being used to restrict guest, I immediately thought it was a static implementation but did not see anything on the virtual disk image files so I thought it was not implemented yet. However, you use MCS dynamically when a guest is actually run ... this makes more sense and is far simpler to implement and manage than any static implementation..
I see that you "only" set categories for the virtual disk images and not the ISO image file ... at least this is what I see and hope this is true ... example: i OFTEN run two or three guests which booted into rescue mode from a single netinst CD image.
I noticed that the SELinux rule for virt_image_t allows both read and write as it must.
However, the SELinux rule for virt_content_t (which is used for ISO image files) also allows both read and write ... changing this to read-only makes more sense to me.
I still believe that sVirt should not be changing the file context for ISO images (especially now that I see that categories are not set). One solution which would "scratch my itch" while still doing (more or less) what is now done is to add some global sVirt parameter to define what context to use and have this default to virt_content_t. It would also be nice if this could be overridden on a per-guest basis also.
Note that I am only talking about files which would use virt_content_t since the "static" option mentioned in a different email addresses the virtual disk image file ... at least I think it does.
BTW, it appears that sVirt picks a couple of non-zero random numbers to use for the category pair. True? If true, is any checking done so there are not any conflicts/reuse on different guests? [I am trying to avoid going to the ultimate documentation for any software ... the source code]
Gene
On 07/07/2009 01:06 PM, Gene Czarcinski wrote:
On Monday 06 July 2009 18:22:42 James Morris wrote:
On Mon, 6 Jul 2009, Gene Czarcinski wrote:
Neat!
OK, this is starting to make more sense to me. I like the idea of using the MCS policy to protect guests from each other.
These slides from LCA should help explain the design further: http://namei.org/presentations/svirt-lca-2009.pdf
There's also a google video of the talk: http://video.google.com/videoplay?docid=5750618585157629496&hl=en
Dan Walsh is giving a talk on the topic at Linuxcon in September: http://linuxcon.linuxfoundation.org/meetings/1571
(which will be especially useful, as the code has evolved since the initial design).
Thank you one and all. With the provided pointers to documentation I now have a much better understanding of how sVirt is using MCS.
When I originally saw that MCS was being used to restrict guest, I immediately thought it was a static implementation but did not see anything on the virtual disk image files so I thought it was not implemented yet. However, you use MCS dynamically when a guest is actually run ... this makes more sense and is far simpler to implement and manage than any static implementation..
I see that you "only" set categories for the virtual disk images and not the ISO image file ... at least this is what I see and hope this is true ... example: i OFTEN run two or three guests which booted into rescue mode from a single netinst CD image.
I noticed that the SELinux rule for virt_image_t allows both read and write as it must.
However, the SELinux rule for virt_content_t (which is used for ISO image files) also allows both read and write ... changing this to read-only makes more sense to me.
These are the rules in F11, it only allows read
# sesearch --allow -s svirt_t -t virt_content_t Found 2 semantic av rules: allow svirt_t virt_content_t : file { ioctl read getattr lock open } ; allow svirt_t virt_content_t : dir { ioctl read getattr lock search open } ;
I still believe that sVirt should not be changing the file context for ISO images (especially now that I see that categories are not set). One solution which would "scratch my itch" while still doing (more or less) what is now done is to add some global sVirt parameter to define what context to use and have this default to virt_content_t. It would also be nice if this could be overridden on a per-guest basis also.
Note that I am only talking about files which would use virt_content_t since the "static" option mentioned in a different email addresses the virtual disk image file ... at least I think it does.
BTW, it appears that sVirt picks a couple of non-zero random numbers to use for the category pair. True? If true, is any checking done so there are not any conflicts/reuse on different guests? [I am trying to avoid going to the ultimate documentation for any software ... the source code]
Well it does check if the MCS label is unique among svirt images and it makes sure that the to numbers are different. s0:c1,c1 == so:c1 which is not allowed.
Gene
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Monday 06 July 2009 09:11:17 Gene Czarcinski wrote:
On Sunday 05 July 2009 11:55:04 Paul Howarth wrote:
On Sun, 5 Jul 2009 11:36:05 +0100
"Daniel P. Berrange" berrange@redhat.com wrote:
- 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
Couldn't an ISO image that's already public_content_t (or even public_content_rw_t) be left alone, as that type is already well-known and used for sharing this type of content by various means?
Yes, exactly my point.
I believe that changing any file context should not be done. Depend on the rules in the security policy or any added with semanage apply. And then let something like public_content_t and public_content_rw_t be OK too.
Mmmm, this makes so much sense that I think I will bugzilla this.
On Sunday 05 July 2009 06:36:05 Daniel P. Berrange wrote:
- 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
I am still looking for the update libvirt to be post to updates-testing.
- 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?
- 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.
- 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
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Daniel P. Berrange -
Dominick Grift -
Gene Czarcinski -
James Morris -
Paul Howarth -
Stephen Smalley