Hello all, Thank you so much for the comments and inptus, I appreciate it.
+-- On Tue, 14 Jul 2020, Michael S. Tsirkin wrote --+ | On Tue, Jul 14, 2020 at 11:22:28AM +0100, Peter Maydell wrote: | > On Tue, 14 Jul 2020 at 11:12, Michael S. Tsirkin <m...@redhat.com> wrote: | > > And for people who want to build QEMU with lots of functionality (like | > > Fedora does), I think a -security flag would be a useful addition. | > > We can then tell security researchers "only a high security issue | > > if it reproduces with -security=high, only a security issue | > > if it reproduces with -security=low". | > | > I think a -security option would also be useful to users -- it makes it | > easier for them to check "is this configuration using something that I | > didn't realize was not intended to be secure". For me, something useful | > for our users is much more compelling than "this might make security | > researchers' lives a bit easier". * General consensus seems to be that MAINTAINERS file is not best suited for such security related annotation. * We generally ask researchers if the issue is reproducible with '-enable-kvm', so it excludes TCG use cases. | -security level | Set minimal required security level of QEMU. | | high: block use of QEMU functionality which is intended to be secure against | malicious guests. secure -> insecure, I think? | low: allow use of all QEMU functionality, best effort security | against malicious guests. | | Default would be -security low. | | Does this look reasonable? | | Just a correction to what I wrote: I no longer think it's reasonable to | classify the severity of a security issue automatically. E.g. a qemu | crash in virtio code is a high severity security issue if it triggers | with platform_iommu=on since it is then driver from guest userspace, and | low severity one without since then it's driven from a guest driver. | | So I think we can add something like this to security.rst and to | the wiki: | | only a security issue if it | reproduces with -security high, a regular bug if it only reproduces with | -security low | | Prasad? IIUC: * QEMU would abort(3), if a user attempts to start QEMU with insecure options like say -virtfs OR -fda fat:floopy OR -netdev user OR -device tulip ? * One way could be to abort(3) at options parsing stage, if 'security' flag is set to high(1) and continue further if it is low(0). * ie. for each option we'd need do define if it is safe or not? Does that seem right? OR do we maintain a run time list of features/options deemed to be safe? Either way, we need to define some place, which QEMU functions/devices/backends etc. are safe. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
