QSB #46: APT update mechanism vulnerability

503 views
Skip to first unread message

Marek Marczykowski-Górecki

unread,
Jan 23, 2019, 12:05:35 PM1/23/19
to qubes-announce, qubes-devel, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) #46:
APT update mechanism vulnerability.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).

View QSB #46 in the qubes-secpack:

<https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-046-2019.txt>

Learn about the qubes-secpack, including how to obtain, verify, and read it:

<https://www.qubes-os.org/security/pack/>

View all past QSBs:

<https://www.qubes-os.org/security/bulletins/>

```


---===[ Qubes Security Bulletin #46 ]===---

2019-01-23

APT update mechanism vulnerability


Summary
========

The Debian Security Team has announced a security vulnerability
(DSA-4371-1) in the Advanced Package Tool (APT). The vulnerability lies
in the way APT performs HTTP redirect handling when downloading
packages. Exploitation of this vulnerability could lead to privilege
escalation [1] inside an APT-based VM, such as a Debian or Whonix VM.
This bug does _not_ allow escape from any VM or enable any attacks on
other parts of the Qubes system. In particular, this bug does _not_
affect dom0, the Xen hypervisor, or any non-APT-based VMs. Nevertheless,
we have decided to release this bulletin, because if a TemplateVM is
affected, then every VM based on that template is affected.


Description
============

As described in [1]:

| Max Justicz discovered a vulnerability in APT, the high level package
| manager. The code handling HTTP redirects in the HTTP transport
| method doesn't properly sanitize fields transmitted over the wire.
| This vulnerability could be used by an attacker located as a
| man-in-the-middle between APT and a mirror to inject malicious content
| in the HTTP connection. This content could then be recognized as a
| valid package by APT and used later for code execution with root
| privileges on the target machine.


Impact
=======

Users who use Debian or Whonix VMs are affected. Users who use only
Fedora VMs are not affected. Although we do not provide any other
official or community APT-based templates, any other APT-based VMs that
users have installed on their own should also be assumed to be affected.


Discussion
===========

Normally, we do not release Qubes Security Bulletins (QSBs) to address
vulnerabilities that only affect VMs internally without affecting the
rest of the Qubes system, i.e. vulnerabilities that do not undermine the
Qubes security model.

For example, we do not release QSBs to address bugs in Firefox or Linux
kernel USB stacks, because Qubes OS was designed under the primary
assumption that in a typical desktop OS there will be countless such
bugs and that humankind will never be able to patch all of them promptly
(at least not as quickly as developers introduce new bugs). This is, in
fact, the very reason we designed Qubes OS as an implementation of the
security-by-compartmentalization approach.

The APT update bug discussed today is, however, somewhat special.
While it is indeed a bug that only affects VMs internally, it could
allow an attacker to compromise TemplateVMs, which are used as a basis
for creating other VMs, such as AppVMs and ServiceVMs. If a TemplateVM
is compromised, then all the VMs based on that TemplateVM will be
compromised. Since AppVMs operate directly on user data, and since
ServiceVMs can be critical to user privacy (especially in the case of
Whonix and VPN ProxyVMs), this is a serious matter.

In Qubes OS, we take special precautions to make TemplateVMs difficult
to compromise. For example, we block all network connections to and from
templates, with one exception: We allow templates to connect to the
so-called "Update Proxy" (which runs in the NetVM). This allows the
TemplateVM to retrieve updates while protecting users from accidentally
using TemplateVMs to perform risky activities, such as browsing the web.

Since the bug under discussion has the potential to subvert this very
protection mechanism, we've decided to issue this QSB.

We would like to point out, however, that Qubes OS does a good job of
mitigating this kind of a vulnerability. Instead of having to reinstall
the whole operating system from scratch, Qubes users may need only to
reinstall the affected template(s).

If users are concerned that potential attackers may have compromised not
only the root filesystem of the template, but also attempted to infect
user files in AppVM filesystems (e.g. ~/.bashrc or a Web browser profile
directory), Qubes allows for mounting each of the suspected AppVM
private images into a different, trusted VM, based on a trusted
template, for "offline" analysis and cleanup, allowing users to preserve
their data.


Patching
=========

If you are a Qubes user, you should remove all APT-based (including
Debian and Whonix) TemplateVMs and StandaloneVMs, then install fresh
ones. You can do this by performing the following steps on each such
TemplateVM:

1. Note any customizations you have made to the target TemplateVM.

2. Temporarily change all VMs based on the target TemplateVM to a
different template, or remove them.

Temporarily switching to a different template can be a good idea if
you have user data in these VMs that you want to keep. On the other
hand, if you suspect that these VMs are compromised, you may want to
remove them instead. You can remove them in Qube(s) Manager by
right-clicking on the VM and clicking "Remove VM" or "Delete qube,"
or you can use this command in dom0:

$ qvm-remove <vm-name>

3. Uninstall the target TemplateVM from dom0:

$ sudo dnf remove <template-package-name>

This requires specifying the template package name (not the
TemplateVM's name). A list of affected template package names is
provided below. For example, to uninstall the whonix-gw-14 template:

$ sudo dnf remove qubes-template-whonix-gw-14

4. Reinstall the target TemplateVM in dom0:

$ sudo qubes-dom0-update --enablerepo=<optional-additional-repo> \
<template-package-name>

This requires specifying the template package name (not the
TemplateVM's name). A list of new (fixed) template package names is
provided below. For example, to install the whonix-gw-14
template:

$ sudo qubes-dom0-update --enablerepo=qubes-templates-community \
qubes-template-whonix-gw-14

Then verify the right version was installed:

$ rpm -q qubes-template-whonix-gw-14
qubes-template-whonix-gw-14-4.0.1-201901231238.noarch

In accordance with our standard policy, new (fixed) template packages
will first reside in the testing repositories for approximately two
weeks before migrating to the stable repositories. In order to
install a templates package from its testing repository, you must
enable that repository. For example, to install the whonix-gw-14
template from its testing repository:

$ sudo qubes-dom0-update \
--enablerepo=qubes-templates-community-testing \
qubes-template-whonix-gw-14

5. If you temporarily changed all VMs based on the target TemplateVM to
a different template in step 2, change them back to the fresh
TemplateVM now. If you instead removed all VMs based on the old
TemplateVM, you can recreate your desired VMs from the fresh
TemplateVM now.

6. If you noted any template customizations in step 1, clone the target
TemplateVM, then reapply your customizations to the clone.

Old (vulnerable) and new (fixed) Qubes TemplateVM packages are listed
for each supported Qubes OS version in the tables below:

Qubes 4.0:
+------------------------------------------------------------------------------+
| Old (Vulnerable) | New (Fixed) |
| --------------------------- | ---------------------------------------------- |
| qubes-template-debian-8 | qubes-template-debian-8-4.0.1-201901231241 |
| qubes-template-debian-9 | qubes-template-debian-9-4.0.1-201901230644 |
| qubes-template-whonix-gw-14 | qubes-template-whonix-gw-14-4.0.1-201901231238 |
| qubes-template-whonix-ws-14 | qubes-template-whonix-ws-14-4.0.1-201901231238 |
+------------------------------------------------------------------------------+

Qubes 3.2:
+--------------------------------------------------------------------------+
| Old (Vulnerable) | New (Fixed) |
| --------------------------- | ------------------------------------------ |
| qubes-template-debian-8 | qubes-template-debian-8-4.0.1-201901230645 |
| qubes-template-debian-9 | qubes-template-debian-9-4.0.1-201901230645 |
| qubes-template-whonix-gw-14 | not supported |
| qubes-template-whonix-ws-14 | not supported |
+--------------------------------------------------------------------------+


Alternative patching for non-critical TemplateVMs
==================================================

Users who do not rely on APT-based VMs for any critical tasks may
instead opt just to install fixed APT packages. This is _not_ secure if
the template has already been compromised. If you are not willing to
take the risk that the template may already be compromised, you should
instead follow the instructions in the previous section to completely
remove the template, then install a fresh one.

As the bug is present in the update mechanism itself, special care
should be taken while performing the update, as described in [1]. We
include those steps in GUI tools used to update, so updating the GUI
tools and performing the template update with either of them will also
apply the fix in a safe way, as long as the TemplateVM is not already
compromised.

Important: Listed below are the minimum package versions that will
perform APT updates safely. However, after installing these packages,
you must also update all APT-based TemplateVMs normally through the
Qubes VM Manager. Installing the packages listed below is not enough.

Qubes 4.0:
- qubes-desktop-linux-manager 4.0.14 (updates widget)
- qubes-manager 4.0.27 (Qube Manager)

Qubes 3.2:
- qubes-manager 3.2.14 (Qubes VM Manager)

The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:

For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update

For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing

Now you can safely update your APT-based TemplateVMs through the Qubes
VM Manger.


Credits
========

This vulnerability was discovered by Max Justicz and reported to the
Debian Security Team.


References
===========

[1] https://www.debian.org/security/2019/dsa-4371


- --
The Qubes Security Team
https://www.qubes-os.org/security/
```

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxIntgACgkQ24/THMrX
1yyCMggAiZ39l/FNTMvpZ3mcuYvIt3+OtnJa39IJ1A1O8F7cFQXmENLBbEfO2/r7
y0oIras3jD3FEgqqEHDaUx/OuF9XHsii8XMbvAiWKIVAchK3/Oze2UjPjDF63mtJ
p7ngVs6CciYNmW4Y2QPTs+vUPzSY+SllWl+qf/kWKvKzYsPyC8SCuNYB1dG3SZXg
I3NZcxdVdMao4FN/dJkLitEQeFhMiQTHA6SaD6ozxb5hv4FbIAeaoVFf/gR22EZb
hy3W6wfmYN2eW2Ydq+jq9/YHXzuZhVEGvPcWxblEr2rcat1gz1Gp76h9U8oJppUs
TEa7gg6fGzITNuhJAQCJZddxWDQb4A==
=XKVs
-----END PGP SIGNATURE-----

