[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field |
Date: |
Thu, 16 Jul 2020 13:54:04 +0100 |
User-agent: |
Mutt/1.14.5 (2020-06-23) |
On Thu, Jul 16, 2020 at 02:22:14PM +0200, Christian Schoenebeck wrote:
> On Donnerstag, 16. Juli 2020 12:01:57 CEST Daniel P. Berrangé wrote:
> > > My concern here is that just distinguishing between either 'low' or 'high'
> > > is a far too rough classification.
> > >
> > > In our preceding communication regarding 9pfs, I made clear that a) we do
> > > care about security relevant 9pfs issues, and only b) the avarage use
> > > cases (as far we know) for 9pfs are above a certain trust level.
> > >
> > > However b) does not imply 9pfs being 'unsafe', nor that we want users to
> > > refrain using it in a security relevant environment. So 9pfs would
> > > actually be somewhere in between.
> >
> > We shouldn't overthink this and invent many classification levels.
> >
> > This is essentially about distinguishing code that is written with the
> > intent of protecting from a malicous guest, from code that assumes a
> > non-malicious guest. That is a pretty clear demarcation on when it is
> > reasonable to use any given feature in QEMU.
> >
> > Within the set of code that is assuming a malicious guest, there are
> > still going to be varying levels of quality, and that is ok. We don't
> > need to express that programatically, the docs are still there to
> > describe the fine nuances of any given feature. We're just saying that
> > in general, this set of code is acceptable to use in combination with
> > a malicious guest, and if you find bugs we'll triage them as security
> > flaws.
>
> Yes, that would be a base consideration for any security classification. And
> it applies to 9pfs hence it would suggest 'high' for 9pfs, but ...
>
> > 9p is generally written from the POV of protecting against a malicious
> > guest, so it would be considered part of the high security set, and
> > flaws will be treated as CVEs. We don't need to be break it down into
> > any more detail than that.
>
> ... this is where it already differs from reality, as 9pfs security issues
> were both handled as CVEs as well as normal reports for years, which nobody
> objected.
Even if something is classified as "high", we still have the freedom to
decide whether each specific issue is worthy of a CVE or not.
> So I wonder how helpful it would be trying to either put 9pfs into either
> 'high' or 'low', because another observed problematic with 9pfs is that the
> degree of participation is so low, that if you try to impose certain formal
> minimum requirements to contributors, you usually never hear from them again.
>
> And BTW Prasad actually suggested the opposite classification:
I don't personally mind whether 9p is classified high or low. It is really
upto the maintainers to decide which classification best fits. I'm just
saying that I think the simple binary choice is sufficient for our needs.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, (continued)
- 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, 2020/07/14
- 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é <=
- 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, Kevin Wolf, 2020/07/14
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, Thomas Huth, 2020/07/14
- Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, Christian Schoenebeck, 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, Philippe Mathieu-Daudé, 2020/07/14
Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, Cornelia Huck, 2020/07/14
Re: [PATCH 1/1] MAINTAINERS: introduce cve or security quotient field, Dr. David Alan Gilbert, 2020/07/16