RFC: adding qubes images to the (qubes) repo

[john.david.r.smith]

currently when i have qubes and need a new image (e.g. to
reinstall/install on a new machine), i need to download the image from
qubes-os.org and then check the signature.

this may be a source of errors for some users, or even insecure
(mitm + exchanging the master signing key information on the website +
patching the downloaded image).
also checking signatures manually should unnecessary since a package
manager is build to do such stuff.

i would propose to add the qubes-images as packages to the repos.

maybe you could get other official repos to add them, too.
(debian (+ubuntu), fedora and arch should reach a significant portion of
the linux users)

also: is the public qubes master signing key somewher in dom0?
in case a user has not saved it, this could circumvent the problem of an
mitm exchanging the information about the signing key

-john

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-12-28 04:39, john.david.r.smith wrote:
> currently when i have qubes and need a new image (e.g. to
> reinstall/install on a new machine), i need to download the image
> from qubes-os.org and then check the signature.
>
> this may be a source of errors for some users, or even insecure
> (mitm + exchanging the master signing key information on the
> website + patching the downloaded image).

I know what you mean, but it's worth remembering that the Qubes Master
Signing Key fingerprint is supposed to be verified
out-of-band/multiband. So, in principle, replacing the key and/or
fingerprint only just qubes-os.org shouldn't work as a successful
attack vector.

> also checking signatures manually should unnecessary since a
> package manager is build to do such stuff.
>
> i would propose to add the qubes-images as packages to the repos.
>

Interesting idea. I wonder whether this would count as a misuse of the
repos/package manager.

One thing is that we'd like to offload most of the traffic to a mirror
(e.g., mirrors.kernel.org, as we currently do).

> maybe you could get other official repos to add them, too. (debian
> (+ubuntu), fedora and arch should reach a significant portion of
> the linux users)
>

Another interesting idea. I've never heard of a distro adding a
different OS's ISO as a package of their own, though.

> also: is the public qubes master signing key somewher in dom0? in
> case a user has not saved it, this could circumvent the problem of
> an mitm exchanging the information about the signing key
>

I recall someone suggesting this a long time ago, and I (think I) also
recall Marek doing it, but I can't find the original thread or issue,
and I don't see the key in `/etc/pki/rpm-gpg/`. Tracking:

https://github.com/QubesOS/qubes-issues/issues/2544

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYZAb2AAoJENtN07w5UDAwVmYQAL2DSynbnJaceUIR2Mv2hvCz
7lS6oq/4HIpUtj1DJbib041EniapfId/LFzZKeh5FoE2bEkhrBRezW2A5TG6N4Dt
AKtK9Vgtj84MEP8E2eb2xMyANZ2WXtCeEYN9n4lOKzx8ETg1ZS0r054CYA3lSsWk
oLuJO59RcSjXUMaP4Myj0KkOnYpT8+N/fhzB6aps8sG1TK1AlyAsnMygCQfMmkdp
k6apddL2E1ivEhvZKXN27dKbLxR12IMMDYKBzqb1edGTh4FaJ/4ulKPfFgAOiKQj
biWK+/75LCecNHkuPeEKtt3LdWqfIqNFTjLLgoTn3QpTeIIbx8Gf/lDIWLh/G7uJ
TXFpo9J94Ra1UB44zt5/D7NqK/n6jxDPM5pbYZrbgVacZ8nRxNCAW3jSJEhqMK75
2Pmx+0MGd29M6kb9Iawk34KdmW3dGt7Mmqp44ZRtgErVkRvwuF6SLqnotH8Sp0W4
lzW2RU+ZTt5UBin1HsWGiN4bljUhGBbC3m88lywp3XIwa0q13H9+cSywXzj52JID
quCS4UXe2uLazDCMES8QJzhSAim17PlO3LXmr5X0iuh7CUB6SOyXqbF/HrDmRKMA
3Be1wU7+vK/NGnSCD4X5ArIPou02UTjxyebciCHu1uKQKVHC2UE/YHHL+Opxw8td
Ex9Yvsv9l3hNJ0bjv+O+
=3jP9
-----END PGP SIGNATURE-----