Brendan Hoar

unread,
Jan 23, 2019, 12:32:38 PM1/23/19
to qubes-users
Thank you, Marek et al, for your work over what was presumably a longer than usual work day.

B

seshu

unread,
Jan 23, 2019, 12:49:10 PM1/23/19
to qubes-users
On Wednesday, January 23, 2019 at 5:32:38 PM UTC, Brendan Hoar wrote:
> Thank you, Marek et al, for your work over what was presumably a longer than usual work day.
>
>
> B

Agreed, thanks everyone! One question Marek, the ubuntu distros you recently made available to the community could be affected also? They are APT based distro's right?

If so, I'm assuming I'll have to apply the same procedure for those right?

gone

unread,
Jan 23, 2019, 3:06:20 PM1/23/19
to qubes...@googlegroups.com
seshu wrote on Wed, 23 January 2019 17:49
> On Wednesday, January 23, 2019 at 5:32:38 PM UTC,
> Brendan Hoar wrote:
> > Thank you, Marek et al, for your work over what was
> > presumably a longer than usual work day.
> >
> >
> > B
>
> Agreed, thanks everyone!
>
> --

I'd also like to thank you for doing all that.

I've tried it for the debian-9 template with sudo
qubes-dom0-update
--enablerepo=qubes-templates-community-testing
qubes-template-debian-9 but this only brings up the
4.0.1.-201812091508 version.
Is that repo only right for the whonix tempate as in the
example or is there another reason? What have I done wrong?

seshu

unread,
Jan 23, 2019, 3:14:53 PM1/23/19
to qubes-users

I followed the same steps you did and I did get the right version. I did notice that after deleting the old templateVMs I needed to reboot my system. Not necessarily to get or see the new versions but, I was getting a signature error when I downloaded the new version and dnf wouldn't install them because it did not match the signature of the 201812091508 version.

But, after rebooting the system, that seemed to clean the cache or something and then the qubes-dom0-update process worked.

gone

unread,
Jan 23, 2019, 3:32:07 PM1/23/19
to qubes...@googlegroups.com
@seshu: OK, thanks, so I'll try and reboot.

gone

unread,
Jan 23, 2019, 4:08:24 PM1/23/19
to qubes...@googlegroups.com
unfortunately the reboot brought no change. Still the
201812091508 version.

Chris Laprise

unread,
Jan 23, 2019, 4:52:31 PM1/23/19
to qubes...@googlegroups.com
On 01/23/2019 12:05 PM, Marek Marczykowski-Górecki wrote:

> Patching
> =========
>
> If you are a Qubes user, you should remove all APT-based (including
> Debian and Whonix) TemplateVMs and StandaloneVMs, then install fresh
> ones. You can do this by performing the following steps on each such
> TemplateVM:


A shortened update procedure for debian-9:

1. If your "debian-9" template is customized or contains data, you may
wish to back it up with qvm-clone first...

[dom0]$ qvm-clone debian-9 d9-backup

2. Run the upgrade command...

[dom0]$ sudo qubes-dom0-update qubes-template-debian-9 \
--enablerepo=qubes*testing --action=upgrade

This will display package info as it begins downloading. The package
version-date should begin with "4.0.1-20190123" or later.

3. Shutdown all VMs so the upgrade can take effect...

[dom0]$ qvm-shutdown --all --wait --timeout=30

This method also works with whonix-gw-14 and whonix-ws-14 templates.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

gold...@riseup.net

unread,
Jan 23, 2019, 5:16:40 PM1/23/19
to gone, qubes...@googlegroups.com
On 2019-01-23 21:08, gone wrote:
> unfortunately the reboot brought no change. Still the
> 201812091508 version.

Try sudo
qubes-dom0-update
--enablerepo=qubes-templates-itl-testing
qubes-template-debian-9

John S.Recdep

unread,
Jan 23, 2019, 5:32:05 PM1/23/19
to qubes...@googlegroups.com
On 1/23/19 9:08 PM, gone wrote:
> unfortunately the reboot brought no change. Still the
> 201812091508 version.
>


this is for Fedora, is there something akin to this for Debian ?


------
What you can do to get the differences between two templates:

1) run "dnf list installed > packagelist1.txt
Do the same in the other VM

2) compare both lists:
grep -Fxv -f packagelist1.txt packagelist2.txt



The problem with that is that it outputs version numbers, which isnt
particularly helpful.
dnf repoquery --qf "%{name}" --userinstalled
Will give you just the names.
------

gone

unread,
Jan 23, 2019, 7:56:57 PM1/23/19
to qubes...@googlegroups.com
has worked fine with debian-9. Thank you Chris.

js...@bitmessage.ch

unread,
Jan 23, 2019, 8:10:50 PM1/23/19
to qubes...@googlegroups.com
Marek Marczykowski-Górecki:
> Summary
> ========
>
> The Debian Security Team has announced a security vulnerability
> (DSA-4371-1) in the Advanced Package Tool (APT). The vulnerability lies
> in the way APT performs HTTP redirect handling when downloading
> packages. Exploitation of this vulnerability could lead to privilege
> escalation [1] inside an APT-based VM, such as a Debian or Whonix VM.
> This bug does _not_ allow escape from any VM or enable any attacks on
> other parts of the Qubes system. In particular, this bug does _not_
> affect dom0, the Xen hypervisor, or any non-APT-based VMs. Nevertheless,
> we have decided to release this bulletin, because if a TemplateVM is
> affected, then every VM based on that template is affected.

Hi,

Does this vulnerability apply to whonix users who download updates over
tor from .onion repos?

My understanding is that it shouldn't, since the exit node operator or
any other MITM doesn't even know it's apt traffic, they just see
encrypted traffic to a hidden service.

Is this right, or am i not understanding something?

--
Jackie

Marek Marczykowski-Górecki

unread,
Jan 23, 2019, 8:22:58 PM1/23/19
to js...@bitmessage.ch, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

In case of onion indeed MitM attack is not that easy, but if someone
takes over Debian (or Whonix) mirrors still could perform the attack.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxJE2sACgkQ24/THMrX
1yxbaAf+LBDndywJFQnv8ecVh3MADbYF3I1fpBJuPFP58MW3Iti2zB1US0jcxFbk
9GevFxLRd0f0u6sblyX+lko8f469gGhl/N0eK5Tl77omJNQc2on5uZb9pPotuuAi
0S8f49SJhl7B1WaJLKV9MAL2sXraHfZ59juQaLmQiSearuJcanPJAqEM/D0OI/aT
BWTc/fsjDpfQ9hV/BQcEOjoOqKuwnZDBLSrXR/ychWFA0zRPzmFtJjA6shFprPf1
NGxhdabDWSEzcKGyUW+GM/eoBo3qwH7cvQk9tHBFJfSpDDUAmgkodCO3PfVYw44L
5wAONEFFZZJH8xs7V/NSo9nqZVjuKQ==
=zzzU
-----END PGP SIGNATURE-----

pixel fairy

unread,
Jan 23, 2019, 9:53:47 PM1/23/19
to qubes-users
is whonix in the repo? i keep getting "Error: Unable to find a match"
tried copy/pasting from the command to delete the templates to make sure they're spelled right. tried qubes-templates-itl and qubes-templates-itl-testing.

Andrew David Wong

unread,
Jan 23, 2019, 10:24:57 PM1/23/19
to pixel fairy, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
The Whonix packages are in qubes-templates-community-testing.

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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxJL/sACgkQ203TvDlQ
MDBw/w//YOWTVN8shPoHSzkKUmz6tnG3PZ4xr0gq4Nc3eJeC1Oz9GJT92TJwQZiU
O0BGHg5vI6lXes5KYJWPl0aKVCmbdI23HoSGh/9C0PryGapAJ8+b+Y0M4DE3tA1k
znQKRZezs5XudXfX0Zy2jR1wXGON59D8XIOK1SDQQLQjha8jFPBwCNcjDPvmibX+
9lx+Gt8+SOkOI13Bg3WBruZ10mSAJhC7nVKLMkEy9xE2UlSJeCxfdKqyCTdnCG7R
VSaDRsX4b46XjiSVnVgCoKG/00wPeU2Ix+p9CmsYIbtNmKB4jybHIvX/6Qa365Fl
ieBHy0lEMIhs9cDeFRYM4Lo+tdCslwMEkk1Acx90kP/PQI4moo5qRR3yMxwYmXNX
llua+ijV6ONE9nDhj/Lvi62GzSMhZwq18pwTUqDUXKm8Z8hUAwmaZL3Ay4o2/qE5
3LFgaBIgY8HHdV96xxZZxOpcp1itNgU17xpkz9gphIpCLIkccjrjulQilRdSHKa1
1KH1DnVxKtC/TM4RFOFywuFX7GpZklPEBPXRAtHhzmfkENX//+3h1rKXA9k3iCam
axTGjQGOnmA2tXkGYEUi6VOJ/6WD6K6YPcovlEm7ao2d3HZU+SQKKiJ53B41dJJO
stk9jV51h0r19XIA/1dcYbKaMgZDdWF7Z0TW/AhyuqVUCMsuvG0=
=iiJY
-----END PGP SIGNATURE-----

