[qemu-web PATCH v2] Add "Security Process" information to the main website

[Thomas Huth]

One reporter of a security issue recently complained that it might not
be the best idea to store our "Security Process" in the Wiki. Well, while
the page in the Wiki is protected (so that only some few people can edit
it), it is still possible that someone might find a bug in the Wiki
software to alter the page contents...
Anyway, it looks more trustworthy if we present the "Security Process"
information in the static website instead. Thus this patch adds the
information from the wiki to the Jekyll-based website now.

Signed-off-by: Thomas Huth <address@hidden>
---
 v2: Improved some sentences as suggested by Paolo

 contribute.md                  |   3 +-
 contribute/report-a-bug.md     |   7 +-
 contribute/security-process.md | 129 +++++++++++++++++++++++++++++++++
 3 files changed, 134 insertions(+), 5 deletions(-)
 create mode 100644 contribute/security-process.md

diff --git a/contribute.md b/contribute.md
index 56306e0..96901b5 100644
--- a/contribute.md
+++ b/contribute.md
@@ -3,7 +3,8 @@ title: Contribute to QEMU!
 permalink: /contribute/
 ---
 
-* Report a bug: 
[https://bugs.launchpad.net/qemu/](https://bugs.launchpad.net/qemu/)<br>[How to 
report a bug](report-a-bug/)
+* Report a bug in our bugtracker: 
[https://bugs.launchpad.net/qemu/](https://bugs.launchpad.net/qemu/)<br>
+  See also [How to report a bug](report-a-bug/) or [How to report a security 
bug](security-process/)
 
 * Clone ([or browse](https://git.qemu.org/?p=qemu.git)) the git repository: 
<br>`git clone https://git.qemu.org/git/qemu.git`
 
diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
index 441c61b..1cc42e7 100644
--- a/contribute/report-a-bug.md
+++ b/contribute/report-a-bug.md
@@ -17,10 +17,9 @@ When submitting a bug report, please try to do the following:
 
 * Do not contribute patches on the bug tracker; send patches to the mailing 
list. Follow QEMU's [guidelines about submitting 
patches](https://wiki.qemu.org/Contribute/SubmitAPatch).
 
-Do NOT report security issues (or other bugs, too) as
-"private" bugs in the bug tracker.  QEMU has a [security
-process](https://wiki.qemu.org/SecurityProcess) for issues that should
-be reported in a non-public way instead.
+Do NOT report security issues (or other bugs, too) as "private" bugs in the
+bug tracker.  QEMU has a [security process](../security-process) for issues
+that should be reported in a non-public way instead.
 
 For problems with KVM in the kernel, use the kernel bug tracker instead;
 the [KVM wiki](https://www.linux-kvm.org/page/Bugs) has the details.
diff --git a/contribute/security-process.md b/contribute/security-process.md
new file mode 100644
index 0000000..ad10627
--- /dev/null
+++ b/contribute/security-process.md
@@ -0,0 +1,129 @@
+---
+title: Security Process
+permalink: /contribute/security-process/
+---
+
+QEMU takes security very seriously, and we aim to take immediate action to
+address serious security-related problems that involve our product.
+
+Please report any suspected security vulnerability in QEMU to the following
+addresses. You can use GPG keys for respective receipients to communicate with
+us securely. If you do, please upload your GPG public key or supply it to us
+in some other way, so that we can communicate to you in a secure way, too!
+Please include the tag **\[QEMU-SECURITY\]** on the subject line to help us
+identify your message as security-related. 
+
+## QEMU Security Contact List
+
+Please copy everyone on this list:
+
+ Contact Person(s)     | Contact Address               | Company       |  GPG 
Key  | GPG key fingerprint
+:-----------------------|:------------------------------|:--------------|:---------:|:--------------------
+ Michael S. Tsirkin    | address@hidden                | Red Hat Inc.  | 
[&#x1f511;](https://pgp.mit.edu/pks/lookup?op=vindex&search=0xC3503912AFBE8E67) 
| 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
+ Petr Matousek         | address@hidden                | Red Hat Inc.  | 
[&#x1f511;](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3E786F42C44977CA) 
| 8107 AF16 A416 F9AF 18F3 D874 3E78 6F42 C449 77CA
+ Stefano Stabellini    | address@hidden        | Independent   | 
[&#x1f511;](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x894F8F4870E1AE90) 
| D04E 33AB A51F 67BA 07D3 0AEA 894F 8F48 70E1 AE90
+ Security Response Team | address@hidden               | Red Hat Inc.  | 
[&#x1f511;](https://access.redhat.com/site/security/team/contact/#contact) |
+ Michael Roth          | address@hidden        | IBM           | 
[&#x1f511;](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3353C9CEF108B584) 
| CEAC C9E1 5534 EBAB B82D 3FA0 3353 C9CE F108 B584
+ Prasad J Pandit       | address@hidden                | Red Hat Inc.  | 
[&#x1f511;](http://pool.sks-keyservers.net/pks/lookup?op=vindex&search=0xE2858B5AF050DE8D)
 | 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D 
+
+## How to Contact Us Securely
+
+We use GNU Privacy Guard (GnuPG or GPG) keys to secure communications. Mail
+sent to members of the list can be encrypted with public keys of all members
+of the list. We expect to change some of the keys we use from time to time.
+Should a key change, the previous one will be revoked.
+
+## How we respond
+
+Maintainers listed on the security reporting list operate a policy of
+responsible disclosure. As such they agree that any information you share with
+them about security issues that are not public knowledge is kept confidential
+within respective affiliated companies. It is not passed on to any third-party,
+including Xen Security Project, without your permission.
+
+Email sent to us is read and acknowledged with a non-automated response. For
+issues that are complicated and require significant attention, we will open an
+investigation and keep you informed of our progress. We might take one or more
+of the following steps:
+
+### Publication embargo
+
+As a security issue reported, that is not already publically disclosed
+elsewhere, has an embargo date assigned and communicated to reporter. Embargo
+periods will be negotiated by mutual agreement between members of the security
+team and other relevant parties to the problem. Members of the security contact
+list agree not to publically disclose any details of the security issue until
+the embargo date expires.
+
+### CVE allocation
+
+An security issue is assigned with a CVE number. The CVE numbers will usually
+be allocated by one of the vendor security engineers on the security contact
+list.
+
+## When to contact the QEMU Security Contact List
+
+You should contact the Security Contact List if:
+* You think there may be a security vulnerability in QEMU.
+* You are unsure about how a known vulnerability affects QEMU.
+* You can contact us in English. We are unable to respond in other languages.
+
+## When *not* to contact the QEMU Security Contact List
+* You need assistance in a language other than English.
+* You require technical assistance (for example, "how do I configure QEMU?").
+* You need help upgrading QEMU due to security alerts.
+* Your issue is not security related.
+
+## How impact and severity of a bug is decided
+
+All security issues in QEMU are not equal. Based on the parts of the QEMU
+sources wherein the bug is found, its impact and severity could vary.
+
+In particular, QEMU is used in many different scenarios; some of them assume
+that the guest is trusted, some of them don't. General considerations to triage
+QEMU issues and decide whether a configuration is security sensitive include:
+
+* Is there any feasible way for a malicious party to exploit this flaw and
+  cause real damage? (e.g. from a guest or via downloadable images)
+* Does the flaw require access to the management interface? Would the
+  management interface be accessible in the scenario where the flaw could cause
+  real damage?
+* Is QEMU used in conjunction with a hypervisor (as opposed to TCG binary
+  translation)?
+* Is QEMU used to offer virtualised production services, as opposed to usage
+  as a development platform?
+
+Whenever some or all of these questions have negative answers, what appears to
+be a major security flaw might be considered of low severity because it could
+only be exercised in use cases where QEMU and everything interacting with it is
+trusted.
+
+For  example, consider upstream commit [9201bb9 "sdhci.c: Limit the maximum
+block size"](http://git.qemu.org/?p=qemu.git;a=commit;h=9201bb9), an of out of
+bounds (OOB) memory access (ie. buffer overflow) issue that was found and fixed
+in the SD Host  Controller emulation (hw/sd/sdhci.c).
+
+On the surface, this bug appears to be a genuine security flaw, with 
potentially
+severe implications. But digging further down, there are only two ways to use
+SD Host Controller emulation, one is via 'sdhci-pci' interface and the other
+is via 'generic-sdhci' interface.
+
+Of these two, the 'sdhci-pci' interface had actually been disabled by default
+in the upstream QEMU releases (commit [1910913 "sdhci: Make device "sdhci-pci"
+unavailable with -device"](http://git.qemu.org/?p=qemu.git;a=commit;h=1910913)
+at the time the flaw was reported; therefore, guests could not possibly use
+'sdhci-pci' for any  purpose.
+
+The 'generic-sdhci' interface, instead, had only one user in 'Xilinx Zynq
+Baseboard emulation' (hw/arm/xilinx_zynq.c). Xilinx Zynq is a programmable
+systems on chip (SoC) device. While QEMU does emulate this device, in practice
+it is used to facilitate cross-platform developmental efforts, i.e. QEMU is
+used to write programs for the SoC device. In such developer environments, it
+is generally assumed that the guest is trusted.
+
+And thus, this buffer overflow turned out to be a security non-issue.
+
+## What to Send to the QEMU Security Contact List
+
+Please provide as much information about your system and the issue as possible
+when contacting the list.
-- 
2.18.1