[john.david.r.smith]

>> this may be a source of errors for some users, or even insecure
>> (mitm + exchanging the master signing key information on the
>> website + patching the downloaded image).
>
> I know what you mean, but it's worth remembering that the Qubes Master
> Signing Key fingerprint is supposed to be verified
> out-of-band/multiband. So, in principle, replacing the key and/or
> fingerprint only just qubes-os.org shouldn't work as a successful
> attack vector.

the problem is (as you wrote) 'supposed to be verified out-of-band'.
for some less technical people, even verifying the signature is a huge step.
i am a fan of providing easy accessible security and using already
existing infrastructure. (in case of the dom0 repo, an ultimately
trusted source).

also depending on the situation a mitm could replace the fingerprint of
different channels, too.

>> also checking signatures manually should unnecessary since a
>> package manager is build to do such stuff.
>>
>> i would propose to add the qubes-images as packages to the repos.
>>
>
> Interesting idea. I wonder whether this would count as a misuse of the
> repos/package manager.
>
> One thing is that we'd like to offload most of the traffic to a mirror
> (e.g., mirrors.kernel.org, as we currently do).

if offloading is not done for isos: ad a "qubes-images" repo providing
the files and host it on your servers.

if offloading is done for isos: ship the master key with qubes and
provide a convenience command to the user.
this command should download (e.g. via torrent) and verify the image (a
step the user can'd do wrong anymore).
this command could spawn a dispvm, install torrent software, load the
torrent and copy it to dom0. from there the user could qvm-copy it to
the vm with the install medium.

>> maybe you could get other official repos to add them, too. (debian
>> (+ubuntu), fedora and arch should reach a significant portion of
>> the linux users)
>
> Another interesting idea. I've never heard of a distro adding a
> different OS's ISO as a package of their own, though.

asking can't hurt.

[nick...@kulinacs.com]

>the problem is (as you wrote) 'supposed to be verified out-of-band'.
>for some less technical people, even verifying the signature is a huge
>step.
>i am a fan of providing easy accessible security and using already
>existing infrastructure. (in case of the dom0 repo, an ultimately
>trusted source).

I'm weary of calling the dom0 repo an ultimately trusted source, as it implies trust in all the related infrastructure (DNS, CAs, etc.) Package managers follow a trusted objects model. Each package's signature is verified before installing, meaning trust of the repo is not required.

In either case however, a signing key must be distributed in such a fashion that it can be verified and, as such, Im not sure if this offers anything other than a wrapper around the signature verification step.

[john.david.r.smith]

>> the problem is (as you wrote) 'supposed to be verified out-of-band'.
>> for some less technical people, even verifying the signature is a huge
>> step.
>> i am a fan of providing easy accessible security and using already
>> existing infrastructure. (in case of the dom0 repo, an ultimately
>> trusted source).
> I'm weary of calling the dom0 repo an ultimately trusted source, as it implies trust in all the related infrastructure (DNS, CAs, etc.) Package managers follow a trusted objects model. Each package's signature is verified before installing, meaning trust of the repo is not required.

ok, i was a bit imprecise.
i meant: packages loaded and verified (via signatures) from the repo for
dom0 can be considered ultimately trusted.

if one of the installed packages of the dom0 repo is compromised, we
have an attacker in do0 and it is game-over.
so we can assume these packages are ultimately trusted.

> In either case however, a signing key must be distributed in such a fashion that it can be verified and, as such, Im not sure if this offers anything other than a wrapper around the signature verification step.
>

if you distribute the key with the os and it is living in dom0, it can
only be changed by someone in dom0 -> game-over
so: if the key is compromised, you cant trust anything on this machine
either it was somehow compromised during usage, or it was compromised
from the beginning (via a compromised installation image)

if the key is in dom0 and you want to verify it over a different
channel, you can load it into some vm and do this there.

the wrapper-function to download and check images is just convenience
for a non-technical user.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-12-28 11:11, john.david.r.smith wrote:
>>> this may be a source of errors for some users, or even insecure
>>> (mitm + exchanging the master signing key information on the
>>> website + patching the downloaded image).
>>
>> I know what you mean, but it's worth remembering that the Qubes
>> Master Signing Key fingerprint is supposed to be verified
>> out-of-band/multiband. So, in principle, replacing the key and/or
>> fingerprint only just qubes-os.org shouldn't work as a successful
>> attack vector.
>
>
> the problem is (as you wrote) 'supposed to be verified
> out-of-band'. for some less technical people, even verifying the
> signature is a huge step.

Yes, this is why we go to such great lengths to educate users about
this. Qubes is the sort of system that places ultimate trust in users
to safeguard their own security. There are too many ways for users to
shoot themselves in the feet that we can't prevent. Verifying the ISO
is just the first step, before Qubes is even installed. After Qubes is
installed, just think about how many ways there are for a user to
compromise dom0 or a TemplateVM if they're being reckless. (We try to
mitigate this by cutting off all network access from dom0 and allowing
network access only to the Updates Proxy for TemplateVMs, but there
are still uncountable ways to harm oneself.) Ultimately, Qubes is the
sort of OS where we have to educate users, and users have to be
willing to be educated. It's not the sort of OS where we can always
protect users from themselves.