pixel fairy

unread,
Jan 23, 2019, 10:36:04 PM1/23/19
to qubes-users
On Wednesday, January 23, 2019 at 7:24:57 PM UTC-8, Andrew David Wong wrote:

> The Whonix packages are in qubes-templates-community-testing.

$ sudo qubes-dom0-update --enablerepo=qubes-templates-community-testing qubes-template-whonix-gw-14

Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
Last metadata expiration check: 1:08:18 ago on Wed Jan 23 18:22:56 2019.
No match for argument: qubes-template-whonix-gw-14

Andrew David Wong

unread,
Jan 23, 2019, 10:40:02 PM1/23/19
to pixel fairy, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

That's strange. I was just able to install them with the same command.
Maybe try it again with --clean?

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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxJM4UACgkQ203TvDlQ
MDA6xg//f6Z108hVsOt0NShRKr0ymesvupANPfoVSE4LmuNr3rh3sHiRCNrUQUFw
jbX2K05aig82smbqwya/+qxTs5IY50zLzPYaBHMVLthFNI2YRXir0VFPGf2z5YA0
59/dEjxXWkmB+itSZ94dFLEwiwwPJwl1nzYSPb5xCfhT6gTus0Ur0Ig1HL71jgTz
HWmXKkUHMrXl92ET87yCEBB9yT4NKyhii8qQKauyrCKsDL2Z1Xr1jbO6ezY34Mjw
EKYiau97vvpdEEPH9xHkXkFSZI22PJ5TNcsbFOYWwevQdlWonSX9u9EQqV+DVueP
0jGiA+68cV9ih99mhciOt6cKajPmD7sMak0TqgBGET0s21Jal0vBLbJhK4kYIpYf
DJ8TOHKsSogEI0stxyqyGZgJ1Nlj1urffXdYsuJL53WtlNy9X06Qxa5aGYM/Kk1+
HWAVMkG5pjAxtlJ73+MVO4/7pRWsYOwma67bmcpQ+D6mcj/IPn4FFVue6bOq4t5t
iWOlPvzMH8xm8yPlmEdtOkdE1BbsxcORlXQig/5b+T3W0ZCSDXPLkO+Cgn6Yb6P9
URxspGf+lU/7R5lUDWjV2X/b3dAVNzUHyQ0tlNqAdqmfg6abi21YgnAl2nFPkHtF
9wYajSzhRK7ytFGcGT7UKY8yjZEbG58nMOO+XHJxc2ixYbpP+Jo=
=oMb9
-----END PGP SIGNATURE-----

Chris Laprise

unread,
Jan 24, 2019, 12:54:33 AM1/24/19
to Andrew David Wong, pixel fairy, qubes-users
On 01/23/2019 10:39 PM, Andrew David Wong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 23/01/2019 9.36 PM, pixel fairy wrote:
>> On Wednesday, January 23, 2019 at 7:24:57 PM UTC-8, Andrew David Wong wrote:
>>
>>> The Whonix packages are in qubes-templates-community-testing.
>>
>>
>> $ sudo qubes-dom0-update --enablerepo=qubes-templates-community-testing qubes-template-whonix-gw-14
>> Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
>> Last metadata expiration check: 1:08:18 ago on Wed Jan 23 18:22:56 2019.
>> No match for argument: qubes-template-whonix-gw-14
>> Error: Unable to find a match
>>
>
> That's strange. I was just able to install them with the same command.
> Maybe try it again with --clean?

That's why I found its better to just specify qubes*testing for the
templates:

https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net

Also, using the 'upgrade' action is a lot less confusing. The official
steps are needlessly painful.

Lorenzo Lamas

