From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58225) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YstNz-0003Ps-56 for qemu-devel@nongnu.org; Thu, 14 May 2015 09:41:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YstNw-0007g7-9U for qemu-devel@nongnu.org; Thu, 14 May 2015 09:41:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59317) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YstNw-0007fP-2P for qemu-devel@nongnu.org; Thu, 14 May 2015 09:41:12 -0400 Date: Thu, 14 May 2015 14:41:05 +0100 From: "Daniel P. Berrange" Message-ID: <20150514134105.GJ3441@redhat.com> References: <20150513174204.GS23627@redhat.com> <5553C651.4060000@redhat.com> <20150514111825.GE3441@redhat.com> <878ucr4bb7.fsf@blackfin.pond.sub.org> <555490EE.1040802@redhat.com> <87egmjz5sl.fsf@blackfin.pond.sub.org> <55549ABD.2050202@redhat.com> <908546719.20150514152539@eikelenboom.it> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <908546719.20150514152539@eikelenboom.it> Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Do not emulate a floppy drive when -nodefaults Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sander Eikelenboom Cc: Kevin Wolf , xen-devel@lists.xensource.com, mst@redhat.com, Stefano Stabellini , Markus Armbruster , qemu-devel@nongnu.org, Paolo Bonzini , John Snow , rth@twiddle.net On Thu, May 14, 2015 at 03:25:39PM +0200, Sander Eikelenboom wrote: > > Thursday, May 14, 2015, 2:53:17 PM, you wrote: > > > > > On 14/05/2015 14:45, Markus Armbruster wrote: > >> Paolo Bonzini writes: > >> > >>> On 14/05/2015 14:02, Markus Armbruster wrote: > >>>> It should certainly be off for pc-q35-2.4 and newer. Real Q35 boards > >>>> commonly don't have an FDC (depends on the Super I/O chip used). > >>>> > >>>> We may want to keep it off for pc-i440fx-2.4 and newer. I doubt > >>>> there's a real i440FX without an FDC, but our virtual i440FX is quite > >>>> unlike a real one in other ways already. > >>> > >>> That would break libvirt for people upgrading from 2.3 to 2.4. So it's > >>> more like pc-i440fx-3.0 and pc-q35-3.0. > >> > >> What exactly breaks when? > > > libvirt expects "-nodefaults -drive if=none,id=fdd0,... -global > > isa-fdc.driveA=fdd0" to result in a machine with a working FDD. It > > doesn't know that it has to add "-machine fdc=on". > > > Besides, adding a new machine option is not the best we can do. If the > > default is "no FDC", all that is needed to add one back is -device. An > > FDC is yet another ISA device, it is possible to create one with -device. > > >> add the magic to make -global isa-fdc... auto-set the option to on. > > > That would be ugly magic. > > > The more I think about this, the more I think this is just a kneejerk > > reaction to a sensationalist announcement. The effect of this > > vulnerability on properly configured data centers (running > > non-prehistoric versions of Xen or KVM and using > > stubdom/SELinux/AppArmor properly) should be really close to zero. > > > It's a storm in a tea cup. > > > Paolo > > I tend to kindly disagree if you look at the broader perspective, yes it's could > be a storm in a tea cup, but there seems to be a pattern. > > From a "cmdline user" / "platform emulation" point of view i can imagine that some sort of > auto configuration / bundling in platforms is necessary (to limit the length of > the cmdline to be supplied). > > But from a library / toolstack point of view it's quite nasty if *all* more or > less obscure options have to actively disabled. It's quite undoable, not to mention what > happens when new ones get added. > > From this PoV it would be better to have to actively enable all the stuff you want. > > At least Xen seemed to have taken the "no-defaults" as the best option to get > there so far, but that doesn't seem to > > It's not the first CVE that has come from this "you have to actively disable all > you don't want to happen" and probably won't be the last. > > So a "-no-defaults-now-for-real" option/mode for libraries / toolstacks, that > requires them to be very verbose, explicit and specific in what they actually > want, could be valuable. That doesn't really scale to be honest - a -no-defaults-now-for-real basically means deleting the entire concept of machine types, and requiring every single aspect of the base chipset to be explicitly configured. That's certainly possible but its a massive code job for QEMU and the management apps using QEMU. In fact the amount of code we'll have to write to achieve that in both QEMU and libvirt would probably introduce more bugs, so its questionable whether it would even be a net win in terms of reducing CVEs. Even if you disable some more default devices, the amount of code that'll be taken out of the attack surface is going to be tiny compared to the amount of code that will always remain due to the feature needs of the OS. So even with more default devices disabled, we have to assume that we will continue to see CVEs in stuff that remains and so must ensure we can mitigate the risks such that they have negligble impact on people who have deployed QEMU. ie the goal should be that a guest attack on QEMU ends up being nothing worse than a denial of service on attacker themselves. This is why using technologies such as SELinux, AppArmour, StubDomains and seccomp are so important when running QEMU. There is scope for applying more such as kernel namespaces to further isolate QEMU processes from each other. With these defences in place these kind of bugs really do become a storm in a teacup as Paolo suggests. That's not to say they are not important to fix, but we need to have some perspective about where efforts should be best focused to reduce our security risk. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel P. Berrange" Subject: Re: [Xen-devel] [PATCH] Do not emulate a floppy drive when -nodefaults Date: Thu, 14 May 2015 14:41:05 +0100 Message-ID: <20150514134105.GJ3441@redhat.com> References: <20150513174204.GS23627@redhat.com> <5553C651.4060000@redhat.com> <20150514111825.GE3441@redhat.com> <878ucr4bb7.fsf@blackfin.pond.sub.org> <555490EE.1040802@redhat.com> <87egmjz5sl.fsf@blackfin.pond.sub.org> <55549ABD.2050202@redhat.com> <908546719.20150514152539@eikelenboom.it> Reply-To: "Daniel P. Berrange" Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: <908546719.20150514152539@eikelenboom.it> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Sander Eikelenboom Cc: Kevin Wolf , xen-devel@lists.xensource.com, mst@redhat.com, Stefano Stabellini , Markus Armbruster , qemu-devel@nongnu.org, Paolo Bonzini , John Snow , rth@twiddle.net List-Id: xen-devel@lists.xenproject.org On Thu, May 14, 2015 at 03:25:39PM +0200, Sander Eikelenboom wrote: > > Thursday, May 14, 2015, 2:53:17 PM, you wrote: > > > > > On 14/05/2015 14:45, Markus Armbruster wrote: > >> Paolo Bonzini writes: > >> > >>> On 14/05/2015 14:02, Markus Armbruster wrote: > >>>> It should certainly be off for pc-q35-2.4 and newer. Real Q35 boards > >>>> commonly don't have an FDC (depends on the Super I/O chip used). > >>>> > >>>> We may want to keep it off for pc-i440fx-2.4 and newer. I doubt > >>>> there's a real i440FX without an FDC, but our virtual i440FX is quite > >>>> unlike a real one in other ways already. > >>> > >>> That would break libvirt for people upgrading from 2.3 to 2.4. So it's > >>> more like pc-i440fx-3.0 and pc-q35-3.0. > >> > >> What exactly breaks when? > > > libvirt expects "-nodefaults -drive if=none,id=fdd0,... -global > > isa-fdc.driveA=fdd0" to result in a machine with a working FDD. It > > doesn't know that it has to add "-machine fdc=on". > > > Besides, adding a new machine option is not the best we can do. If the > > default is "no FDC", all that is needed to add one back is -device. An > > FDC is yet another ISA device, it is possible to create one with -device. > > >> add the magic to make -global isa-fdc... auto-set the option to on. > > > That would be ugly magic. > > > The more I think about this, the more I think this is just a kneejerk > > reaction to a sensationalist announcement. The effect of this > > vulnerability on properly configured data centers (running > > non-prehistoric versions of Xen or KVM and using > > stubdom/SELinux/AppArmor properly) should be really close to zero. > > > It's a storm in a tea cup. > > > Paolo > > I tend to kindly disagree if you look at the broader perspective, yes it's could > be a storm in a tea cup, but there seems to be a pattern. > > From a "cmdline user" / "platform emulation" point of view i can imagine that some sort of > auto configuration / bundling in platforms is necessary (to limit the length of > the cmdline to be supplied). > > But from a library / toolstack point of view it's quite nasty if *all* more or > less obscure options have to actively disabled. It's quite undoable, not to mention what > happens when new ones get added. > > From this PoV it would be better to have to actively enable all the stuff you want. > > At least Xen seemed to have taken the "no-defaults" as the best option to get > there so far, but that doesn't seem to > > It's not the first CVE that has come from this "you have to actively disable all > you don't want to happen" and probably won't be the last. > > So a "-no-defaults-now-for-real" option/mode for libraries / toolstacks, that > requires them to be very verbose, explicit and specific in what they actually > want, could be valuable. That doesn't really scale to be honest - a -no-defaults-now-for-real basically means deleting the entire concept of machine types, and requiring every single aspect of the base chipset to be explicitly configured. That's certainly possible but its a massive code job for QEMU and the management apps using QEMU. In fact the amount of code we'll have to write to achieve that in both QEMU and libvirt would probably introduce more bugs, so its questionable whether it would even be a net win in terms of reducing CVEs. Even if you disable some more default devices, the amount of code that'll be taken out of the attack surface is going to be tiny compared to the amount of code that will always remain due to the feature needs of the OS. So even with more default devices disabled, we have to assume that we will continue to see CVEs in stuff that remains and so must ensure we can mitigate the risks such that they have negligble impact on people who have deployed QEMU. ie the goal should be that a guest attack on QEMU ends up being nothing worse than a denial of service on attacker themselves. This is why using technologies such as SELinux, AppArmour, StubDomains and seccomp are so important when running QEMU. There is scope for applying more such as kernel namespaces to further isolate QEMU processes from each other. With these defences in place these kind of bugs really do become a storm in a teacup as Paolo suggests. That's not to say they are not important to fix, but we need to have some perspective about where efforts should be best focused to reduce our security risk. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|