> i am a fan of providing easy accessible security and using already
> existing infrastructure.

Agreed.

> (in case of the dom0 repo, an ultimately trusted source).
>

(I see that this was clarified in the other subthread.)

> also depending on the situation a mitm could replace the
> fingerprint of different channels, too.
>

The greater the number of alternative channels and the more different
they are (in terms of protocol, form, ownership, control, etc.), the
more difficult it would be for an attacker to replace them all. If a
user is very careful (e.g., checks from multiple computers over
different internet connections, VPNs, Tor circuits, Wi-Fi hotspots,
searches for and checks the fingerprint on webpages, PDFs, photos,
etc.), I think it would be exceedingly difficult even for a nation
state attacker to substitute every instance of the fingerprint that
the user could find on the internet (not to mention meatspace
channels). It would almost surely be easier to mount an attack in
other ways.

>>> also checking signatures manually should unnecessary since a
>>> package manager is build to do such stuff.
>>>
>>> i would propose to add the qubes-images as packages to the
>>> repos.
>>>
>>
>> Interesting idea. I wonder whether this would count as a misuse
>> of the repos/package manager.
>>
>> One thing is that we'd like to offload most of the traffic to a
>> mirror (e.g., mirrors.kernel.org, as we currently do).
>
> if offloading is not done for isos: ad a "qubes-images" repo
> providing the files and host it on your servers.
>

We *do* want to (and currently do) offload most of the ISO-download
traffic onto third-party servers, since they're better able to handle
the load. This is why we provide mirrors.kernel.org as the default
download source for Qubes ISOs.

