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 :|
