Re: [RFC 1/1] security-process: update process information

[Darren Kenny <darren.kenny@oracle.com>]

Hi Prasad,

Thanks for writing this up.

I have some comments below on the response steps.

On Tuesday, 2020-11-24 at 19:52:38 +0530, P J P wrote:
> From: Prasad J Pandit <pjp@fedoraproject.org>
>
> We are about to introduce a qemu-security mailing list to report
> and triage QEMU security issues.
>
> Update the QEMU security process web page with new mailing list
> and triage details.
>
> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
> ---
>  contribute/security-process.md | 105 +++++++++++++++++----------------
>  1 file changed, 55 insertions(+), 50 deletions(-)
>
> diff --git a/contribute/security-process.md b/contribute/security-process.md
> index 1239967..a03092c 100644
> --- a/contribute/security-process.md
> +++ b/contribute/security-process.md

...

> +## How we respond:
> +
> +* Steps to triage:
> +    - Examine and validate the issue details to confirm whether the
> +      issue is genuine and can be misused for malicious purposes.
> +    - Determine its worst case impact and severity(Low/M/I/Critical)
> +    - Negotiate embargo timeline (if required)
> +    - Request a CVE and open an upstream bug
> +    - Create an upstream fix patch
> +
> +* Above security lists are operated by select analysts, maintainers and/or
> +  representatives from downstream communities.
> +
> +* List members follow a **responsible disclosure** policy. Any non-public
> +  information you share about security issues, is kept confidential within the
> +  respective affiliated companies. Such information shall not be passed on to
> +  any third parties, including Xen Security Project, without your prior
> +  permission.
> +
> +* We aim to triage security issues within maximum of 60 days.

I always understood triage to be the initial steps in assessing a bug:

- determining if it is a security bug, in this case

- then deciding on the severity of it

I would not expect triage to include seeing it through to the point
where there is a fix as in the steps above and as such that definition
of triage should probably have a shorter time frame.

At this point, if it is not a security bug, then it should just be
logged as any other bug in Qemu, which goes on to qemu-devel then.

But, if it is a security bug - then that is when the next steps would be
taken, to (not necessarily in this order):

- negotiate an embargo (should the predefined 60 days be insufficient)

  - don't know if you need to mention that this would include downstream
    in this too, since they will be the ones most likely to need the
    time to distribute a fix

- request a CVE

- create a fix for upstream

  - distros can work on bringing that back into downstream as needed,
    within the embargo period

I do feel that it is worth separating the 2 phases of triage and beyond,
but of course that is only my thoughts on it, I'm sure others will have
theirs.

Thanks,

Darren.