[Qemu-devel] QEMU's CVE Procedures

[John Snow]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi, everyone:

("Oh no, what monolith did John type up this time? /Golly Dang He's
really giving Markus a run for his money/")

Prompted by the recent CVE-2015-3456 ("VENOM") issue, it seems to me
that our CVE handling procedure is a little more ad-hoc than it should
reasonably be. This is not the first attempt to help rectify our CVE
process -- see Peter Maydell's 2.3 post-mortem.

Our Security Process page ( http://wiki.qemu.org/SecurityProcess )
details a list of persons one may contact when confronted with a
security issue, but it's not a mailing list of trusted persons, only a
handful of contacts. The only email list mentioned here is actually a
Red Hat list, not an upstream one.


(1) Would it be worth creating an upstream non-public list as a single
point of contact to be able to reach out to? It could include all of
the names printed here (And -- hey! Why is Peter Maydell not on this
list? ...) to make it secure and easy to grab hold of the right people
who understand the security policies.


(2) What is our CVE management policy for maintainers?
This policy page also doesn't specify what maintainers should do or
how they should handle CVEs if they are approached by e.g. the Red Hat
security team, so our policy should expand a little to include
instructions for some of the maintainers and sub-maintainers.

Not that the procedure should be complicated, but spelling it out
can't hurt. Specific policy questions follow below.


(3) How do maintainers get reviews? Who do they ask?
CVEs by nature are handled behind closed doors during the embargo
period, so patches can't just be posted to the list at large. So there
needs to be a review process in place for sub-maintainers that we can
follow to get patches properly reviewed in a secure and private manner
before the embargo date.

We could leave this process "ad-hoc" and trust that maintainers know
who to ask for reviews, but I do not want anyone accused of "slipping
in fixes" away from the eyes of the list, so a more formal procedure
will help prevent any accusations of impropriety.

We likely need a list or mechanism where we can query a portion of
developers who have agreed to assist with CVE patch reviews. This
could include the existing security team, Peter Maydell, other
sub-maintainers, developers with a lot of general experience and/or
experience with the subsystem in question.

This could be perhaps the same email list as above (expanded to
include a couple of reviewers) and those reviewers could loop in other
developers on a case-by-case basis to get appropriate reviews, or we
could create a wiki page with GPG keys and so forth of trusted
reviewers that sub-maintainers can reach out to for reviews on a
case-by-case basis.

Anything would be better than "Guess and go for it."


(4) How much review is sufficient?

A CVE patch should probably get at least one review from someone who
is not Peter Maydell or the subsystem maintainer.

After it's been looked over by these 2-3 people it should be handed
over to Peter Maydell to pre-approve prior to the embargo date being
lifted so that the patch can be pulled promptly after disclosure is
public.


(5) What should be posted on embargo day?

A pull request of the patch(es) with all of the ACKs and R-Bs acquired
during the embargo period alongside the patch being posted to
qemu-devel and qemu-stable simultaneously seems sufficient.

Any additional review or changes incurred after the embargo date can
be handled publicly and in the normal manner in response to the patch.


(6) What about qemu-stable?

Our stable process is somewhat lacking with respect to the CVE
process. It is good that we occasionally publish stable fix roundups
that downstream maintainers can base their work off of, but it would
be good to have a branch where we can have CVE fixes posted promptly.


(7) How long should we support a stable branch?

We should figure out how many stable release trees we actually intend
to support: The last two releases? The last three?

My initial guess is "Any stable branch should be managed for at least
a year after initial release."

This would put our current supported releases as 2.1, 2.2 and 2.3, so
about ~3 managed releases seems sane as an initial effort.


(8) What should our procedure for tagging stable branches be?

I am suggesting that we /can/ and *should* apply bug-fixes to the
stable branches untagged to allow people to check out and build what
are essentially "preview" builds of the upcoming stable release.

Peter has suggested that any CVE patch in particular should force a
new stable tag and cause an accompanying source tarball release
without waiting for a roundup.

This is in contrast to our current rhythm where we only push new
patches periodically as part of the roundup and tag the new stable
release then. This is undesirable because it means that users may not
be able to get bugfixes and security patches in a timely manner from
upstream -- they currently HAVE to rely on downstream maintainers.


(9) Who is going to manage these stable branches?

Currently it looks like Michael Roth, although he's not actually
listed in the MAINTAINERS file. The maintainers file lists a bunch of
apparently unsupported and orphaned stable branches, too -- we should
cull these and update the file with newer information.

Perhaps it would be pertinent (If Michael is unwilling) to give each
stable branch to a different maintainer to help keep the maintenance
burden low. Of course, the more people we ask to manage these
releases, the more complicated each individual CVE becomes, because it
increases the necessary communication between the different stable
branch maintainers.



Anyway, my apologies for the wall of text. I wanted to take this
opportunity post-venom to ask some questions to the list to see if the
interest is there in revamping our CVE policy which is in need of, at
the very least, some clarifications.

See you all next CVE :)

- --js


(Oh, and have a good weekend!)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVch++AAoJEH3vgQaq/DkOiugP/REQCM6H3q7O5CnomtEq0Gtw
WrrQ/8qyCaqRSb6VcO97wO0hQUMEy01SQ1B+HhOzHEWcO1BmhjC0GyNQpAD7JAl6
gRcYpoKa+regPCNc1Sa4eCgI7c8RoC9qygzmrRxgXYI9vGvJn3pideGJB3ubd0ej
uX8SqjxhJKMp7gLnKcBdasYfNTrazvc+8Co5I+VXj68gdSHz+qlw3/Ebgf9FIIez
jHT+jH5t98XlZ1R3zL/iQMKTJDEtrF8zAwW5IZxA3cxcl8dW3K06bWx2RQd59PGB
CQVWCelPg74JiU5d4WX06GiTf863t56K2q0JuO0pGLBhMfP0ILF5CHf9h4lG3bnJ
dtsYMrs45eJfNfQj4C54tRdXN8GVBc0XAih1QCgDP52B+rw28wZNg4CvIyYr3uCV
s9j+0+dtiQ9nX0WIkTs2sCpdhTd3Of3x3Pi/i8FlI7c53mQVoa8hW3wYpUsfnWms
LRyuMjQ0g7oxZMYlWn9XWfgmvGTk3TwP/zKRI9Bh6HqldYqhzJDsz7lzKKJsWuRG
1KFfmJWbAo96uTWFM7p/2UJSGrlN970tU+cpBXpVMsEc8F7xfqup4/6dlqX1ZX0Z
r8u9NP7jwUHcP66ZrtbrHvGOhxQiKjNiGAgXcwJWlDA4rEv90nt9IXBs6hYRd61S
QSlU9M5OTcbyskOmm7lh
=Jepd
-----END PGP SIGNATURE-----