10:33 a.m.
On 06/04/2013 04:06 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange(a)redhat.com>
Historically security issues in libvirt have been primarily
triaged & fixed by the Red Hat libvirt members & Red Hat
security team, who then usually notify other vendors via
appropriate channels. There have been a number of times
when vendors have not been properly notified ahead of
announcement. It has also disadvantaged community members
who have to backport fixes to releases for which there are
no current libvirt stable branches.
To address this, we want to make the libvirt security process
entirely community focused / driven. To this end I have setup
a new email address "libvirt-security(a)redhat.com" for end
users to report bugs which have (possible) security implications.
This email addr is backed by an invitation only, private
archive, mailing list. The intent is for the list membership
to comprise a subset of the libvirt core team, along with any
vendor security team engineers who wish to participate in a
responsible disclosure process for libvirt. Members of the
list will be responsible for analysing the problem to determine
if a security issue exists and then issue fixes for all current
official stable branches & git master.
I am proposing the following libvirt core team people as
members of the security team / list (all cc'd):
Daniel Berrange (Red Hat)
Eric Blake (Red Hat)
Jiri Denemar (Red Hat)
Daniel Veillard (Red Hat)
Jim Fehlig (SUSE)
Doug Goldstein (Gentoo)
Guido Günther (Debian)
We don't have anyone from Ubuntu on the libvirt core team.
Serge Hallyn is the most frequent submitter of patches from
Ubuntu in recent history, so I'd like to invite him to join.
Alternatively, Serge, feel free to suggest someone else to
represent Ubuntu's interests.
Is it worth adding any BSD representation? Roman Bogorodskiy might be
the best candidate on that front.
If any other vendors/distros have security people who are
responsible for dealing with libvirt security issues, and
want to join to get early disclosure of issues, they can
suggest people. Existing security team members will vet /
approve such requests to ensure they are genuine.
Anyone on the team / list will be **required** to honour any
embargo period agreed between members for non-public issues
that are reported. The aim will be to have a maximum 2 week
embargo period in the common case, extendable to 1 month if
there is sufficient justification made. If anyone feels they
are unable to follow such an embargo process for whatever
reason, please decline membership of the security list/team.
The patch which follows puts up some docs on the website
about all of this....
Document how to report security bugs and the process that
will be used for addressing them.
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
docs/bugs.html.in | 12 +++++
docs/contact.html.in | 12 +++++
docs/securityprocess.html.in | 113 +++++++++++++++++++++++++++++++++++++++++++
docs/sitemap.html.in | 4 ++
4 files changed, 141 insertions(+)
create mode 100644 docs/securityprocess.html.in
Thanks for tackling this. It definitely sounds useful, especially as
your pending work on ACLs will mean that more issues might have CVE
status (previously, a bug was generally treated as CVE-worthy only if it
was provable that a read-only connection could cause denial-of-service
to a read-write connection; but with ACLs, any action on a read-write
connection that violates ACL boundaries of any other connection is a CVE).
diff --git a/docs/bugs.html.in b/docs/bugs.html.in
index 3d79b32..71e43e4 100644
--- a/docs/bugs.html.in
+++ b/docs/bugs.html.in
@@ -7,6 +7,18 @@
<ul id="toc"></ul>
+ <h2><a name="security">Security Issues</a></h2>
+
+ <p>
+ If you think that an issue with libvirt may have security
+ implications, <strong>please do not</strong> publically
s/publically/publicly/
+ report it in the bug tracker, mailing lists, or irc. Libvirt
+ has <a href="securityprocess.html">a dedicated process for
handling (potential) security issues</a>
Wrap the long line?
+ that should be used instead. So if your issue has security
+ implications, ignore the rest of this page and follow the
+ <a href="securityprocess.html">security process</a>
instead.
+ </p>
+
<h2><a name="bugzilla">Bug Tracking</a></h2>
<p>
diff --git a/docs/contact.html.in b/docs/contact.html.in
index e34de67..51cc775 100644
--- a/docs/contact.html.in
+++ b/docs/contact.html.in
@@ -6,6 +6,18 @@
<ul id="toc"></ul>
+ <h2><a name="security">Security Issues</a></h2>
+
+ <p>
+ If you think that an issue with libvirt may have security
+ implications, <strong>please do not</strong> publically
copy-paste, so same comments as above.
+ report it in the bug tracker, mailing lists, or irc. Libvirt
+ has <a href="securityprocess.html">a dedicated process for
handling (potential) security issues</a>
> + that should be used
instead. So if your issue has security
> + implications, ignore the rest of this page and follow the
> + <a href="securityprocess.html">security process</a>
instead.
> + </p>
> +
> <h2><a name="email">Mailing lists</a></h2>
>
> <p>
> diff --git a/docs/securityprocess.html.in b/docs/securityprocess.html.in
> new file mode 100644
> index 0000000..c29ae80
> --- /dev/null
> +++ b/docs/securityprocess.html.in
> @@ -0,0 +1,113 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> +<html xmlns="http://www.w3.org/1999/xhtml">
> + <body>
> +
> + <h1>Security Process</h1>
> +
> + <ul id="toc"></ul>
> +
> + <p>
> + The libvirt project believes in responsible disclosure of
> + security problems, to allow vendors time to prepare and
> + distribute patches for problems ahead of their publication.
> + This page describes how the process works and how to report
> + potential security issues.
> + </p>
> +
Should we add a blurb on what comprises a security issue (such as my
above comment about a read-only connection libvirtd crash)? Likewise,
it might be worth describing why many libvirtd crashers have not been
considered CVEs (again, ACL work may change that, but explaining the
historical situation will help readers learn the importance of privilege
escalation as being fundamental to a security flaw). That is, if a
libvirtd crash can only be triggered by a read-write connection, we have
historically argued that the only people that can make a read-write
connection have generally already been given full access to the system
in ways that do not require libvirt in the middle, and therefore the
libvirtd crash was not adding anything to the power that they already had.
+ <h2><a name="reporting">Reporting security
issues</a></h2>
+
+ <p>
+ In the event that a bug in libvirt is found which is
+ believed to have (potential) security implications there
+ is a dedicated contact to which a bug report / notification
+ should be directed. Send an email with as many details of
+ the problem as possible (ideally with steps to reproduce)
+ to the following email address:
+ </p>
+
+ <pre>
+<a
href="mailto:libvirt-security@redhat.com">libvirt-security@redhat.com</a></pre>
+
+ <p>
+ NB. while this email address is backed by a mailing list, it
+ is invitation only and moderated for non-members. As such you
+ will receive an auto-reply indicating the report is held for
+ moderation. Postings by non-members will be approved by a
+ moderator and the reporter copied on any replies.
+ </p>
+
+ <h2><a name="seclist">Security team</a></h2>
+
+ <p>
+ The libvirt security team is made up of a subset of the libvirt
+ core development team which covers the various distro maintainers
+ of libvirt, along with nominated security engineers representing
+ the various vendors who distribute libvirt. The team is responsible
+ for analysing incoming reports from users to identify whether a
Should I even bother with US vs. UK spelling? :)
+ security problem exists and its severity. It then works to
produce
+ a fix for all official stable branches of libvirt and co-ordinate
+ embargo dates between vendors to allow simultaneous release of the
+ fix by all affected parties.
+ </p>
Maybe worth mentioning that we strive to mention the CVE number in any
git commit that is finally pushed at the time the embargo is listed.
+
+ <p>
+ If you are a security representative of a vendor distributing
+ libvirt and would like to join the security team, send an email
+ to the afore-mentioned security address. Typically an existing
+ member of the security team will have to vouch for your credentials
+ before membership is approved. All members of the security team
+ are <strong>required to respect the embargo policy</strong>
+ described below.
+ </p>
+
+ <h2><a name="embargo">Publication embargo
policy</a></h2>
+
+ <p>
+ The libvirt security team operates a policy of
+ <a
href="http://en.wikipedia.org/wiki/Responsible_disclosure">r...
disclosure</a>.
+ As such any security issue reported, that is not already publically disclosed
s/publically/publicly/
+ elswhere, will have an embargo date assigned. Members of the
security team agree
s/elswhere/elsewhere/
+ not to publically disclose any details of the security issue
until the embargo
s/publically/publicly/
+ date expires.
+ </p>
Should we mention that this list is still useful even for zero-day bugs
(those that already have public disclosure), if only for assigning the
CVE and ensuring that vendors pick up on the fix as fast as possible?
+
+ <p>
+ The general aim of the team is to have embargo dates which
+ are two weeks or less in duration. If a problem is identified
+ with a proposed patch for a security issue, requiring further
+ investigation and bug fixing, the embargo clock may be restarted.
+ In exceptional circumstances longer initial embargos may be
s/embaros/embargoes/
+ negotiated by mutual agreement between members of the
security
+ team and other relevant parties to the problem. Any such extended
+ embargoes will aim to be at most one month in duration.
Should we mention that a one month maximum also corresponds to the
typical mainline release schedule?
+ </p>
+
+
+ <h2><a name="cve">CVE allocation</a></h2>
+
+ <p>
+ The libvirt security team will associate each security issue with
+ a CVE number. The CVE numbers will usually be allocated by one of
+ the vendor security engineers on the security team.
+ </p>
+
+ <h2><a name="branches">Branch fixing
policy</a></h2>
+
+ <p>
+ The libvirt community maintains one or more stable release branches
+ at any given point in time. The security team will aim to publish
+ fixes for GIT master (which will become the next major release) and
+ each currently maintained stable release branch. The distro maintainers
+ will be responsible for backporting the officially published fixes to
+ other release branches where applicable.
+ </p>
+
+ <h2><a name="notification">Notification of
issues</a></h2>
+
+ <p>
+ When an embargo expires, security issues will be announced on both
+ the libvirt development and announcement <a
href="http://libvirt.org/contact.html#email">mailing lists</a>.
We haven't always announced CVEs on the announcement list, other than
mentioning them in passing as part of the release notes for a new
version; but this policy makes sense.
+ </p>
+ </body>
+</html>
diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in
index cb7cc5b..fd10caf 100644
--- a/docs/sitemap.html.in
+++ b/docs/sitemap.html.in
@@ -349,6 +349,10 @@
<span>How and where to report bugs and request features</span>
<ul>
<li>
+ <a href="securityprocess.html">Security Process</a>
+ <span>Security bug reporting and resolution process</span>
+ </li>
+ <li>
<a href="todo.html">Todo list</a>
<span>Main feature request list</span>
</li>
ACK - I like where this is headed, and think you can fix up the places I
pointed out, and/or post a followup patch that adds more details to the
page.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org