Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field

[P J P]

  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 <mst@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