unread,
Jan 24, 2019, 10:13:36 AM1/24/19
to qubes-users
Please help, after updating dom0 with security-testing(which installed not only qubes-desktop-linux-manager and qubes-manager, but also qubes-mgmt-salt-dom0-update-4.0.5-1 and reboot, no VM at all will start.
Failed to connect to qmmemman:[Errno 2] No such file or directory.
Text boot shows:
Failed to start Qubes memory management daemon.

systemctl status qubes-qmemman.service shows:
"qubes-qmemman.service - Qubes memory management daemon
Loaded: loaded (/usr/lib/systemd/system/qubes-qmemman.service; enabled; vendor preset: enabled)
Active: failed (Result: exit code) since Thu 2019-01-24 15:41:40 CET; 1min 1s ago
Proces: 2094 ExecStart=/usr/bin/qmemmand (code=exited, status=1/FAILURE]
Main PID: 2094 (code-exited, status=1/FAILURE)

Jan 24 15:41:40 dom0 qmemmand[2094]: sys.exit(main())
Jan 24 15:41:40 dom0 qmemmand[2094]: File "/usr/lib/python3.5/site-packages/qubes/tools/qmemmand.py", line 261, in main
Jan 24 15:41:40 dom0 qmemmand[2094]:qubes.utils.parse_size(config.get('global', vm-min-mem'))
Jan 24 15:41:40 dom0 qmemmand[2094]: File "/usr/lib/python3.5/site-packages/qubes/utils.py", line 107, in parse_size
Jan 24 15:41:40 dom0 qmemmand[2094]: raise qubes.exc.QubesException("Invalid size: {0}.".format(size))
Jan 24 15:41:40 dom0 qmemmand[2094]: qubes.exc.QubesException: Invalid size 190MIB.
Jan 24 15:41:40 dom0 systemd[1]: qubes-qmemman.service: Main proces exited, code-exited, status=1/FAILURE
Jan 24 15:41:40 dom0 systemd[1]: Failed to start Qubes memory management daemon.
Jan 24 15:41:40 dom0 systemd[1]: qubes-qmemman.service: Unit entered failed state.
Jan 24 15:41:40 dom0 systemd[1]: qubes-qmemman.service: Failed with result 'exit-code'.

I tried to undo the update with dnf history undo but it says the package is not available.

Lorenzo Lamas

unread,
Jan 24, 2019, 2:16:06 PM1/24/19
to qubes-users

Well, thanks to the help of someone more knowledgeable than me, I was able to fix it.
The trick was to edit /etc/qubes/qmemman.conf.
In the line vm-min-mem = 190MIB replace with 190M
In the line dom0-mem-boost = 333MIB replace with 333M.
Maybe a typo in one of the patches?

Fidel Ramos

unread,
Jan 24, 2019, 5:43:42 PM1/24/19
to qubes-users
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, January 23, 2019 9:52 PM, Chris Laprise <tas...@posteo.net> wrote:

> On 01/23/2019 12:05 PM, Marek Marczykowski-Górecki wrote:
>
> > Patching
> >
> > =========
> >
> > If you are a Qubes user, you should remove all APT-based (including
> > Debian and Whonix) TemplateVMs and StandaloneVMs, then install fresh
> > ones. You can do this by performing the following steps on each such
> > TemplateVM:
>
> A shortened update procedure for debian-9:
>
> 1. If your "debian-9" template is customized or contains data, you may
> wish to back it up with qvm-clone first...
>
> [dom0]$ qvm-clone debian-9 d9-backup
>
> 2. Run the upgrade command...
>
> [dom0]$ sudo qubes-dom0-update qubes-template-debian-9 \
> --enablerepo=qubes*testing --action=upgrade
>
> This will display package info as it begins downloading. The package
> version-date should begin with "4.0.1-20190123" or later.
>
> 3. Shutdown all VMs so the upgrade can take effect...
>
> [dom0]$ qvm-shutdown --all --wait --timeout=30
>
> This method also works with whonix-gw-14 and whonix-ws-14 templates.

Also in case people don't know there is an easy procedure to store the list of installed packages from the old debian 9 template and reinstall the same packages in the fresh template:

https://unix.stackexchange.com/questions/176134/installing-packages-by-importing-the-list-with-dpkg-set-selections/177187#177187

I reproduce the steps here for convenience:

debian-9-old$ dpkg --get-selections > /tmp/dpkg_selections.txt
debian-9-old$ qvm-copy-to-vm debian-9 /tmp/dpkg_selections.txt

debian-9$ avail=`mktemp`
debian-9$ apt-cache dumpavail > "$avail"
debian-9$ dpkg --merge-avail "$avail"
debian-9$ rm -f "$avail"
debian-9$ sudo dpkg --set-selections < ~/QubesIncoming/debian-9-old/dpkg-selections.txt
debian-9$ sudo apt-get dselect-upgrade

That should do the trick. Of course check dpkg-selections.txt, it's a simple text file.

Note that with this procedure the information of which packages have been installed manually and which automatically as a dependency is not kept. If you want to transfer this information use this procedure:

debian-9-old$ apt-mark showmanual > pkgs_manual.lst
debian-9-old$ apt-mark showauto > pkgs_auto.lst
debian-9-old$ qvm-copy-to-vm debian-9 pkgs_auto.lst pkgs_manual.lst

debian-9$ sudo apt-mark manual $(cat QubesIncoming/debian-9-old/pkgs_manual.lst)
debian-9$ sudo apt-mark auto $(cat QubesIncoming/debian-9-old/pkgs_auto.lst)

https://askubuntu.com/questions/101931/restoring-all-data-and-dependencies-from-dpkg-set-selections/108760#108760

Hope that's useful.

Fidel Ramos
PGP 7F07 1B7C 479F EDD1
https://www.fidelramos.net

Andrew David Wong

unread,
Jan 24, 2019, 9:57:40 PM1/24/19
to Chris Laprise, pixel fairy, qubes-users, Marek Marczykowski-Górecki
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 23/01/2019 11.54 PM, Chris Laprise wrote:
> On 01/23/2019 10:39 PM, Andrew David Wong wrote:
>> On 23/01/2019 9.36 PM, pixel fairy wrote:
>>> On Wednesday, January 23, 2019 at 7:24:57 PM UTC-8, Andrew David Wong
>>> wrote:
>>>
>>>> The Whonix packages are in qubes-templates-community-testing.
>>>
>>>
>>> $ sudo qubes-dom0-update
>>> --enablerepo=qubes-templates-community-testing
>>> qubes-template-whonix-gw-14
>>> Using sys-firewall as UpdateVM to download updates for Dom0; this may
>>> take some time...
>>> Last metadata expiration check: 1:08:18 ago on Wed Jan 23 18:22:56 2019.
>>> No match for argument: qubes-template-whonix-gw-14
>>> Error: Unable to find a match
>>>
>>
>> That's strange. I was just able to install them with the same command.
>> Maybe try it again with --clean?
>
> That's why I found its better to just specify qubes*testing for the
> templates:
>
> https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net
>

I don't understand. How would that help here? To recap, this command
worked for me:

$ sudo qubes-dom0-update --enablerepo=qubes-templates-community-testing qubes-template-whonix-gw-14

The very same command failed for pixel fairy. Why would using
qubes*testing instead fix whatever is causing that command to fail?
Would that somehow force cache busting for some reason?

>
> Also, using the 'upgrade' action is a lot less confusing. The official
> steps are needlessly painful.
>

Would it be worth updating the QSB? (CC: Marek)

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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxKev0ACgkQ203TvDlQ
MDBgmw/+IgsI5x0xAjdetKXzcdsOJUyeMd4ksZc0EWItQhQRN/ZD56KEODRQNryc
f1NkApyRi9WdH6PC+G2X5UiVXWNwx3Zu52J718qsWB1WkRnvQKlUvPI24uBXZH5x
f1f8L2OulK0dDikxSYTPSnRkPNQ+kmOyr0W50lJLbPufHH+tRhIKWCHIVdU45QXD
qpLnARlkNusH3uJA8lRmMZjhyg/ipsz6bM+z31n7Odf9M6sp+cD7mIgRCUqv4K20
3KbA+QWfREV67sgvgZ4NYFkGof/qJa4SF+rMbc0LOYbn9gzvnzNabLsQFHZhuCVk
DXyFGqXauLsF9ksmmyd2sskaiv3Y+mIiBXgL/F3Ks0AR8KsQZ+vJyIKnCG3o9doJ
brUucluIaPtDfD0fmSlRyHfM3XQOEuHHIOrkwY6QxfyBOpuMSPB2lAY1yfg9Er9z
NWbi8bcDknjiS9U1ZMih3Ox0bLthef/B3V1M6A4x3lINp5J/1aJ6VB7BwmkU6tON
2oBl0IY+KkrcA5eX3OkDt5ZRuo8syFDdB9CvHft1WKweL8FkQmhfOR2HDB52IRGr
YGSsd9m9V999dKs7zkPcExhdU3BNhK11aEp84ZX3S11NeXf2iqSZw6ORN3qi5Nf2
Y++BFwE3vjLnssWCTCj8YcI69C8jUoLaPmZkdEVIUqTvGQL9YEY=
=BVTN
-----END PGP SIGNATURE-----

Andrew David Wong

unread,
Jan 24, 2019, 10:13:04 PM1/24/19
to Chris Laprise, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 23/01/2019 3.52 PM, Chris Laprise wrote:
> On 01/23/2019 12:05 PM, Marek Marczykowski-Górecki wrote:
>
>> Patching
>> =========
>>
>> If you are a Qubes user, you should remove all APT-based (including
>> Debian and Whonix) TemplateVMs and StandaloneVMs, then install fresh
>> ones. You can do this by performing the following steps on each such
>> TemplateVM:
>
>
> A shortened update procedure for debian-9:
>
> 1. If your "debian-9" template is customized or contains data, you may
> wish to back it up with qvm-clone first...
>
> [dom0]$ qvm-clone debian-9 d9-backup
>
> 2. Run the upgrade command...
>
> [dom0]$ sudo qubes-dom0-update qubes-template-debian-9 \
> --enablerepo=qubes*testing --action=upgrade
>
> This will display package info as it begins downloading. The package
> version-date should begin with "4.0.1-20190123" or later.
>

Will this step work with templates where installed_by_rpm = false?

> 3. Shutdown all VMs so the upgrade can take effect...
>
> [dom0]$ qvm-shutdown --all --wait --timeout=30
>
> This method also works with whonix-gw-14 and whonix-ws-14 templates.
>

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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxKfqsACgkQ203TvDlQ
MDDe8xAAoEDmpIWBbhdeRUtQQsIbsKS/RexE8tRZoWgl68IIHMCL/SBsPU4aw4sl
lmp+AUXkiko3mMutWBP+AujscnF2V+rTuGAKRSBwf90qd0sHkL4MUq2jVhwELnOq
xT8N8vQOGBQckeTN9iqGw+6Yg4lrPSmB2evi/Ma7B7f5x9rfkk22tZNEB3oGDSyk
z6NCjxRWvNKHYi/h3UzGvfrFHJdMrC1s6gcd9+h+Tw9WOU5/ZkLqIGB1mDV9FKQF
EzwgU2zy1QiUaNEihjDghohqJOoxDPvqA3muil2qpReKLhqGkBrtpJGN8mjnjIdW
lmtUWipBOCFEgnrPfvPD9wbmwp64mc86qFDlTIskKHvZYjEMJV5ILw7w3s5hZTnk
KlAz6iAyW09E5JE1hQplZdpKAx+Z+Oc5mAdJzHI8j1ytKiHfk40nupyM07QCm/GR
iiXlZTYMRgsy5+s8SkBVhLFL9CLWWje7eH63TLQ5hwHm+rJTshjI3BycV5m+3fdv
StIvgg5u6LVXITkfSUxwOlOR1somjwddWB+zSVME6vAQJ7+LfBRqB/eD0mcSrmtQ
nhDHgyOfulu3IHjm3TbSLl5d8bqk2/GTTBsvsIfoKeo9eSdGO/+nuQb4G5AhqOJ2
bD0NWIQaMqNdhi7V3hzIYiYkh2fQVV0fSzHjmeUbqUShxt0IOfg=
=UuFd
-----END PGP SIGNATURE-----


Marek Marczykowski-Górecki

unread,
Jan 24, 2019, 10:15:08 PM1/24/19
to Andrew David Wong, Chris Laprise, pixel fairy, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Jan 24, 2019 at 08:57:16PM -0600, Andrew David Wong wrote:
> On 23/01/2019 11.54 PM, Chris Laprise wrote:
> > On 01/23/2019 10:39 PM, Andrew David Wong wrote:
> >> On 23/01/2019 9.36 PM, pixel fairy wrote:
> >>> On Wednesday, January 23, 2019 at 7:24:57 PM UTC-8, Andrew David Wong
> >>> wrote:
> >>>
> >>>> The Whonix packages are in qubes-templates-community-testing.
> >>>
> >>>
> >>> $ sudo qubes-dom0-update
> >>> --enablerepo=qubes-templates-community-testing
> >>> qubes-template-whonix-gw-14
> >>> Using sys-firewall as UpdateVM to download updates for Dom0; this may
> >>> take some time...
> >>> Last metadata expiration check: 1:08:18 ago on Wed Jan 23 18:22:56 2019.
> >>> No match for argument: qubes-template-whonix-gw-14
> >>> Error: Unable to find a match
> >>>
> >>
> >> That's strange. I was just able to install them with the same command.
> >> Maybe try it again with --clean?
> >
> > That's why I found its better to just specify qubes*testing for the
> > templates:
> >
> > https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net
> >
>
> I don't understand. How would that help here? To recap, this command
> worked for me:
>
> $ sudo qubes-dom0-update --enablerepo=qubes-templates-community-testing qubes-template-whonix-gw-14
>
> The very same command failed for pixel fairy.

I think the issue is about the previous point in the patching
instruction: remove buggy template version. Otherwise it will fail
exactly like this (indeed the message is confusing...). Feature request
about simplifying this process is tracked here:
https://github.com/QubesOS/qubes-issues/issues/4518

> Why would using
> qubes*testing instead fix whatever is causing that command to fail?
> Would that somehow force cache busting for some reason?

No. But it would be easier - no need to think in which repository given
template is. In this particular case, it should be fine as given
template is only in one of those repositories.

> > Also, using the 'upgrade' action is a lot less confusing. The official
> > steps are needlessly painful.
>
> Would it be worth updating the QSB? (CC: Marek)

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxKfzYACgkQ24/THMrX
1yy/RQf/aHFY61ViLRp9IRosZegJ/CybS5uioPxQf/GEy/d5JbkXMYEKWyTgyA7c
HsPB1z/HVfA+I7CRidrtKufr9jgeuE5KGrposFNxG/yCvzDh7nQaVF6svw3gozJw
pO4ULJ02zRg8YaJF+aBv25/p6jI7CQYs93OFZ0x0pVli4+BlkUY8gzhTgrf0V/bU
cpaC9UmzKfWR8TxR6gFTTmVqs5K+WxcBo3LfXF1yNoBlHCgJdhfK5kqmvANE5apS
gw5pM0ccsNYV//cmVr8fULAa05gRPRIQgepPUoj/442fGesfHDMVCm48pta/uhZ2
OPh0sBdqAgmlbRjrAGFi3a0b36ewww==
=7+Ci
-----END PGP SIGNATURE-----

Andrew David Wong

unread,
Jan 24, 2019, 10:35:59 PM1/24/19
to Marek Marczykowski-Górecki, pixel fairy, Chris Laprise, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Oh, the old template is still installed? Ok, that makes sense.

pixel fairy, please let us know of fully removing the old template first
doesn't fix the problem.

>> Why would using
>> qubes*testing instead fix whatever is causing that command to fail?
>> Would that somehow force cache busting for some reason?
>
> No. But it would be easier - no need to think in which repository given
> template is. In this particular case, it should be fine as given
> template is only in one of those repositories.
>

Sure, I can see it being easier. I'd specify it as
`qubes-templates*testing` to be safe, though. Otherwise, user error
could easily lead to pulling updates from `qubes-dom0-current-testing`
that they didn't mean to get and aren't prepared to deal with.

>>> Also, using the 'upgrade' action is a lot less confusing. The official
>>> steps are needlessly painful.
>
>> Would it be worth updating the QSB? (CC: Marek)
>

PR: https://github.com/QubesOS/qubes-secpack/pull/26

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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxKhAcACgkQ203TvDlQ
MDBmVQ//dSU4Jyi/Cg2m7+YkdGyjJB3W8TmS1HFDrGEFlVKsTl5WL8TSxjNPb0tS
yHMRlOzDDA5POiTBPmLAPk6zwUDkiDSMt+DQ1GZ5b7NIxcnKNZjHM5EMOCzcCoW2
7DB/wYpp5AndG+3pHM8TWcCTOC7cSAqMxj5pgqUMnOOunG5Ic8nVnUEU1YdBSM51
uPJuXeR7/sZ33eWUKN5QrRP/Yb4TLORYjouWR6tI60j8ReE7xyYre5TpTBnroIZE
Aq4+IYBrjqqSZcBJRhqcshtgDF6A2/AUhLeZZpokA9eL7KDxCG2L1QVjiO6c6DhM
ARc0SxsKhAOzxRUj1PqHQvtQCEhX5MvjkjgfwY7aDD9IGMmZU7/7+CR8QrilMICq
p4dJQWyiMmvwyQS0xBJEPEkUuHO89CTZ7VNs8/S1jhPwyo6myDwekKhmAS7Nc/Iz
G71YjwrV3+C7I31JiEEwe2y30RLncZdn9t+oySoCeznrvwtoK8cFzeJ9616As5Yz
smXgoGKQmyKnRw7WIto1MuLbvVr8NUGzY7PWCOmPASDu2UAnWgkIn6aTrJd9KWPB
4TZHhu+YVHVahkqugZSQ8g7aoaJ/7aURERlURASz1yDEPsmbmLt+4oI4PZUpCjHC
2fpXTSCqOPK1GqX1Hyxi5EnldbBCyoMbU+LwikD+8k+zc02U/iY=
=DiKo
-----END PGP SIGNATURE-----


pixel fairy

unread,
Jan 24, 2019, 11:01:31 PM1/24/19
to qubes-users
On Thursday, January 24, 2019 at 7:35:59 PM UTC-8, Andrew David Wong wrote:

> pixel fairy, please let us know of fully removing the old template first
> doesn't fix the problem.

thats what i ended up doing. i had to reinstall to delete them. then it worked.

then, with whonix, sys-firewall was full. changed the templates system storage max size to 20G. that problems hit me a few times before, but i think this should fix it. dnf clean all was not enough, probably because of how much is installed in the template.

Chris Laprise

unread,
Jan 25, 2019, 9:20:28 AM1/25/19
to Andrew David Wong, qubes...@googlegroups.com
On 01/24/2019 10:12 PM, Andrew David Wong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 23/01/2019 3.52 PM, Chris Laprise wrote:
>> On 01/23/2019 12:05 PM, Marek Marczykowski-Górecki wrote:
>>
>>> Patching
>>> =========
>>>
>>> If you are a Qubes user, you should remove all APT-based (including
>>> Debian and Whonix) TemplateVMs and StandaloneVMs, then install fresh
>>> ones. You can do this by performing the following steps on each such
>>> TemplateVM:
>>
>>
>> A shortened update procedure for debian-9:
>>
>> 1. If your "debian-9" template is customized or contains data, you may
>> wish to back it up with qvm-clone first...
>>
>> [dom0]$ qvm-clone debian-9 d9-backup
>>
>> 2. Run the upgrade command...
>>
>> [dom0]$ sudo qubes-dom0-update qubes-template-debian-9 \
>> --enablerepo=qubes*testing --action=upgrade
>>
>> This will display package info as it begins downloading. The package
>> version-date should begin with "4.0.1-20190123" or later.
>>
>
> Will this step work with templates where installed_by_rpm = false?

No, that's why I wrote "debian-9" template and referenced the package name.

I'm just now starting to address my non-rpm templates that were
originally cloned from the old debian-9. Probably will make new clones
of upgraded debian-9, apply customizations (its great to have them
written down), then use my 'findpref' script to switch all the relevant
VMs to the new template at once.

Alternately, if you know LVM commands you could just duplicate the
upgraded template's root volume into target (non-rpm) templates using
'lvcreate' and maybe zero-out the target private volume with
'blkdiscard' for extra safety. If I had a lot of specific Qubes settings
on the target template VMs I might have chosen this option.

Also see Fidel Ramos' advice about duplicating existing package
selections in the upgraded template.

Finally, if anyone suspects that malware may have taken hold in their
VMs because the old template was exploited (or other reason), my
Qubes-VM-hardening project installs a service that activates at VM
startup before any private-volume scripts are executed. This can
immunize the VM against malware persistence and also provides a shell
that can examine VM contents at the moment the private volume is first
mounted:

https://github.com/tasket/Qubes-VM-hardening

gone

unread,
Jan 25, 2019, 2:03:45 PM1/25/19
to qubes...@googlegroups.com
Chris Laprise wrote on Wed, 23 January 2019 21:52
> On 01/23/2019 12:05 PM, Marek Marczykowski-Górecki
> wrote:
>
> A shortened update procedure for debian-9:
>
> .....
>
> This method also works with whonix-gw-14 and
> whonix-ws-14 templates.
>
> --

This worked very well on the debian-9 template and thanks
again for it. But when I try that method for whonix-gw-14
template I get the following errors:

@dom0 ~]$ sudo qubes-dom0-update qubes-template-whonix-gw-14
--enablerepo=qubes*testing --action=upgrade
WARNING: Replacing a template will erase all files in
template's /home and /rw !
Template VM halted
Attempting to operate on template of UpdateVM... backing up
whonix-gw-14 to whonix-gw-14-backup-20190125-mhQ
qvm-clone: error: VM name must be shorter than 32
characters
ERROR: Unable to make backup of UpdateVM template!

I had already cloned the template (using a shorter name ;-)
) before starting this command. So this automatic backup
could be omitted in order to bring it forth if there exists
some option for that or an option to assign a custom name to
this automated backup file.

Or do I have to switch the default upgrade template for dom0
to something else instead of whonix-gw-14 before performing
the update action?


Chris Laprise

unread,
Jan 25, 2019, 2:45:36 PM1/25/19
to gone, qubes...@googlegroups.com
On 01/25/2019 02:03 PM, gone wrote:
> Chris Laprise wrote on Wed, 23 January 2019 21:52
>> On 01/23/2019 12:05 PM, Marek Marczykowski-Górecki
>> wrote:
>>
>> A shortened update procedure for debian-9:
>>
>> .....
>>
>> This method also works with whonix-gw-14 and
>> whonix-ws-14 templates.
>>
>> --
>
> This worked very well on the debian-9 template and thanks
> again for it. But when I try that method for whonix-gw-14
> template I get the following errors:
>
> @dom0 ~]$ sudo qubes-dom0-update qubes-template-whonix-gw-14
> --enablerepo=qubes*testing --action=upgrade
> WARNING: Replacing a template will erase all files in
> template's /home and /rw !
> Template VM halted
> Attempting to operate on template of UpdateVM... backing up
> whonix-gw-14 to whonix-gw-14-backup-20190125-mhQ
> qvm-clone: error: VM name must be shorter than 32
> characters
> ERROR: Unable to make backup of UpdateVM template!

