Re: About 'qemu-security' mailing list

[Darren Kenny]

Hi Prasad,

Just my 2c as someone working on a downstream distro with Qemu...

On Friday, 2020-09-18 at 12:32:23 +0530, P J P wrote:
>   Hello all,
>
> +-- On Wed, 16 Sep 2020, Stefan Hajnoczi wrote --+
> | I'm surprised the lack of encryption doesn't bother you. The security bug 
> | reporting process should be confidential to prevent disclosure of 0-days.
>
> * I think it'll work only if all issue reports are encrypted. Under current 
>   process, we've our GPG keys published, yet majority of the issue reports 
> are 
>   unencrypted. CVEs are of more interest/incentive.
>
> * Encrypted email workflow is also not as seamless as unencrypted.
>

While that is true, some aliases have managed to do something here by
having a single key for the alias, and behind the scenes that
re-encrypts the e-mail for each member of that alias (trying to avoid
the 'list' term a little here)

An example of this is the 'distro's list, e.g.:

- https://oss-security.openwall.org/wiki/mailing-lists/distros

>
> | Triaging and fixing are different things. Where is the bottleneck, triaging 
> | or fixing?
>
> * Issue triaging/analysis is lesser time; Patches may take longer, so fixing.
>
> * But having mailing-list isn't going to affect/address either.
>
>
> | Do downstream maintainers want to know about potential security bug reports 
> | that have not been triaged yet?
> | 
> | Maybe there should there be a pre-announce list for bugs that have been 
> | triaged? That saves downstream from being spammed with confidential info 
> | that they probably can't use.
>
> * I was thinking about that, an '-announce' list could be better. Because 
>   issue reports may come with reproducers (code/scripts/packet dump). And 
>   sharing such reproducers with wide-rs recipients seems risky, not right.
>
> * Such reproducers shall stay in the list archives forever. It may have some 
>   legal IP related concerns. I'm not sure.

I believe there was some resistance in the Linux kernel security space
of having things like a pre-announce message of a security issue that
has come in but is not fixed yet...

If you're looking to announce before a security issue is fixed, it
may just be better to keep it to the qemu-security members, which should
try to include at least 1, if not more, members from interested distros.
I know from past kernel security issues, it is still important to a
distro to be able to reproduce any issues if a PoC is provided.

There are some existing mechanisms for announcing security issues once
found, e.g. oss-security:

- https://oss-security.openwall.org/wiki/mailing-lists/oss-security

A lot of distros have people on this list already monitoring it and many
OSS projects do send announcements of CVEs and security issues to this,
once resolved and an embargo period has expired - including Qemu, as I'm
sure that you know, given I've seen postings from you (Prasad) there.

Why would this not be enough for that?

> | I don't think a broadcast model works well for assigning responsibility. If 
> | maintainers constantly receive security-related emails (most of which don't 
> | affect them), they will ignore them. This is what happens with broadcast CI 
> | and fuzzing results.
> | 
> | Instead someone should assign security bug reports to relevant maintainers.
> | 
> | Another option is to let reporters directly contact the maintainers (e.g. 
> | QEMU's MAINTAINERS file), but this is hard to get right and if a maintainer 
> | is on vacation the report may go unnoticed.
>
> * True, agree.
>
>  
> | Anyway, it's unclear to me what the motivation for creating a list and
> | changing the process is. Please share your goals and reasoning in more
> | detail.
>
> * Primary motivation is to address the concern that current process limits 
>   community participation.
>
> * Representatives from downstream QEMU user communities shall be notified 
>   about security issues as and when they come in.
>
> * These representatives then decide if an issue can be readily disclosed and 
>   discussed on the public 'qemu-devel' list OR needs to go through an embargo 
>   process.

These are all very important points - and the need for an embargo period
can be vital where Qemu/KVM is being widely deployed in a company.

>
>
> | I think it's worth investigating whether GitLab Issues can be configured in 
> | a secure-enough way for security bug reporting. That way HTTPS is used and 
> | only GitLab stores the confidential information (this isn't end-to-end 
> | encryption but seems better than unencrypted SMTP and plaintext emails 
> | copied across machines).
>
> +-- On Wed, 16 Sep 2020, Peter Maydell wrote --+
> | Given that we currently use launchpad for bugs we should also look at 
> | whether launchpad's "private security" bug classification would be useful 
> | for us (currently such bug reports effectively go to /dev/null but this can 
> | be fixed).
>
>
> * Bug trackers would entail that reporters must have an account there. They 
>   may create account also, but if/when they become inactive, they'll continue
>   to  receive emails or have access to security bugs.
>
>   A mailing list works more on invite-only basis that way.
>
> * Bug trackers may also face the current limitation of community participants 
>   not knowing about the issues as and when they come in.
>
> * So bug trackers need a way to send an email to a -announce/-security list,
>   sans the reproducer code/scripts/packet dump etc. information.
>
> * Between LaunchPad and GitLab, I think GitLab is preferable.
>

I would agree that Gitlab may be better here, if it would work - Gitlab
can certainly be configured to restrict access to specific projects, but
I'm not sure how that would play into logging an issue if you can't even
see the project in question as a non-member of the security team.

But I don't really know the internal workings of Gitlab, maybe there is
a way to do it.

Thanks,

Darren.