[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
From: |
Michael S. Tsirkin |
Subject: |
Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field |
Date: |
Tue, 14 Jul 2020 07:02:59 -0400 |
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".
>
> thanks
> -- PMM
True. And I guess downstreams can also force the option to high or set the
default to high rather easily if they want to.
So the option would be:
-security level
Set minimal required security level of QEMU.
high: block use of QEMU functionality which is intended to be secure
against
malicious guests.
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?
--
MST
- [PATCH 0/1] MAINTAINERS: add security quotient field, P J P, 2020/07/14
- [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, P J P, 2020/07/14
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, Peter Maydell, 2020/07/14
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, Daniel P . Berrangé, 2020/07/14
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, Michael S. Tsirkin, 2020/07/14
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, Peter Maydell, 2020/07/14
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field,
Michael S. Tsirkin <=
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, P J P, 2020/07/14
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, Cornelia Huck, 2020/07/16
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, Daniel P . Berrangé, 2020/07/16
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, P J P, 2020/07/16
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, Daniel P . Berrangé, 2020/07/16
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, Christian Schoenebeck, 2020/07/16
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, Daniel P . Berrangé, 2020/07/16
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, Christian Schoenebeck, 2020/07/16
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, Daniel P . Berrangé, 2020/07/16
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, Daniel P . Berrangé, 2020/07/14