This looks like a qubes-dom0-update bug.

>
> I had already cloned the template (using a shorter name ;-)
> ) before starting this command. So this automatic backup
> could be omitted in order to bring it forth if there exists
> some option for that or an option to assign a custom name to
> this automated backup file.
>
> Or do I have to switch the default upgrade template for dom0
> to something else instead of whonix-gw-14 before performing
> the update action?

You can try to change the updatevm as a workaround. If downloading the
template without Tor is OK you can just change it to sys-firewall or
similar VM.

John S.Recdep

unread,
Jan 25, 2019, 3:02:16 PM1/25/19
to qubes...@googlegroups.com
On 1/23/19 9:52 PM, Chris Laprise wrote:
> On 01/23/2019 12:05 PM, Marek Marczykowski-Górecki wrote:
>
>> Patching
>> =========
>>
>> If you are a Qubes user, you should remove all APT-based (including
>> Debian and Whonix) TemplateVMs and StandaloneVMs, then install fresh
>> ones. You can do this by performing the following steps on each such
>> TemplateVM:
>
>
> A shortened update procedure for debian-9:
>
> 1. If your "debian-9" template is customized or contains data, you may
> wish to back it up with qvm-clone first...
>
> [dom0]$ qvm-clone debian-9 d9-backup
>
> 2. Run the upgrade command...
>
> [dom0]$ sudo qubes-dom0-update qubes-template-debian-9 \
> --enablerepo=qubes*testing --action=upgrade
>
> This will display package info as it begins downloading. The package
> version-date should begin with "4.0.1-20190123" or later.
>
> 3. Shutdown all VMs so the upgrade can take effect...
>
> [dom0]$ qvm-shutdown --all --wait --timeout=30
>
> This method also works with whonix-gw-14 and whonix-ws-14 templates.
>