> if offloading is done for isos: ship the master key with qubes and
> provide a convenience command to the user. this command should
> download (e.g. via torrent) and verify the image (a step the user
> can'd do wrong anymore). this command could spawn a dispvm,
> install torrent software, load the torrent and copy it to dom0.
> from there the user could qvm-copy it to the vm with the install
> medium.
>

This is a different proposal, and it would be a much larger
undertaking. It's certainly not something that the core Qubes devs
have time to do, so it would have to be a community-developed feature.
Would you like to take this project on?

>>> maybe you could get other official repos to add them, too.
>>> (debian (+ubuntu), fedora and arch should reach a significant
>>> portion of the linux users)
>>
>> Another interesting idea. I've never heard of a distro adding a
>> different OS's ISO as a package of their own, though.
>
> asking can't hurt.
>

Well... why don't you ask them, then? :)

After all, Qubes is free and open-source software. You don't need our
permission to distribute it. :)

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYZCMdAAoJENtN07w5UDAwBSMP/jhfnxe9QGFU4JzCyuoLtKHK
XfUAPibLUeSmum0lL0UpV9y3+v0gk0aKMVIXz4emthUSLjHgyTA8NmMzzqPXDl2g
YQQ0geO6aHgKNi2EM7V0ga/+o1jM96eS1DOzTEhvgcICBx14NpCG9E0zMs6NyS0n
n+nhqvp3/+sislXnTdVD71jWyfPTwIvubg3hHtle0ly5i+9iMb5nd0X7DCZy4Kga
1/OD6G4Ijpg5hRV6nJMYrrzh6vQX+E17M6dLNfddFXFJbiQZBTJYZvVnFS74uL86
8mUNzRoAK+c+nCmM09Rd+EKQktrmVn4TLm3bRas9aVNsq/iSr8v9lAVRqEM44I63
Rtq6XrAKav636VMjGB2us/Ffgk5NO1KjVBdu3xFj7okMw0pAL7JgIGnOHEZ5Golb
2nrPwsd5wVkJHxW1BZQ79wbd5Mlj76WOcWxZ2mAh8wSDqm7B16VJBaICVCY98K5L
KBnlfBq4UPGKFhFuVwQzqZCD0ksLc8Ph9s4rkDCpWzzZ0n9yt9wyTYoU/tbg724V
ap0IjLySTUzQtZ9gIWFfJxP151c1reroWwbIZ2/ePjhVkd9ye6iHet/blGomhuUO
3GOoCx1t9+KvLvBl6ejnBghHNXikGUOGZgOoIfHOBu2+PreE7F4MYeWEYEBpK60B
YDIth+4aNjRZY1naN+EC
=2Nfe
-----END PGP SIGNATURE-----

[john.david.r.smith]

>> if offloading is done for isos: ship the master key with qubes and
>> provide a convenience command to the user. this command should
>> download (e.g. via torrent) and verify the image (a step the user
>> can'd do wrong anymore). this command could spawn a dispvm,
>> install torrent software, load the torrent and copy it to dom0.
>> from there the user could qvm-copy it to the vm with the install
>> medium.
>>
>
> This is a different proposal, and it would be a much larger
> undertaking. It's certainly not something that the core Qubes devs
> have time to do, so it would have to be a community-developed feature.
> Would you like to take this project on?

my current idea:
1) create a temporary download vm A
2) use wget to get the signature + iso + release signing key

4) create a temporary verify vm B
5) copy the data from A to B
6) destroy A

7) copy the qubes-master key from dom0 to B
4) set the master key to ultimate trust
5) verify the release signing key
6) check the signature
7) copy the image to dom0
8) destroy B

you also could do all steps in one vm.

i think this should be possible with the current tools. (i would have to
look up how to do all this key management stuff via shell.

i have not this much time (and am not really skilled), but what i
thought about would not be that much work.
if this solution is acceptable, i can give it a try.
it would be in form of some bash scripts.

>>>> maybe you could get other official repos to add them, too.
>>>> (debian (+ubuntu), fedora and arch should reach a significant
>>>> portion of the linux users)
>>>
>>> Another interesting idea. I've never heard of a distro adding a
>>> different OS's ISO as a package of their own, though.
>>
>> asking can't hurt.
>>
>
> Well... why don't you ask them, then? :)

some random guy is more likely to be ignored than people officially
connected to a project (but i could try to ask them and link them to
this thread.)

[Chris Laprise]

I would support a version of this idea: A built-in downloader script
that can perform the download of an .iso and then verify it against the
key built into Qubes. A brief message could be displayed warning the
user to only download + burn isos where there is no suspicion that the
system has been breeched.

Chris