[Bug 656173] Re: libvirt no longer probes chained backing stores
I can see already a Problem with the opennebula package. It will no longer work, since it does not generate this information on the domain xmls - it would not have this information anyway - else if it would probe for the data type of the image, this - we are being told - being a security issue. @Jamie: I think the OS *in the guest* should never ever have access to the file of the image! It should only have access to the virtualized disks, not to the file itself, where the backingstore informations are. If it is now so, then the issue is rooted in qemu/kvm and not in libvirt. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. https://bugs.launchpad.net/bugs/656173 Title: libvirt no longer probes chained backing stores -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 656173] Re: libvirt no longer probes chained backing stores
@nerling: Whatever is creating the domain XML (ie with 'create' or 'define') needs to add the driver name='qemu' type='foo'/ bit, after which it is stored in the XML. If OpenNebula creates virtual machines and adds them to libvirt, it must be adjusted for this. If OpenNebula is creating virtual machines, then it should know what type of disk format it is creating. If it always creates one format, then it is easy-- OpenNebula should just add driver name='qemu' type='opennubula's disk format'/. While I am the one commenting on these changes, I would like to reiterate that these are upstream changes and not Ubuntu specific. Yes, the behavior was changed in Lucid because it can be a significant security issue and Ubuntu users need to be protected. I suggest working with OpenNebula upstream to see how they are handling libvirt's new behavior, then patches can be applied to OpenNebula on Lucid (and possibly Maverick, if it is affected also) in an SRU (https://wiki.ubuntu.com/StableReleaseUpdates) or if the patch is simple enough it can be published in the security queue like was done for virtinst and vm-builder. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. https://bugs.launchpad.net/bugs/656173 Title: libvirt no longer probes chained backing stores -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 656173] Re: libvirt no longer probes chained backing stores
** Changed in: ubuntu-release-notes Status: New = Fix Released -- libvirt no longer probes chained backing stores https://bugs.launchpad.net/bugs/656173 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 656173] Re: libvirt no longer probes chained backing stores
Suggested release note text: Previous libvirt versions would probe a qemu disk to determine its format and did not require that the format be declared in the XML. This is considered a security problem in most deployments and newer versions of libvirt will default to the 'raw' format when the format is not specified in the XML. As a result, non-raw disks without unspecified disk format will no longer be available in virtual machines. The libvirt-migrate-qemu-disks tool is provided to aid in transitioning virtual machine definitions to the new required format. In essence, it will check all domains for affected virtual machines, probe the affected disks and update the domain definition accordingly. This command will be run automatically on upgrade. See 'man 1 libvirt-migrate-qemu-disks' for details. Users who require the old behavior can adjust the 'allow_disk_format_probing' option in /etc/libvirt/qemu.conf. ** Also affects: ubuntu-release-notes Importance: Undecided Status: New -- libvirt no longer probes chained backing stores https://bugs.launchpad.net/bugs/656173 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 656173] Re: libvirt no longer probes chained backing stores
The automated run of libvirt-migrate-qemu-disks is great if your virtual machines are permanently defined within libvirt. However, if you simply inject and run a VM as needed, with something like the following: virsh create vm.xml Which is what I've been doing. The VM definitions will not hang around after the VM finishes executing. As such, this bug is very likely to silently hit you. I believe the upgrade needs a more prominent notice of this change. -- libvirt no longer probes chained backing stores https://bugs.launchpad.net/bugs/656173 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 656173] Re: libvirt no longer probes chained backing stores
Jamin, your vm.xml does not contain enough information-- you must specify the disk format when defining a new VM. Simply put, if you are using a qcow2 disk you must specify driver name='qemu' type='qcow2'/ in the vm.xml you are using. -- libvirt no longer probes chained backing stores https://bugs.launchpad.net/bugs/656173 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 656173] Re: libvirt no longer probes chained backing stores
Updated suggested release note text (my last one had a typo and I've tried to address Jamin's concerns): Previous libvirt versions would probe a qemu disk to determine its format and did not require that the format be declared in the XML. This is considered a security problem in most deployments and newer versions of libvirt will default to the 'raw' format when the format is not specified in the XML. As a result, non-raw disks without a specified disk format will no longer be available in existing virtual machines. The libvirt-migrate-qemu-disks tool is provided to aid in transitioning virtual machine definitions to the new required format. In essence, it will check all domains for affected virtual machines, probe the affected disks and update the domain definition accordingly. This command will be run automatically on upgrade. For new virtual machines using non-raw images, the disk format must be specified in the domain XML provided to libvirt, otherwise the disk will not be available to the virtual machine. See 'man 1 libvirt-migrate-qemu-disks' for details. Users who require the old behavior can adjust the 'allow_disk_format_probing' option in /etc/libvirt/qemu.conf. -- libvirt no longer probes chained backing stores https://bugs.launchpad.net/bugs/656173 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 656173] Re: libvirt no longer probes chained backing stores
Jamie, I understand that the vm.xml does not contain enough information for the version of libvirt in maverick. I understand that with maverick's version one now has to supply a disk format. However, this was not the case with libvirt under lucid. Furthermore, not providing the disk format does not result in any meaningful error message that would guide the user to the actual cause of the problem. My point is that the very same vm.xml worked perfectly under the version of libvirt in lucid. Hence this is a regression, what did work no longer works. -- libvirt no longer probes chained backing stores https://bugs.launchpad.net/bugs/656173 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 656173] Re: libvirt no longer probes chained backing stores
Jamin, that is why there will be a release note. There isn't much else that can be done. Applications change with new versions and people need to adapt the applications that use the changed applications appropriately. The tools that most people use are either already adjusted or are going to be as I mentioned in the other bug. If someone is going to be creating machines with raw XML, he/she is going to have to create the correct XML. The implication of your comments suggests that you believe the behavior should somehow change. The default (which is the same for upstream and also an upcoming lucid security update) should not change, but people who require the old behavior can adjust /etc/libvirt/qemu.conf accordingly (but why not just fix the script/template that creates the XML?). The changed behavior fixes an important security flaw in libvirt. Imagine a VM with 2 raw disks and a libvirt that probes the disk for its format. A privileged user *in the guest* could write to the beginning of the second disk the necessary (and widely known) qemu disk structure, declare some arbitrary file on the system as its backing store, then wait for a reboot. On reboot, the guest now can access that file because libvirt probes the 2nd disk, discovers it is a qcow2 with backingstore, and calls the AppArmor (or SELinux, or DAC, it doesn't matter) security driver to add it to its list of allowed files, and the attacker has access to that data (the AppArmor driver will protect against some parts of the host, such as /etc, but most of the system is available to an attacker still-- including other virtual machine's disks). Granted it is a one shot deal since the attacker won't be able to modify the disk structure once qemu recognizes it as a qcow2, but the impact is potentially very high if she gets it right. -- libvirt no longer probes chained backing stores https://bugs.launchpad.net/bugs/656173 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 656173] Re: libvirt no longer probes chained backing stores
Sure applications change with versions. However, they normally also provide useful error messages when something that was previously valid no longer is. This is *not* the case here. There is *no* error message. I'm not saying that users shouldn't provide valid XML when defining a VM. However, I am saying that if the XML being provided was previously valid and no longer is, that some clear indication about the change in validity should be given. There is no indication being given by the application. Yes, I believe the current behavior should change. No, I'm not disagreeing that this is a necessary security fix, nor am I saying that in the end this is somehow an undesired fix. What I am disputing is how the change is currently being handled. I do see that an effort has been made to migrate older configurations, and it does appear likely that this effort will catch the majority of cases. However, it won't catch all cases and the current handling leaves all remaining users wondering what the hell is going on with no guidance. I still see two points of contention. The first, and largest point of contention, is that due to the behavior change, previously valid XML configurations will now fail to operate as expected and will do so without any indication of why they are failing to operate. A change such as this should generate a log entry or something that would at least guide a user to documentation about the change and possible resolution. Perhaps an entry could be kicked out to the /var/log/libvirt/qemu/ per machine log file. Something along the lines of: WARNING: no drive image file format specified, defaulting to raw mode. Please specify drive image format. For more information please see: Second, I don't believe a blurb in the release notes alone is sufficient for this change. Why? Because, as indicated in the first point, there is no output from the application to indicate that the expected behavior has changed. Additionally, you've indicated that the existing behavior in lucid will be changing. As I understand it, this will be a simple security update. A change in behavior like this is definitely not something one would expect from a security update, not without a rather in your face notice about it. -- libvirt no longer probes chained backing stores https://bugs.launchpad.net/bugs/656173 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 656173] Re: libvirt no longer probes chained backing stores
** Summary changed: - virt-aa-helper generates incomplete apparmor profiles with chained backing files + libvirt no longer probes chained backing stores -- libvirt no longer probes chained backing stores https://bugs.launchpad.net/bugs/656173 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