Tasket,

Does this mean that a upgrade to testing is as good as uninstalling -
re-installing templates ?

I guess your cloning debian-9-nonpatch'd just in case the upgrade fails
, which you'd rather do than reinstall fresh clean
debian-9-new-apt-version?


btw, somewhere in this thread I think I saw howto find which debian-9
useradded packages were installed, but maybe someone could confirm
how please

rec

Chris Laprise

unread,
Jan 25, 2019, 3:23:37 PM1/25/19
to John S.Recdep, qubes...@googlegroups.com
On 01/25/2019 03:01 PM, John S.Recdep wrote:
> On 1/23/19 9:52 PM, Chris Laprise wrote:
>> On 01/23/2019 12:05 PM, Marek Marczykowski-Górecki wrote:
>>
>>> Patching
>>> =========
>>>
>>> If you are a Qubes user, you should remove all APT-based (including
>>> Debian and Whonix) TemplateVMs and StandaloneVMs, then install fresh
>>> ones. You can do this by performing the following steps on each such
>>> TemplateVM:
>>
>>
>> A shortened update procedure for debian-9:
>>
>> 1. If your "debian-9" template is customized or contains data, you may
>> wish to back it up with qvm-clone first...
>>
>> [dom0]$ qvm-clone debian-9 d9-backup
>>
>> 2. Run the upgrade command...
>>
>> [dom0]$ sudo qubes-dom0-update qubes-template-debian-9 \
>> --enablerepo=qubes*testing --action=upgrade
>>
>> This will display package info as it begins downloading. The package
>> version-date should begin with "4.0.1-20190123" or later.
>>
>> 3. Shutdown all VMs so the upgrade can take effect...
>>
>> [dom0]$ qvm-shutdown --all --wait --timeout=30
>>
>> This method also works with whonix-gw-14 and whonix-ws-14 templates.
>>
>
> Tasket,
>
> Does this mean that a upgrade to testing is as good as uninstalling -
> re-installing templates ?

Yes. Everything in the template's root and private volumes is wiped
before the new package is added.

However we found out this doesn't work for Whonix if your updatevm is
set to sys-whonix. For debian-9 its fine.

>
> I guess your cloning debian-9-nonpatch'd just in case the upgrade fails
> , which you'd rather do than reinstall fresh clean
> debian-9-new-apt-version?

Its less hassle to qvm-clone to a backup, then run the upgrade.

>
>
> btw, somewhere in this thread I think I saw howto find which debian-9
> useradded packages were installed, but maybe someone could confirm
> how please

That was the post from Fidel Ramos:

https://groups.google.com/d/msgid/qubes-users/DM9_q5vgod4jYvlICr67Wg1SpGKDv2BNytlGZBHx2Tmd6J6w9DmZ2s__jTMhGtfAHvjigwMnaFYKLLhkEQHliA%3D%3D%40fidelramos.net

john s.

unread,
Jan 25, 2019, 4:31:46 PM1/25/19
to Chris Laprise, qubes...@googlegroups.com

>>
>> Tasket,
>>
>> Does this mean that a upgrade to testing  is as good as   uninstalling -
>> re-installing templates ?
>
> Yes. Everything in the template's root and private volumes is wiped
> before the new package is added.
>
> However we found out this doesn't work for Whonix if your updatevm is
> set to sys-whonix. For debian-9 its fine.


.....but, otherwise Marek's original Patch howto remains OK for
whonix-14 Q4.0 ?


>> I guess your cloning debian-9-nonpatch'd just in case the upgrade fails
>> , which you'd rather do  than  reinstall  fresh clean
>> debian-9-new-apt-version?
>
> Its less hassle to qvm-clone to a backup, then run the upgrade.

....less hassle meaning than new Templates , ?because one would not then
need to add back any useradded packages or both ?






--
A895 0C7C A244 8E2E FD77 A3DB 180B 7D4D D158 F8B6

John S.Recdep

unread,
Jan 26, 2019, 12:23:26 AM1/26/19
to qubes...@googlegroups.com

When I remove the whonix templates I get about 12 errors complaining
about /var/lib/qubes/vm-templates/whonix-ws-14/app.tempicons
/vm-whitelisted-appmenus.list

etc

no such file or directory


I suppose just another one of those mystery errors to ignore ?

John S.Recdep

unread,
Jan 26, 2019, 12:50:55 AM1/26/19
to qubes...@googlegroups.com
somewhere in this large thread it probably states there is an error in
the original whonix install invocation right ?

if one just uses community-testing they end up with 2018 version

so use the --enablerepo=qubes*testing instead ....

John S.Recdep

unread,
Jan 26, 2019, 12:53:59 AM1/26/19
to qubes...@googlegroups.com
sh**t now I am getting the correct whonix 2019 started but it fails with
"Disk quota exceeded" dnf clean packages 0 files removed so what
now please

Aly Abdellatif

unread,
Jan 26, 2019, 4:30:09 AM1/26/19
to qubes-users
@John S redcap

Go into the updateVM and delete unneeded rpms :
/var/lib/qubes/dom0-updates/packages

If you didnt change your updateVM, it will be in sys-firewall

And then add - - clean in your qubes-dom0-update
Command

Alexandre Belgrand

unread,
Jan 26, 2019, 5:42:32 AM1/26/19
to qubes-users
Le mercredi 23 janvier 2019 à 18:05 +0100, Marek Marczykowski-Górecki a
écrit :
> We have just published Qubes Security Bulletin (QSB) #46:
> APT update mechanism vulnerability.

Keep in mind that all PGP Debian/Ubuntu signing keys have been stolen
and injection may occur during apt-get install/update using man-in-the-
middle attack, at least in some countries. Unless packages are compiled
with reproducible builds and fingerprints are available online, there
is no way to avoid such an attack.

John S.Recdep

unread,
Jan 26, 2019, 1:02:52 PM1/26/19
to qubes...@googlegroups.com
hmm, this is a /var/lib/qubes/updates/rpm/ directory with 4 rpm in it
(2 whonix-gw one is the 2018, one the 2019, 1 deb-9 2019 and 1 whonix-ws
2018)

(there is no /var/lib/qubes/dom0-updates just /updates in this
4.0-> 4.1 install)


suppose that is the one, not sure what you mean by sys-firewall being
"it"

so something like
sudo qubes-dom0-update qubes-template-whonix-gw-14
--enablerepo=qubes*testing --clean ??

after deleting the 4 template rpms in /rpm ?

Aly Abdellatif

unread,
Jan 26, 2019, 1:41:39 PM1/26/19
to qubes-users
@John S.Recdep

1. Go into sys-firewall and delete rpms available in /var/lib/qubes/dom0-updates/packages

and then in dom0 use sudo qubes-dom0-update qubes-template-whonix-gw-14
--enablerepo=qubes*testing --clean


John S.Recdep

