On 5 June 2015 at 23:16, John Snow <js...@redhat.com> wrote:
> 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.
Thanks for raising this. Rather than trying to fit my opinions
into a per-para response format I'll just list some general
principles/opinions first:
(1) We shouldn't set ourselves a security policy we don't have
the resources to actually adhere to
(2) We should be clear about what we actually are guaranteeing
(both to end-users and to people reporting vulnerabilities)
(3) We should try to avoid an excessively formal and prescriptive
security policy/process
(4) I think the lack of timely upstream tarball releases with
security fixes is the biggest problem with our current setup
(it basically means we're saying "if you care about guest
isolation then use a distro QEMU, or monitor CVE lists and
backport patches yourself")
> (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.
We went back and forth on this one when we set up that page; see
this thread from last year:
https://lists.nongnu.org/archive/html/qemu-devel/2014-04/msg02724.html
There was concern that using a mailing list would clash with people
being able to use PGP to send us info about vulnerabilities.
I don't personally have a strong opinion (except for "using
GPG for email is a huge pain in the neck", that's a fairly
strong opinion).
The reason I'm not on the list of people notified is that
I don't have any desire to be in the first-line triage of
genuine vulnerabilities from misapprehension, user error,
non-problems and plain old spam. Having a single person as
"head developer" who has to have their fingers in every pie
is a recipe for burnout and that person leaving the project.
> (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.
Yes; we should also perhaps mention in our page for people
disclosing vulnerabilities that we'll inform the relevant
QEMU submaintainer(s) as part of our response.
> (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.
The other way round you could do it is to apply directly to
master (and stable branches) first, and then post the patches
second. That's the way round that Anthony used to do it. It
has the advantage that there is less delay before the fixes
go into master.
> (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.
Yes, and (as you note below) my ideal would be that any CVE results
in a new stable release, so we don't have the current situation
where our download page only has a 2.0 which still has various
vulnerabilities in.
However, this is where we run sharply into the "do we have the
resources to do this" question. I don't currently maintain the
stable branches and would prefer not to start...
I like Daniel's suggestion about documenting CVE issues.
I'm unconvinced about importing the Xen security policy
wholesale -- I think it is a lot more heavyweight than we
want, since we don't have a commercial company providing
people to deal with CVEs, or direct customers wanting early
notification.
We should probably write down somewhere what we consider to be
a security issue -- something like "only KVM, only <list of
architectures>, only <list of board models>".
thanks
-- PMM
