Move project security pages to separate directory

This commit is contained in:
Andrew David Wong 2016-11-26 02:12:28 -08:00
parent 638fcffc51
commit fbcf95e21c
No known key found for this signature in database
GPG key ID: 8CE137352A019A17
3 changed files with 0 additions and 0 deletions

View file

@ -0,0 +1,72 @@
---
layout: doc
title: Security Bulletins
permalink: /doc/security-bulletins/
redirect_from:
- /en/doc/security-bulletins/
- /doc/SecurityBulletins/
- /wiki/SecurityBulletins/
- /trac/wiki/SecurityBulletins/
---
Qubes Security Bulletins
========================
Qubes Security Bulletins are published through the [Qubes Security Pack](/doc/security-pack/).
2010
----
- None
2011
----
- [Qubes Security Bulletin \#01](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-001-2011.txt) (Gui daemon bug, Intel VT-d escape on non-IR hardware)
2012
----
- [Qubes Security Bulletin \#02](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-002-2012.txt) (Intel SYSRET bug)
- [Qubes Security Bulletin \#03](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-003-2012.txt) (Xen hypervisor bugs: XSA 13, others with DoS potential)
- [Qubes Security Bulletin \#04](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-004-2012.txt) (Qubes firewall misconfiguration: ipv6 allowed)
- [Qubes Security Bulletin \#05](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-005-2012.txt) (Xen hypervisor bugs: XSA 29, others with DoS potential)
2013
----
- [Qubes Security Bulletin \#06](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-006-2013.txt) (Xen hypervisor bugs: XSA 50, others with DoS potential)
- [Qubes Security Bulletin \#07](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-007-2013.txt) (Xen hypervisor bugs: XSA 57 potential escalation, also XSA 52-54 with potential leaks)
- [Qubes Security Bulletin \#08](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-008-2013.txt) (Xen hypervisor bugs: XSA 45,58 potential DoS)
2014
----
- [Qubes Security Bulletin \#09](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-009-2014.txt) (Qubes qvm-open-in-[d]vm environment inter-VM leak)
- [Qubes Security Bulletin \#10](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-010-2014.txt) (Qubes pulseaudio & vchan bugs, Xen XSA 87)
- [Qubes Security Bulletin \#11](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-011-2014.txt) (Qubes clipboard inter-VM leak)
- [Qubes Security Bulletin \#12](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-012-2014.txt) (Memory leak in Xen hypervisor via RDMSR emulation bug (XSA 108))
2015
----
- [Qubes Security Bulletin \#13](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-013-2015.txt) (Qubes Clipboard Timing Attacks and Qubes Core Python API Inconsistency)
- [Qubes Security Bulletin \#14](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-014-2015.txt) (Race condition in Qubes Inter-VM File-Copy Mechanism)
- [Qubes Security Bulletin \#15](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-015-2015.txt) (Critical Xen Hypervisor Vulnerability (XSA 109))
- [Qubes Security Bulletin \#16](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-016-2015.txt) (Xen Hypervisor Information Leaks Vulnerabilities (XSA 121 & 122))
- [Qubes Security Bulletin \#17](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-017-2015.txt) (Xen DoS from malicious driver domains or devices (XSA 120 & 124))
- [Qubes Security Bulletin \#18](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-018-2015.txt) (Xen Hypervisor Instruction Emulation Bug (XSA 123))
- [Qubes Security Bulletin \#19](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-019-2015.txt) (Anti Evil Maid bypass through unusual LUKS header)
- [Qubes Security Bulletin \#20](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-020-2015.txt) (Fedora os-prober considered harmful)
- [Qubes Security Bulletin \#21](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-021-2015.txt) (Anti Evil Maid bypass through filesystem ID collision)
- [Qubes Security Bulletin \#22](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-022-2015.txt) (Critical Xen bug in PV memory virtualization code (XSA 148))
- [Qubes Security Bulletin \#23](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-023-2015.txt) (Race condition bugs in Xen code (XSA-155 and XSA-166), other Xen bugs)
2016
----
- [Qubes Security Bulletin \#24](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt) (Critical Xen bug in PV memory virtualization code (XSA 182))
- [Qubes Security Bulletin \#25](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-025-2016.txt) (Xen bug in event channel handling code (XSA 188))
- [Qubes Security Bulletin \#26](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-026-2016.txt) (Colored window border handling bug in Qubes GUI daemon)
- [Qubes Security Bulletin \#27](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-027-2016.txt) (Xen 64-bit bit test instruction emulation broken (XSA 195))

View file

@ -0,0 +1,16 @@
---
layout: doc
title: Security Goals
permalink: /doc/security-goals/
redirect_from:
- /en/doc/security-goals/
- /doc/SecurityGoals/
- /wiki/SecurityGoals/
---
Qubes Security Goals
====================
Qubes implements a Security by Isolation approach by providing the user with the ability to easily create many security domains. These domains are implemented as lightweight Virtual Machines (VMs) running under the Xen hypervisor. Qubes' main objective is to provide strong isolation between these domains, so that even if an attacker compromises one of the domains, the others are still safe. Qubes, however, does not attempt to provide any security isolation for applications running within the same domain. For example, a buggy web browser running in a Qubes domain could still be compromised just as easily as on a regular Linux distribution. The difference that Qubes makes is that now the attacker doesn't have access to all the software running in the other domains.
Qubes also provides a number of mechanisms that make it easy and convenient for the user to run multiple domains, such as seamless GUI integration onto one common desktop, secure clipboard copy and paste between domains, secure file transfer between domains, disposable VMs, and much more. Qubes also provides an advanced networking infrastructure that allows for the creation of multiple network VMs (which isolate all the world-facing networking stacks) and proxy VMs which can be used for advanced VPN and tunneling over untrusted connections.

View file

@ -0,0 +1,260 @@
---
layout: doc
title: Security Pack
permalink: /doc/security-pack/
redirect_from:
- /en/doc/security-pack/
- /doc/SecurityPack/
- /wiki/SecurityPack/
- /qsp/
- /sec-pack/
- /secpack/
- /doc/qsp/
- /doc/sec-pack/
- /doc/secpack/
---
Qubes Security Pack
===================
The **Qubes Security Pack** (`qubes-secpack`) is a Git repository that contains:
* [Qubes PGP keys](https://keys.qubes-os.org/keys/)
* [Qubes Security Bulletins (QSBs)](/doc/security-bulletins/)
* [Qubes warrant canaries](https://github.com/QubesOS/qubes-secpack/tree/master/canaries)
* [Qubes Bitcoin fund information](https://github.com/QubesOS/qubes-secpack/tree/master/fund)
* Security-related information and announcements (e.g., key revocations)
While `qubes-secpack` itself is independent of any particular host, its current
official location is:
<https://github.com/QubesOS/qubes-secpack>
History and Rationale
---------------------
On 2013-01-05, Joanna Rutkowska announced the `qubes-secpack` and explained its
rationale in an
[email](https://groups.google.com/d/msg/qubes-devel/twkOEaMLtNI/lZyGx6_jFCEJ)
to the Qubes mailing lists:
Hello,
A new Qubes Security Bulletin has been just released and is available here:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-013-2015.txt
As per the previous discussions about recent problems with verifying
digital signatures on messages sent to Google Groups (thanks to
automatic footer addition by Google), we have decided to change the way
we publish Qubes Security Bulletins, as well as other security-related
info pertinent to the Qubes Project.
Starting today, we will be maintain a Git repository -- "Qubes Security
Pack" -- which will contain all the QSBs released so far, all the keys,
warrant canaries [1], and potentially some additional info or
announcements (e.g. key revocations). The whole repo can be found here:
https://github.com/QubesOS/qubes-secpack
Note that all the keys distributed there should be signed by Qubes
Master Key. The Master Key is also attached in the repo, but should
really be obtained/verified using a different channel.
Additionally, most of the files are signed by core Qubes
developers (currently by Marek and myself) via detached signatures as
well as git tag signatures.
The are several advantages of using Git to distribute all these information:
1) Git repo is a collection of files, some of which can be detached GPG
signatures for other files and we can ensure all these files are
distributed together.
2) Git makes it easy for people to clone and redistribute these
collection of files, as well as to easily host them and view on the Web.
3) Git provides for signed tags mechanisms which is another mean we
utilize to ensure integrity of the distributed files.
A few words about the Warrant Canary which we've just introduced today,
and which can be seen here:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-001-2015.txt
Even though we're not providing any kind of services (such as e.g. email
hosting), that could be searched or tapped by authorities, there are
other possibilities that worry us [2], in the light of various recent
law "developments", such as those that might be coercing people to hand
over their private keys to authorities.
Until we fully decentralize the root of trust for Qubes, something that
requires the move to deterministic builds [3], and so won't happen
very soon, the possibility of having to disclose any of the Qubes
signing keys to anybody might have pretty serious consequences for those
who decided to entrust Qubes with anything serious. And we would like to
somehow minimize these consequences with this canary thing.
Additionally the canary is a nice way of ensuring "freshness" of our
messaging to the community.
Of course the canary doesn't solve all the problems. E.g. if my signing
keys were somehow stolen without our knowledge, it wouldn't help.
Neither it could help in case me being or becoming a miscreant. And
probably it doesn't address many other potential problems, which could
only be solved one day with a multi-signature scheme. But anyway, until
that time, this is the best we can do, I think.
And congrats to Jann for the very interesting clipboard attack (even
though mostly theoretical, still very cool)!
Thanks,
joanna.
--
The Qubes Security Team
https://www.qubes-os.org/doc/SecurityPage
[1] http://en.wikipedia.org/wiki/Warrant_canary
[2] Especially myself, because I'm currently the Root Of Trust for all
Qubes binaries :/
[3] Deterministic builds are required because it's the only way we can
implement multiple signature scheme for distributed binaries.
How to Obtain, Verify, and Read
-------------------------------
The following example demonstrates one method of obtaining the `qubes-secpack`,
verifying its contents, and reading them.
1. Clone the `qubes-secpack` repo.
$ git clone https://github.com/QubesOS/qubes-secpack.git
Cloning into 'qubes-secpack'...
remote: Counting objects: 195, done.
remote: Total 195 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (195/195), 130.94 KiB | 207.00 KiB/s, done.
Resolving deltas: 100% (47/47), done.
Checking connectivity... done.
2. Import the included PGP keys.
$ gpg --import qubes-secpack/keys/*/*
gpg: directory `/home/user/.gnupg' created
gpg: new configuration file `/home/user/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/user/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/home/user/.gnupg/secring.gpg' created
gpg: keyring `/home/user/.gnupg/pubring.gpg' created
gpg: /home/user/.gnupg/trustdb.gpg: trustdb created
gpg: key C37BB66B: public key "Joanna Rutkowska (Qubes OS signing key) <joanna@invisiblethingslab.com>" imported
gpg: key 1E30A75D: public key "Joanna Rutkowska (Qubes OS signing key) <joanna@invisiblethingslab.com>" imported
gpg: key 74EADABC: public key "Joanna Rutkowska (Qubes OS signing key) <joanna@invisiblethingslab.com>" imported
gpg: key 65EF29CA: public key "Joanna Rutkowska (Qubes OS Signing Key) <joanna@invisiblethingslab.com>" imported
gpg: key 34898310: public key "Joanna Rutkowska (Qubes OS Signing Key) <joanna@invisiblethingslab.com>" imported
gpg: key B298547C: public key "Marek Marczykowski (Qubes OS signing key) <marmarek@mimuw.edu.pl>" imported
gpg: key AB5EEF90: public key "Marek Marczykowski (Qubes OS signing key) <marmarek@invisiblethingslab.com>" imported
gpg: key A603BCB6: public key "Marek Marczykowski (Qubes OS signing key) <marmarek@invisiblethingslab.com>" imported
gpg: key 42CFA724: public key "Marek Marczykowski-Górecki (Qubes OS signing key) <marmarek@invisiblethingslab.com>" imported
gpg: key 15CE40BF: public key "Wojciech Zygmunt Porczyk (Qubes OS signing key) <woju@invisiblethingslab.com>" imported
gpg: key 36879494: public key "Qubes Master Signing Key" imported
gpg: key 211093A7: public key "Qubes OS Release 1 Signing Key" imported
gpg: key 0A40E458: public key "Qubes OS Release 2 Signing Key" imported
gpg: key 03FA5082: public key "Qubes OS Release 3 Signing Key" imported
gpg: key 92C7B3DC: public key "Joanna Rutkowska (Qubes Security Pack Signing Key) <joanna@invisiblethingslab.com>" imported
gpg: key 1830E06A: public key "Marek Marczykowski-Górecki (Qubes security pack) <marmarek@invisiblethingslab.com>" imported
gpg: key 3F48CB21: public key "Qubes OS Security Team <security@qubes-os.org>" imported
gpg: Total number processed: 17
gpg: imported: 17 (RSA: 17)
gpg: no ultimately trusted keys found
3. Verify and trust the Qubes Master Signing Key.
$ gpg --edit-key 36879494
gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
pub 4096R/36879494 created: 2010-04-01 expires: never usage: SC
trust: unknown validity: unknown
[ unknown] (1). Qubes Master Signing Key
gpg> fpr
pub 4096R/36879494 2010-04-01 Qubes Master Signing Key
Primary key fingerprint: 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
gpg> trust
pub 4096R/36879494 created: 2010-04-01 expires: never usage: SC
trust: unknown validity: unknown
[ unknown] (1). Qubes Master Signing Key
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
pub 4096R/36879494 created: 2010-04-01 expires: never usage: SC
trust: ultimate validity: unknown
[ unknown] (1). Qubes Master Signing Key
Please note that the shown key validity is not necessarily correct
unless you restart the program.
gpg> q
**Important!**
In order to verify the authenticity of the Qubes Master Signing Key prior to
trusting it, you should obtain the Qubes Master Signing Key fingerprint from
a trustworthy source (ideally, multiple sources) *other than* this website
and visually compare it (them) to the fingerprint displayed in the preceding
step, ensuring they match. You can read more about digital signatures and
key verification [here](/doc/verifying-signatures/).
4. Verify signed Git tags.
$ cd qubes-secpack/
$ git tag -v `git describe`
object 2bb7f0b966593d8ed74e140a04d60c68b96b164e
type commit
tag joanna_sec_2bb7f0b9
tagger Joanna Rutkowska <joanna@invisiblethingslab.com> 1468335706 +0000
Tag for commit 2bb7f0b966593d8ed74e140a04d60c68b96b164e
gpg: Signature made 2016-07-12T08:01:46 PDT
gpg: using RSA key 0x4E6829BC92C7B3DC
gpg: Good signature from "Joanna Rutkowska (Qubes Security Pack Signing Key) <joanna@invisiblethingslab.com>" [full]
(The final line of output confirms that the signature is good.)
5. Verify detached PGP signatures.
$ cd canaries/
$ gpg --verify canary-001-2015.txt.sig.joanna canary-001-2015.txt
gpg: Signature made Mon Jan 5 20:21:40 2015 UTC using RSA key ID 92C7B3DC
gpg: Good signature from "Joanna Rutkowska (Qubes Security Pack Signing Key) <joanna@invisiblethingslab.com>"
$ gpg --verify canary-001-2015.txt.sig.marmarek canary-001-2015.txt
gpg: Signature made Mon Jan 5 20:13:37 2015 UTC using RSA key ID 1830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack) <marmarek@invisiblethingslab.com>"
(The fourth and final lines of output confirm that the two signatures are
good.)
The same procedures can be applied to any directory or file in the
`qubes-secpack`. Two methods of verification (signed Git tags and deatched PGP
signatures) are provided to ensure that the system is robust (e.g., against a
potential failure in Git tag-based verification) and to give users more options
to verify the files.