unread,
Jan 26, 2019, 4:25:55 PM1/26/19
to qubes...@googlegroups.com
On 1/26/19 6:41 PM, Aly Abdellatif wrote:
> @John S.cde
>
> 1. Go into sys-firewall and delete rpms available in /var/lib/qubes/dom0-updates/packages
>
> and then in dom0 use sudo qubes-dom0-update qubes-template-whonix-gw-14
> --enablerepo=qubes*testing --clean
>
>

there is nothing in that dir/ (in sys-firewall) nor in sys-net
/packages but it seems removing them from /var/lib/qubes/updates/rpm
fixed the diskquota error ....



on an interesting note folks over at other distros like linuxmint seem
wholly unconcerned with reinstall and seem certain that just
upgrading apt is all that is necessary....



when I mentioned that recent comment in this thread about "stolen
keys" I am asked for a reference for this, and accused of FUD :)

I am not a SA, so that comment would be very serious if true correct ?

Chris Laprise

unread,
Jan 26, 2019, 4:31:53 PM1/26/19
to Alexandre Belgrand, qubes-users
WAT?

unman

unread,
Jan 26, 2019, 7:54:30 PM1/26/19
to qubes-users
On Sat, Jan 26, 2019 at 11:42:27AM +0100, Alexandre Belgrand wrote:
> Le mercredi 23 janvier 2019 ŕ 18:05 +0100, Marek Marczykowski-Górecki a
What a great start to the week.
Do you have *any* evidence for this claim?

Holger Levsen

unread,
Jan 27, 2019, 8:11:43 AM1/27/19
to qubes-users
On Sun, Jan 27, 2019 at 12:54:26AM +0000, unman wrote:
> > Keep in mind that all PGP Debian/Ubuntu signing keys have been stolen
> Do you have *any* evidence for this claim?

I *believe* they probably misunderstood evil32.com and it's fallout.


--
tschüß,
Holger

-------------------------------------------------------------------------------
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
signature.asc

unman

unread,
Jan 27, 2019, 9:09:37 AM1/27/19
to qubes-users
Do you think so? That doesn't seem what they are claiming.
Alexandre , what was it you meant?

The problem is that I *already* see this sort of claim spreading - see
another posting by John Redcap - and eventually there'll be a group of
users convinced that all signing keys have been stolen.
It's very difficult to stop a canard like this.
Unless, of course, Alexandre has some evidence?

Alexandre Belgrand

unread,
Jan 27, 2019, 9:33:15 AM1/27/19
to qubes-users
Le dimanche 27 janvier 2019 à 13:11 +0000, Holger Levsen a écrit :
> I *believe* they probably misunderstood evil32.com and it's fallout.

CAs and GNU/Linux distributions are #1 targets for national
intelligence agencies.

Debian developers are not using smartcards to store their GPG keys,
including the master key signing code. It is very likely that Debian
master key has been stolen. I would be very surprised if it had not
been stolen.

One reason why nobody wants to use SSL, including OpenBSD, is that
there is a wide belief that SSL private keys have been stolen.
Therefore there is no need to use SSL, as it does not offer a real
protection.

This is simply GAME OVER (part 1 of the game).

One reason why I am not using Qubes, is that it does not offer a real
protection compared to Debian, as both systems are IMHO compromised.

At present, any government with a valid certificate from Intel can use
Intel ME backdoor to access all resources from a computer, including
keyboard and screen and there is no way to secure an X86 computer.

If Qubes was making a wide use of Smartcards with a separate pinpad
reader and was using a hardened operating system like OpenBSD or even a
hardened GNU/Linux, I would have a closer look at it.


unman

unread,
Jan 27, 2019, 11:47:26 AM1/27/19
to qubes-users
I'd be interested to know what system has been graced with your
approval.
If you believe all this, then what makes you think that national
intelligence agencies haven't infiltrated *bsd, coreboot and any other
system you can name.
imo Qubes does a reasonable job of providing a more secure system
that's usable by ordinary users.
Spreading unfounded allegations is a disservice to the community.

Alexandre Belgrand

unread,
Jan 27, 2019, 12:04:52 PM1/27/19
to qubes-users
Le dimanche 27 janvier 2019 à 16:47 +0000, unman a écrit :
> I'd be interested to know what system has been graced with your
> approval.
> If you believe all this, then what makes you think that national
> intelligence agencies haven't infiltrated *bsd, coreboot and any
> other
> system you can name.
> imo Qubes does a reasonable job of providing a more secure system
> that's usable by ordinary users.

Simply no x86 system is reasonably secure.

> Spreading unfounded allegations is a disservice to the community.

Qubes is interesting because it is trying to answer security needs and
the design is nice.

But think about Intel ME backdoor. Imagine that any officer with a
signed certificate of Intel can penetrate dom0 in your computer within
seconds and then view your screen, move your mouse and type on your
keyboard. This is reality and Qubes cannot change it.

qube...@tutanota.com

unread,
Jan 28, 2019, 10:47:11 AM1/28/19
to Alexandre Belgrand, qubes-users

Jan 27, 2019, 5:04 PM by alexandre...@mailbox.org:

> Le dimanche 27 janvier 2019 à 16:47 +0000, unman a écrit :
>
>> I'd be interested to know what system has been graced with your
>> approval.
>> If you believe all this, then what makes you think that national
>> intelligence agencies haven't infiltrated *bsd, coreboot and any
>> other
>> system you can name.
>> imo Qubes does a reasonable job of providing a more secure system
>> that's usable by ordinary users.
>>
>
> Simply no x86 system is reasonably secure.
>
>> Spreading unfounded allegations is a disservice to the community.
>>

Most of the serious users are very well aware of the IME/AMT vulnerability and are addressing it continuously and publicly. See Joanna Rutkowska and her talks. You are looking for a 100% solution. Big surprise is a 100% solution is not existing and will never be.
You can of course use a libre X200 without IME and without real virtualization too, having again to deal with issues of a monolythic system.
Tradeoff can be the X230 with more-less disabled IME with proper virtualization.

What do you yourself use?


> Qubes is interesting because it is trying to answer security needs and
> the design is nice.
>
> But think about Intel ME backdoor. Imagine that any officer with a
> signed certificate of Intel can penetrate dom0 in your computer within
> seconds and then view your screen, move your mouse and type on your
> keyboard. This is reality and Qubes cannot change it.
>
Qubes doesn't even claim to change it. You need to address Intel same way as Qubes ppl do and ask them to close the backdoor.

Are you aware that spreading of the false claims *can be* an intelligence operation to undermine user's support and appreciation of the codes like Debian and Qubes? From leaked materials is known that the US IAs named for example Tails based on Debian as a total apocalypse for intelligence collection for them, if spread.

Keep in mind, nothing is perfect. But if you have an option for a better set and setting, put it up.



> --
> You received this message because you are subscribed to the Google Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to > qubes-users...@googlegroups.com <mailto:qubes-users...@googlegroups.com>> .
> To post to this group, send email to > qubes...@googlegroups.com <mailto:qubes...@googlegroups.com>> .
> To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-users/65d4efc1f6cc5203a5fc080...@mailbox.org <https://groups.google.com/d/msgid/qubes-users/65d4efc1f6cc5203a5fc0802e2cdff2e9fc992f7.camel%40mailbox.org>> .
> For more options, visit > https://groups.google.com/d/optout <https://groups.google.com/d/optout>> .
>

Stuart Perkins

unread,
Jan 28, 2019, 12:47:03 PM1/28/19
to qubes...@googlegroups.com
Up to a certain manufacture, you can go to coreboot and lose the ME entirely. After that point, setting the HAP bit may be your best option. We need someone to to reverse engineer the ME and implement enough of it in coreboot to take over so the newer ones will run.

Holger Levsen

unread,
Jan 28, 2019, 12:57:27 PM1/28/19
to qubes...@googlegroups.com
On Mon, Jan 28, 2019 at 11:46:55AM -0600, Stuart Perkins wrote:
> Up to a certain manufacture, you can go to coreboot and lose the ME entirely. After that point, setting the HAP bit may be your best option. We need someone to to reverse engineer the ME and implement enough of it in coreboot to take over so the newer ones will run.

thats not enough. on modern intel cpus there's boot-guard which will
prevent booting with coreboot unless it's signed with a secret intel
key.
signature.asc

gold...@riseup.net

unread,
Jan 28, 2019, 4:08:52 PM1/28/19
to Alexandre Belgrand, qubes-users
To Alexandre Belgrand


I'm intrigued how you know can catagorically state "CAs and GNU/Linux
distributions are #1 targets for national
intelligence agencies". This is classified information and therefore
only available to a "Spook". Otherwise, it's entered the public domain
via say a whistle blower like Ed Snowden. If that's how you came upon
it, please state the source and location.

Alexandre Belgrand

unread,
Jan 28, 2019, 4:25:04 PM1/28/19
to qubes-users
Le lundi 28 janvier 2019 à 16:47 +0100, qube...@tutanota.com a
écrit :
> What do you yourself use?
Hope I can answer too.

I use an X230 with Intel ME disabled from BIOS. It costs about 160€ on
the second hand market and it has pretty decent hardware. Lenovo claims
that Intel ME can be disabled, but Intel ME is still running and may
accept remote shadow connections given a signed certificate from Intel.

This is why I am only reading the mailing list and not using Qubes. At
present, I consider Qubes as an interesting development, but not
reaching its goals because dom0 can be penetrated using Intel ME.

I am quite amused by tails sending an update command on each boot. You
can be sure to light red light in a control center and be penetrated
within seconds if need be. Remember that governments have control of
most outgoing nodes. So neither do I use Tor.

You just can't simply store valuable documents on a computer when
connected to a network. Companies that care about security should have
a complete process to manage workstations and internal networks,
without access to the Internet. We are back to ancien times.

Kind regards,
Alexandre Belgrand

Alexandre Belgrand

unread,
Jan 28, 2019, 4:51:18 PM1/28/19
to qubes-users
Le lundi 28 janvier 2019 à 13:08 -0800, gold...@riseup.net a écrit :
> To Alexandre Belgrand
>
> I'm intrigued how you know can catagorically state "CAs and GNU/Linux
> distributions are #1 targets for national
> intelligence agencies". This is classified information and therefore
> only available to a "Spook". Otherwise, it's entered the public
> domain
> via say a whistle blower like Ed Snowden. If that's how you came upon
> it, please state the source and location.

I am not a whistle blower, but I believe that all CAs and GNU/Linux
distributions are primary targets for Intelligence agencies. This is
not secret, this is why I am writing it, sitting behind my real IP.

You will find this information on Internet. Look for the recent
problems with China for example.

Stealing root certificates allow Intelligence agencies to set-up mirage
Internet : i.e. decrypt SSL/crypted content and present modified
content to the user and make man-in-the-middle attack.

Think about Debian private keys. The keys are stored on a server in a
datacenter, not even on smartcards. What can stop a remote attacker
with a remote console (either directly or using Intel ME) from stealing
the keys and then breaking password using a keylogger in Intel ME.
Answer : nothing can stop a local government from doing so.

Think about SSL X509 certificates. To deliver encrypted content, the
private key has to be on the server. You only need serial console
access to steal the private key.

The only solution is to compile the same bytecode and verifying hashes
online, but Debian is lagging behind important patches, because they
don't understand what already happened.



Alexandre Belgrand

unread,
Jan 28, 2019, 5:19:39 PM1/28/19
to gold...@riseup.net, qubes-users
Le lundi 28 janvier 2019 à 13:08 -0800, gold...@riseup.net a écrit :
> I'm intrigued how you know can catagorically state "CAs and GNU/Linux
> distributions are #1 targets for national

China:
https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies

China uses a tiny chip to intercept data. Read Bloomberg article.

"A chip can also steal encryption keys for secure communications, block
security updates that would neutralize the attack, and open up new
pathways to the internet."


US:
https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine.pdf

The US are using Intel ME backdoor to take complete control of a
computer using a built-in VNC server and shadow connections.

"Has built-in full-fledged web and VNC servers" (page 20)

So my assumption was that all these backdoors were made for the primary
targets of stealing secret keys.

Game-over. Once the private keys have been stolen, "mirage Internet".
At the state of technology, I don't want Qubes users to believe that
Qubes is secure. Qubes is INsecure.

Ilpo Järvinen

unread,
Jan 28, 2019, 5:59:57 PM1/28/19
to Alexandre Belgrand, gold...@riseup.net, qubes-users
On Mon, 28 Jan 2019, Alexandre Belgrand wrote:

> Le lundi 28 janvier 2019 à 13:08 -0800, gold...@riseup.net a écrit :
> > I'm intrigued how you know can catagorically state "CAs and GNU/Linux
> > distributions are #1 targets for national
>
> China:
> https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies
>
> China uses a tiny chip to intercept data. Read Bloomberg article.
>
> "A chip can also steal encryption keys for secure communications, block
> security updates that would neutralize the attack, and open up new
> pathways to the internet."

There are many technical reasons raising from plain physics/electronics
which make an attack chip of that size with the described capabilities to
seem quite utopistic (and the article therefore bogus). ...But of course
you can choose to believe what you want.


--
i.

Alexandre Belgrand

unread,
Jan 29, 2019, 2:32:49 AM1/29/19
to qubes-users
Le mardi 29 janvier 2019 à 00:59 +0200, Ilpo Järvinen a écrit :
> There are many technical reasons raising from plain
> physics/electronics
> which make an attack chip of that size with the described
> capabilities to
> seem quite utopistic (and the article therefore bogus). ...But of
> course
> you can choose to believe what you want.

The Chinese chip has been found and exists, no doubt about it. It was
found on thousands of servers, so I believe it is being analyzed.

Ilpo Järvinen

unread,
Jan 29, 2019, 2:51:08 AM1/29/19
to Alexandre Belgrand, qubes-users
Yeah yeah, the only modification was that chip as claimed in the article?
Magically all the necessary signal pins were routed to its location
but nothing else was changed (and you cannot have that many pins in
that sized chip anyway which will seriously limit the possible functionality
and processing speed). ...But it must all be true and present in thousands
of servers because a sensational article so claims (funny though that the
so claimed victims of the attack consistently denied presence of such a
chip in their servers but I guess you'll anyway think they must be lying
for the benefit of the Chinese, damage control, because of the
"investigation", or whatever reason).

--
i.

Alexandre Belgrand

unread,
Jan 29, 2019, 3:13:39 AM1/29/19
to qubes-users
Le mardi 29 janvier 2019 à 09:51 +0200, Ilpo Järvinen a écrit :
> Yeah yeah, the only modification was that chip as claimed in the
> article?
> Magically all the necessary signal pins were routed to its location
> but nothing else was changed (and you cannot have that many pins in
> that sized chip anyway which will seriously limit the possible
> functionality
> and processing speed). ...But it must all be true and present in
> thousands
> of servers because a sensational article so claims (funny though that
> the
> so claimed victims of the attack consistently denied presence of such
> a
> chip in their servers but I guess you'll anyway think they must be
> lying
> for the benefit of the Chinese, damage control, because of the
> "investigation", or whatever reason).


Good point. Obviously, this article has had access to classified
informations and is part of a new "name and shame" policy. So can we
trust it?

My personal opinion is that adding backdoors in consumer electronics is
like an arms race. Once it starts, it cannot and will not stop.

qube...@tutanota.com

unread,
Jan 29, 2019, 5:22:55 AM1/29/19
to Alexandre Belgrand, qubes-users

Jan 28, 2019, 9:25 PM by alexandre...@mailbox.org:

> Le lundi 28 janvier 2019 à 16:47 +0100, > qube...@tutanota.com <mailto:qube...@tutanota.com>> a
Hardware is only one part, right? The question was about the package you use. What OS, network, apps...yu propose? So, what so you use?

Realize please, that you stand against SW, the OS (Qubes), arguing about HW. Also you argue about statements Qubes devs and especially Joanna Rutkowska, never claimed. They never claimed that Qubes is IME resistant. Actually the opossite. If they did, post their statement here please. I heard her instead stressing publicky and repeatedly that the IME is a global issue, not only of Intel (see PSP), to be addressed. You are fighting against non-existent claims arguing against Qubes. Even the name of the Qubes-OS - A REASONABLY secure OS. They dont claim Qubes is - An omnipotent 100% solution and IME resistant. Or do they? :)

The IME attack is only one of many possible attacks. If you are opened to this kind of attack only, and resistant against many others, present in the traditional OSes, you increased your sec reasonably.

Lets put it other way round. Everyone of us is a wrench-decryption non-resistant. If an adversary starts your thumb-wrench party, what finger-wrench decrypts your password and all the secrets? Now knowing this, do you use passwords or you just gave up, because the found that terrible wrench-security-hole in the system? Do you let your phone unencrypted and unlocked, available to anyone, your credit card number CVV and PIN public, cause both ways it can be cracked? Your email password, chat pass, your https cert if you own the domain? Do you keep your house unlocked at all times, cause both ways the lock can be hacked? Do you see the point?

And the last question. Last but not least. You stated in one of your conversations here that you want people to stop using Qubes for security. Interesting - why would wish to do that? What is the benefit for you? How do we know you are not just another IS spook tasked with the attack on reasonable secure system, which provides very high security for even semi-tech users?

Also if you would like to increase you paranoia, read the Yasha Levine, Surveillance Valley. In that case you can forget everything and ask only one question - can the tech that was designed to enslave us, save us? And if so, how one does that.


>
> --
> You received this message because you are subscribed to the Google Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to > qubes-users...@googlegroups.com <mailto:qubes-users...@googlegroups.com>> .
> To post to this group, send email to > qubes...@googlegroups.com <mailto:qubes...@googlegroups.com>> .
> To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-users/84ef99dc3a6aad1e8e035b5...@mailbox.org <https://groups.google.com/d/msgid/qubes-users/84ef99dc3a6aad1e8e035b5dda640ed306d27792.camel%40mailbox.org>> .

gold...@riseup.net

unread,
Jan 29, 2019, 5:24:53 AM1/29/19
to Alexandre Belgrand, qubes-users
To Alexandre
So you found this stuff on the internet and were gullible enough to
swallow it, hook line and sinker, without first verifying its
authenticity. I suppose your allegations against the Debian Team's
security keys are based on equally unstable foundations.

The making of serious random and unsolicited allegations with the
intention of scaremongering, could be described as TROLLING.

Stuart Perkins

unread,
Jan 29, 2019, 8:16:55 AM1/29/19