Qubes - Critique (long)

547 views
Skip to first unread message

John Goold

unread,
Mar 15, 2019, 10:31:10 PM3/15/19
to Qubes Users Google-Groups
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

*A Critique of Qubes*

Before discussing Qubes, I want to give you a bit of background about
me. I do not want to tell my life-story, I doubt anyone is interested.
However, I want you to know "where I am coming from" and what I want
from Qubes. I am keeping in mind that what I want is just that and
Qubes may not be intended to satisfy, or interest in satisfying my
wants and needs -- that is, I may simply be part of the wrong
demographic.

* Retired roughly 2 decades
* 73 years old
* Degree in Computer Science
* Started out programming mainframes in Assembly Language (machine
code)
* Later, large-scale software development (various roles) -- R & D,
telecoms and mission-critical apps (those involved in health-care are
regulated)
* Proprietary H/W and OSes, then various Unixes.

I am not paranoid over privacy and security, but I recognize there are
many individuals who, rightfully, fear for their privacy and anonymity
- -- their livelihood and even their lives may depend on it.

Wants:

* Reliability -- do not fail on me or, if something goes wrong, fail
gracefully.
* Reasonable security -- more than is provided by the more standard
Linux distributions (I am a fan of Linux Mint).
* Reasonable privacy (I hope that is not an oxymoron); though perhaps
it is too late in the game for me (though I have never been a fan of
social media, or anything Google)
* No need to spend large amounts of time tinkering with my basic
personal computer setup.
* Ease of use and administration, including software installation.
* GUI for virtually everything unless there is a really, really, really
good reason to use a CLI. Do not get me wrong, I am comfortable with
CLI's, but I do not want to spend my time researching various Linux
administration tools. Consider me lazy if you wish.
* No need to build my own tools to use Qubes (I do some website and
server- side development to keep the neurons firing -- I can do all
the programming I want in that environment).

Basically, my personal computer(s) is a tool. If I write some software
on it, that software will be for some other purpose and not to
complement the OS.

- ---------------------------------------------------------------------

Critique:

I started using Qubes for my main computer about two months ago. I had
previously experimented with release 3.2 and 4.0 on my HP laptop and
ran into various problems -- discussed by many users ad nausium in
qubes-users. I got a nice little desktop computer for Christmas (from
my wife :-) -- an Intel NUC7i7 (32 GB RAM, 512 GB SSD).

So I started from the beginning. Installing Qubes 4.0.1 was relatively
straightforward, although it did require researching the use of a USB
mouse and keyboard.

Basic configuration was no worse than any Linux distribution I have
played with. Software installation was not as straightforward. I was
forced into using the CLI (I do have two proprietary programs: VueScan
and Bcompare). Installing other software can be problematic. I
installed Chromium. The install appeared successful. I was able to add
Chromium to an appVM. When I started the appVM and launched Chromium
from the menu... nothing! No window, no error message. I tried a number
of times (the reason for just re-trying will be mentioned below).

Issues...

* When launching a program from the Qubes menu, particularly if the
target appVM has to be started, the program often fails to be
launched. This happens very frequently with the Text Editor.

This is annoying as one waits a bit in case one is simply being
impatient, or at least I do, so as not to launch two copies of the
program by accident.

* When a USB device is attached to an appVM, there is an appropriate
notification. When it is detached, there is a notification that the
device is being detached, but no notification to indicate that it has
been successfully detached so how long should one wait before
unplugging it?

* Ignoring whonix (I do not use it... yet), there are two template VMs
in the vanilla Qubes 4.0.1 installation: Fedora and Debian. However,
they have not been treated equally, with Debian being the loser. The
Qubes documentation indicates that Fedora was favoured for security
reasons.

Since I had been using Linux distributions based, directly or
indirectly, on Debian, when I first set up Qubes, I created my appVMs
based on Debian. That was painful as I then had to install a lot of
basic software.

When I re-read the documentation, I realized the security reasons,
so I switched all my appVMs (except one!) back to Fedora. It was not
painful, but I would have rather have spent the time doing something
else.

The kicker came when Firefox stopped playing Flash content in my
untrusted appVM, complaining that I needed an up to date version of
Flash. I installed the most recent version, but that did not solve
the problem. The problem is/ was something to do with Fedora (or the
version of Firefox for Fedora or ??).

Since Firefox and Flash were working fine on my Linux Mint laptop
(which I use "to play with"), I re-based my untrusted appVM on Debian
and, lo and behold, Firefox and Flash worked just fine. This, by the
way, was when I attempted to use Chromium.

The appVM that had remained Debian-based (the "except one" mentioned
above) is my "entertainment" appVM that I use for streaming radio via
Firefox and playing audio files (VLC player).

At least for some people, it seems Debian is a necessity, but it is
not given the attention it deserves. At a minimum, a GUI software
installer should be included in the Qubes distribution which would
make it much easier for people to install other software they feel
inclined to use.

* Screenshot only appears to work from Qubes Tools. I can "add"
"Screenshot" to appVMVs based on Fedora (but not on Debian). But it
does not work -- The dialog comes up but, having chosen to select an
area, I cannot do so.
Subsequent attempts to use Screenshot do not even present a dialog.

Although I have not seen this documented anywhere (which does not
mean it is not), it seems logical -- dom0 owns the screen (monitor),
so it makes sense that it handles screenshots. However, that means
screenshots are saved in dom0 and have to be moved (or, I suppose,
copied) to the desired appVM. It seems a bit awkward. If one is in a
program in an appVM and decides a screenshot would be nice, it is
probably focussed on that window or a portion of it. Since the OS
displaying the window "knows" what it is displaying, it seems logical
that some kind of screenshot could be made by that OS, but restricted
to its window.

If not, why is it possible to "add" Screenshot to an appVM?

* About a week ago, I started having a problem: I could not
copy-and-paste between appVMs. Prior to that, I had been having
problems with Firefox freezing in different appVMs. Rebooting the
affected appVM solved (or should I say "worked around") the latter
issue; however, it had no effect on the former problem.

[Aside] Ever since my mainframe and Unix days, I have been used to
systems that would run for weeks or months between reboots.
That experience did not carry over to personal computers
until relatively recently (in terms of years) when improvents
in hardware and my switch to Linux got me back into the habit
of rebooting only when necessary.

Using Linux and now Qubes, I not only do not shutdown the computer
(i.e. power-off), but I do not logout -- I simply "Lock the Screen"
and power-off my monitor.

So, wondering about the copy-and-paste problem (and also the Firefox
issue), I decided to re-boot. I individually shut down each VM after
quitting its running programs -- dom0 and the sys- VMs excepted,
before clicking Shutdown (rightmost menu with my user name on it).

That looked like it solved the problems, but...

KeePassX 2 complained that I had the wrong password or the database
was corrupted. It was not a typo in the password (I tried several
times and restarted the vault VM to be sure nothing was wrong).

I was able to restore the vault VM from a backup, but was missing a
few entries. That was alright since my real password vault is on my
smart phone (FWIW, I use mSecure and keep it automatically backed up
to DropBox).

My Bottom Line:

I can live with most of the issues described above. What I cannot live
with (and worry about) are stability and reliability issues.

[Aside] I do not intend doing a daily full back-up. I do not wish to be
hypocritical, so full-disclosure: When I was managing the
internal hardware and software support teams at a Bell-Northern
Research lab., I insisted on daily backups. When managing the
"System Programming" group for a mainframe (same as the modern
"System Administration") the scheme involved daily, weekly,
monthly and annual backups of data files and backups whenever
the operating system was updated, withappropriate off-site
storage.

[Disclosure] I run a FreeNAS file server on a computer on my LAN
Whenever I create (or update) a file that involves my family
(that is, something legal, financial, or similar), I *always*
copy it immediately to the fileserver. In that sense, the only
"stuff" I will lose in a catastrophic failure of my personal
computer and my Qubes backups, is personal stuff not involving
my family.

My wife has access to the file server. My wife knows the master
password to my mSecure password vault (and I to hers). One of
our children has those master passwords in a sealed envelope).
In fact, my wife has the keyphrase for my encrypted Quebes disk
(Luks?) and my login password -- that does not mean she could
manage to navigate Qubes, but I intend to show her.

[Question] So, what do other Qubes users do to protect their families
in case they die/get killed, get imprisoned, go missing?

I need some reasonable assurance that data corruption on disk has a
very low probability. I need some reasonable assurance that the
operating system (the combination of Xen and dom0) is stable.

I will probably survive regardless. However, I assume (hope) there are
others like me. Qubes addresses a relatively small proportion of the
population. However, it does not hurt if it can include people like me
if nothing else, some of us would undoubtedly donate money and help
support Qubes. The user base may be very small, but there is no reason
to force it to be tiny.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEe8Wcf7Po7bts2Rl4jWN9/rQYsRwFAlyMX+QACgkQjWN9/rQY
sRzdQQf/WltsYXQ+TQJgLmaJDSe8KtK2lJJyDzQ8uBVffwRsGX+8iD9r7HiJgAm6
v80S6AYPeVz00XpGB2QM3jHYNhFyIMcxVXDAh7NH6rwtnxLeGZef6ABtUCYRZX36
RNja8qSHt2cGp/JhSlrPtPMGjIUng1cuWbP4PT0qPAiwSYra8kMAYPWK6SHvXZ6E
g3FZ/pEGCBRDKdvAxCcT8vNNobDEssPvjvrYmWL92wij2seEvqwa78HrPVw1F1Gn
jbr6kAor+rd597eflHcR+XlEXBA46iMuHIuAU9R+phBCACaSH9tz1qAZ/8WJlGyY
vud5KdimUm4wgQ7HSbODqn0hmA/0bw==
=NPJ4
-----END PGP SIGNATURE-----

Chris Laprise

unread,
Mar 16, 2019, 7:31:28 AM3/16/19
to jrg.p...@goold.net, Qubes Users Google-Groups
Hi John,

That's an interesting background and list of wants. I've been using
Qubes for some time and can try to address a few of your issues.


On 3/15/19 10:31 PM, John Goold wrote:
> Issues...
>
> * When launching a program from the Qubes menu, particularly if the
> target appVM has to be started, the program often fails to be
> launched. This happens very frequently with the Text Editor.
>
> This is annoying as one waits a bit in case one is simply being
> impatient, or at least I do, so as not to launch two copies of the
> program by accident.

This well-known bug appears to center on programs based on Gtk+ and/or
Gnome. The only way to consistently avoid it is to install Qt/KDE or
other non-Gtk+ software in the templates. KDE works well and Debian+KDE
is what the Whonix templates are based on.

The steps on Debian 9:
> $ sudo apt-get remove gnome*
> $ sudo apt-get install gnome-icon-theme task-kde-desktop
> $ su -c "echo export XDG_CURRENT_DESKTOP=KDE >/etc/profile.d/qkde.sh"

After that, you'll need to adjust the Applications tab in the template's
Settings, and possibly for some of the VMs that are based on it.

(Also switching dom0 to KDE is an option, and this has solved a raft of
usability issues for me.)

>
> * When a USB device is attached to an appVM, there is an appropriate
> notification. When it is detached, there is a notification that the
> device is being detached, but no notification to indicate that it has
> been successfully detached so how long should one wait before
> unplugging it?

There is probably no delay required but a couple of seconds suffices for me.

>
> * Ignoring whonix (I do not use it... yet), there are two template VMs
> in the vanilla Qubes 4.0.1 installation: Fedora and Debian. However,
> they have not been treated equally, with Debian being the loser. The
> Qubes documentation indicates that Fedora was favoured for security
> reasons.

IIRC there is mention that Fedora was chosen for convenience, not
security. Fedora actually presents a security problem for Qubes and
there is an open issue for moving Qubes off of it.

The problem with the Debian template is that its not preconfigured with
an array of familiar apps, and when you do add them some of the default
file/app associations remain set to unfriendly substitutes (like text
files being associated to emacs, pictures set to imagemagik or gimp,
etc.). Switching to KDE has set these associations to reasonable defaults.

Its also doesn't have the full set of kernel firmware packages installed
but that's easy to remedy.

>
> Since I had been using Linux distributions based, directly or
> indirectly, on Debian, when I first set up Qubes, I created my appVMs
> based on Debian. That was painful as I then had to install a lot of
> basic software.
>
> When I re-read the documentation, I realized the security reasons,
> so I switched all my appVMs (except one!) back to Fedora. It was not
> painful, but I would have rather have spent the time doing something
> else.

I would like to know where it says this about security. Most Qubes users
consider Debian to be (in general) more secure. The open issue for
migration away from Fedora is at:

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

>
> The kicker came when Firefox stopped playing Flash content in my
> untrusted appVM, complaining that I needed an up to date version of
> Flash. I installed the most recent version, but that did not solve
> the problem. The problem is/ was something to do with Fedora (or the
> version of Firefox for Fedora or ??).

I haven't used Flash in a long time so I can't help there. In general
its best to find an alternative that doesn't rely on Flash, which is
becoming a dead format. Typically Flash is replaced by HTML5 web apps
(and most websites have made this switch automatic).

> * Screenshot only appears to work from Qubes Tools. I can "add"
> "Screenshot" to appVMVs based on Fedora (but not on Debian). But it
> does not work -- The dialog comes up but, having chosen to select an
> area, I cannot do so.
> Subsequent attempts to use Screenshot do not even present a dialog.
>
> Although I have not seen this documented anywhere (which does not
> mean it is not), it seems logical -- dom0 owns the screen (monitor),
> so it makes sense that it handles screenshots. However, that means
> screenshots are saved in dom0 and have to be moved (or, I suppose,
> copied) to the desired appVM. It seems a bit awkward. If one is in a
> program in an appVM and decides a screenshot would be nice, it is
> probably focussed on that window or a portion of it. Since the OS
> displaying the window "knows" what it is displaying, it seems logical
> that some kind of screenshot could be made by that OS, but restricted
> to its window.
>
> If not, why is it possible to "add" Screenshot to an appVM?

Qubes doesn't limit which apps can be installed in templates. So this is
considered more of a "sensible defaults" issue, where screenshot apps
are not preconfigured in templates, and are preconfigured in dom0.

As for saving screenshots, there is an open issue and a mostly-finished
utility that attempt to address this. OTOH, I just use 'qvm-move-to-vm'
from the shell when I'm done snapshotting.

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

>
> * About a week ago, I started having a problem: I could not
> copy-and-paste between appVMs. Prior to that, I had been having
> problems with Firefox freezing in different appVMs. Rebooting the
> affected appVM solved (or should I say "worked around") the latter
> issue; however, it had no effect on the former problem.

The current Firefox ESR does have a tendency to freeze temporarily when
memory gets low. I'm considering switching to the non-ESR 'firefox'
package in Debian to see if the newer versions are better in this respect.

I think someone reported here in qubes-users that copy/paste stopped
working for them. Since this is a dom0-controlled feature it may be that
your preference for long uptimes is overlapping with a Qubes daemon
stability issue -- sometimes a dom0 Qubes process will just exit,
although I haven't experienced this with copy/paste and I reboot on
average a couple times per week.

> My Bottom Line:
>
> I can live with most of the issues described above. What I cannot live
> with (and worry about) are stability and reliability issues.
>
> [Aside] I do not intend doing a daily full back-up. I do not wish to be
> hypocritical, so full-disclosure: When I was managing the
> internal hardware and software support teams at a Bell-Northern
> Research lab., I insisted on daily backups. When managing the
> "System Programming" group for a mainframe (same as the modern
> "System Administration") the scheme involved daily, weekly,
> monthly and annual backups of data files and backups whenever
> the operating system was updated, withappropriate off-site
> storage.

I'm about to release a beta for my backup utility that can perform quick
incremental backups of Qubes volumes. The working title is 'sparsebak'
and it works like Apple's Time Machine in a sense... you only need to do
one full backup (ever) and it can quickly recover space from old backup
sessions:

https://github.com/tasket/sparsebak/tree/new4

The idea behind sparsebak is similar to Time Machine -- that even VM
backups should be so efficient that you could backup many times each day
without experiencing a burden on your time or system resources. It
depends solely on the amount of change your volumes incur, so that even
very large files experiencing small changes are backed up in a flash.

Its pretty unique on Linux -- capable of updating a VM volume over Wifi
in 1 or 2 seconds -- and I feel the 'new4' branch is already at least
beta quality. The storage format is also simple enough so that regular
Linux tools can recover data from an archive. Although its CLI-based,
you might want to give it a try.

An alternative to this is to setup a Btrfs or ZFS storage pool for your
VMs (if you didn't already install Qubes on Btrfs) and use send/receive
for incremental backups. This also requires a Btrfs or ZFS volume on
your backup server if you wish the snapshots to stay integrated (IIRC
this is a requirement for ZFS anyway).

>
> I need some reasonable assurance that data corruption on disk has a
> very low probability. I need some reasonable assurance that the
> operating system (the combination of Xen and dom0) is stable.

The best assurance is regular backups. I don't know what caused your
glitch but I've had vanishingly few on Qubes myself since 2013.

However, Qubes does require the use of snapshot-capable storage for
reasonable efficiency and this is not yet Linux' strength.

Between Thin LVM (Qubes default) and Btrfs storage options my experience
tells me that Btrfs is actually the more reliable system, as it can
survive system crashes even better than plain ext4; Storage integrity is
a core goal of Btrfs so this is expected. Another option that offers
high integrity is ZFS for which a Qubes guide exists.

-

I hope this response helps you out some. Right now Qubes appears to be
in a state that's mostly suitable for "security techies"; There is
certainly room for improvement and your critique has made me think that
some new issues need to be opened to help address the usability issues.

--

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

Mike Keehan

unread,
Mar 16, 2019, 8:42:58 AM3/16/19
to qubes...@googlegroups.com, jrg.p...@goold.net
On Fri, 15 Mar 2019 21:31:02 -0500
John Goold <jrg.d...@gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> *A Critique of Qubes*
>
Hi John,

What a nice read, thank you. I have a very similar background, and age,
so I was very interested to read your story.

I've been using Qubes now for a few years, and love it. Have had very
little problem with it; have used and restored using the builtin backup
scheme; and have updated without problem using just the normal,
stable repositories.

The one thing I can suggest that I do differently to you, is that I
power down my laptop, and boot up afresh each day. Have always done
this during my professional life (wasn't any choice early on as there
was no suspend option), and I can say that I have not experienced any
of the launch issues you described, nor any copy/paste issues between
VMs, not that I do much of that.

As for Flash, it is a pain. Our BBC still uses it extensively, so I
have to manually download it occasionally and copy the library file
into the appVMs .mozilla directory when necessary.

Anyway, best of luck,

Mike.

John Goold

unread,
Mar 16, 2019, 10:04:24 AM3/16/19
to Mike Keehan, Qubes Users Google-Groups
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 3/16/19 7:42 AM, Mike Keehan wrote:

>
> As for Flash, it is a pain. Our BBC still uses it extensively, so
> I have to manually download it occasionally and copy the library
> file into the appVMs .mozilla directory when necessary.
>
Hi Mike,

What a coincidence! I live in Canada, but use the BBC website on a
daily basis for news and interesting articles. It is really the
only reason I need Flash.

Cheers,
John
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEe8Wcf7Po7bts2Rl4jWN9/rQYsRwFAlyNAl0ACgkQjWN9/rQY
sRwJNAf7BWyeG2BfTKJTSFFjTafLrv384+foZ3D1SVEQ587GSaGr8xReuxa8pbaw
Vz4qb0+BnMgr7jQ9audWijZWmhwJGx/IuLmUxbrKfQ2s6RhvvKCeBWox9oWrsT5p
Lh9J8Ek3QCNStSFNPhIqUT3dXLouYeQ3LQCzXbNafV4HTMyvMzmNkkGKZnWmdnIm
45TiHzx1jiRLH30VjgtSgD55QEyGzi6bMPjIK/n9IdQrgmN/evvvF7PSWsQiE3au
C6SyH9RBhfPAzHYY6gopbUcbr2R7sYUugIlu6cA25O0av5vzX+wxxV0ZrwIqvAOq
w5HuvElorhVHTAbEjR22brJZVtnZBA==
=J3rz
-----END PGP SIGNATURE-----

airele...@tutanota.com

unread,
Mar 16, 2019, 1:17:20 PM3/16/19
to Qubes Users



Mar 16, 2019, 2:31 AM by jrg.d...@gmail.com:
Issues...

* When launching a program from the Qubes menu, particularly if the
target appVM has to be started, the program often fails to be
launched. This happens very frequently with the Text Editor.
Interesting, my experience is limited to mostly debian-based templates and for those, the only program that fails to start from the menu is gnome-terminal.
Since I had been using Linux distributions based, directly or
indirectly, on Debian, when I first set up Qubes, I created my appVMs
based on Debian. That was painful as I then had to install a lot of
basic software.

When I re-read the documentation, I realized the security reasons,
so I switched all my appVMs (except one!) back to Fedora. It was not
painful, but I would have rather have spent the time doing something
else.

I've never come across guidance favoring Fedora over Debian in the docs. Can you provide a link?
Since Firefox and Flash were working fine on my Linux Mint laptop
(which I use "to play with"), I re-based my untrusted appVM on Debian
and, lo and behold, Firefox and Flash worked just fine. This, by the
way, was when I attempted to use Chromium.
This is how I used to get flash working too - chromium + some flash plugin on a debian-based appvm. Thankfully flash is dying and I don't need it anymore.
At least for some people, it seems Debian is a necessity, but it is
not given the attention it deserves. At a minimum, a GUI software
installer should be included in the Qubes distribution which would
make it much easier for people to install other software they feel
inclined to use.
I think the policy is that Qubes defers to the distro. So if the distro doesn't have a GUI installer, than the template won't, and it sounds like it would be out of scope for Qubes to provide a GUI installer.

On the flip side, if the distro has an optional GUI package manager, it should work. For example, for debian, have you tried installing synaptic in the template?
* Screenshot only appears to work from Qubes Tools. I can "add"
"Screenshot" to appVMVs based on Fedora (but not on Debian). But it
does not work -- The dialog comes up but, having chosen to select an
area, I cannot do so.
Subsequent attempts to use Screenshot do not even present a dialog.

Although I have not seen this documented anywhere (which does not
mean it is not), it seems logical -- dom0 owns the screen (monitor),
so it makes sense that it handles screenshots. However, that means
screenshots are saved in dom0 and have to be moved (or, I suppose,
copied) to the desired appVM. It seems a bit awkward. If one is in a
program in an appVM and decides a screenshot would be nice, it is
probably focussed on that window or a portion of it. Since the OS
displaying the window "knows" what it is displaying, it seems logical
that some kind of screenshot could be made by that OS, but restricted
to its window.
It *would* be nice if you could right-click a file in dom0 and send to VM using the VM picker. Useful for screenshots and log files, for GUI-inclined users.

Andrew David Wong

unread,
Mar 16, 2019, 1:39:30 PM3/16/19
to Chris Laprise, jrg.p...@goold.net, Qubes Users Google-Groups
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Thank you, John, for sharing your thoughts with us, and thank you,
Chris, for taking the time for a detailed reply. I'll offer what I can
on just a few points.

On 16/03/2019 6.31 AM, Chris Laprise wrote:
> Hi John,
>
> That's an interesting background and list of wants. I've been using
> Qubes for some time and can try to address a few of your issues.
>
> [...]
>
>>
>> The kicker came when Firefox stopped playing Flash content in my
>> untrusted appVM, complaining that I needed an up to date
>> version of Flash. I installed the most recent version, but that
>> did not solve the problem. The problem is/ was something to do
>> with Fedora (or the version of Firefox for Fedora or ??).
>
> I haven't used Flash in a long time so I can't help there. In
> general its best to find an alternative that doesn't rely on
> Flash, which is becoming a dead format. Typically Flash is replaced
> by HTML5 web apps (and most websites have made this switch
> automatic).
>

You might want to try the Google Chrome browser for this. (You may
need to enable its built-in flash functionality if it's disabled by
default.)

> [...]
>
>> My Bottom Line:
>>
>> I can live with most of the issues described above. What I
>> cannot live with (and worry about) are stability and reliability
>> issues.
>>

I, too, am primarily concerned about stability and reliability (after
security, of course).

> [...]
>
>>
>> I need some reasonable assurance that data corruption on disk
>> has a very low probability. I need some reasonable assurance
>> that the operating system (the combination of Xen and dom0) is
>> stable.
>

In my experience, the probability of data corruption on disk is no
higher (and perhaps even lower) on Qubes than on other more
conventional operating systems. The only kind of instability I've
experienced infrequently in the past on Qubes were crashes (e.g.,
spontaneous reboots), but I've never had any lost or corrupted data on
disk from such events. I've also experienced plenty of BSODs on
Windows, so I think Qubes is batting pretty well on stability.

> The best assurance is regular backups. I don't know what caused
> your glitch but I've had vanishingly few on Qubes myself since
> 2013.
>

I agree that backups are the best assurance, but this is in no way
Qubes-specific. I'd say the same thing about any operating system.

> However, Qubes does require the use of snapshot-capable storage for
> reasonable efficiency and this is not yet Linux' strength.
>

Here's where Chris and I disagree. I've been using Qubes' built-in
backup functionality for many years to great effect. Granted, I
usually run it overnight, so time and system load aren't concerns for
me. It just depends on your needs.

> [...]
>
> I hope this response helps you out some. Right now Qubes appears
> to be in a state that's mostly suitable for "security techies";
> There is certainly room for improvement and your critique has made
> me think that some new issues need to be opened to help address
> the usability issues.
>

Agreed. I think that many of us have been motivated to become
"security techies" by our desire to use Qubes. This isn't a bad thing
in itself (it's good to learn new skills), but we don't want it to be
a requirement either.

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

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

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlyNNKgACgkQ203TvDlQ
MDBuaBAAiaf05nx3+JYRaVibrmofz+8/auIs3xdHkEI0pXrAlKEg6+Q98k6lnnrw
SdK+vnGl249aINJI7uJ5swx6zK+rsCR1rXp25lBT6AFpwfTefbXrIcMVcuXGfj8F
XTWiyeb2Tw5ooKfrbYuXGTtrN9O4OQ/q5/r9GY2oSsj3/lf8KiMH7KkxFbgLMSUh
oCrZ2BrmvpqFm90paB4C4nqCfe/2HTDKjcIHSL01H0FfAhhGp0hLymwQtpVy0atr
80OKQc0LDc0i/w6tIhDQfWDVVAThVyEYF15tSUNDi6eE9BvNqijrN0zYs+La5pTS
AS1Cy1DHdO/ksM0U/083LDo592oKvHdME0XggbBwBVamLvp8wcf4qaLqy83XDbuR
1EgWaPoB5Y8xmQptPJd9ZV93do3p0MuYnpzU+JM6a6U02gW1DQA6apFMvPotxYYE
s9djUGQ7b13R+udbfDqVebrnlf5f+OovZJvZgdQI2gKOMBXe9ZfKAMH1zH8tDcyc
i15diwQ5tSjk70Fiiw/knrxtNDVcHnF/bFq1vQirAsSCCLQvS8CMue4zDzBOSvND
5OPCTdW5VXm7ieCoT+K2uHq+bVdqIf8vzBf67bkG+m1RXBnXLZvnSUbkgPWeBD2N
kbvgpBoKUVRoDi5q42EDVuPZ/M0h2sQPqUZZSTsQxETh7JiAg70=
=zU1k
-----END PGP SIGNATURE-----

Chris Laprise

unread,
Mar 16, 2019, 6:23:15 PM3/16/19
to Andrew David Wong, jrg.p...@goold.net, Qubes Users Google-Groups
On 3/16/19 1:39 PM, Andrew David Wong wrote:
> I agree that backups are the best assurance, but this is in no way
> Qubes-specific. I'd say the same thing about any operating system.
>
>> However, Qubes does require the use of snapshot-capable storage for
>> reasonable efficiency and this is not yet Linux' strength.
>>
>
> Here's where Chris and I disagree. I've been using Qubes' built-in
> backup functionality for many years to great effect. Granted, I
> usually run it overnight, so time and system load aren't concerns for
> me. It just depends on your needs.

I was probably too vague here. The idea was that, apart from the issue
of backups, storage integrity on a Linux COW layer (Thin LVM, Btrfs)
isn't regarded as top-notch. But I think this is more true of Thin LVM
than Btrfs. Someone wishing to guard against data loss on their
Qubes+Linux system in the first place (which seems to be an issue for
John) could be excused for thinking their options are not the best.

js...@bitmessage.ch

unread,
Mar 16, 2019, 7:35:20 PM3/16/19
to qubes...@googlegroups.com
Hi John,

John Goold:
> * When launching a program from the Qubes menu, particularly if the
> target appVM has to be started, the program often fails to be
> launched. This happens very frequently with the Text Editor.
>
> This is annoying as one waits a bit in case one is simply being
> impatient, or at least I do, so as not to launch two copies of the
> program by accident.

I experience that too on debian (i don't use fedora appvms). As Chris
said it's a longstanding bug with gnome apps like nautilus and gedit.

Actually i much prefer the nemo window manager, i think it's great and
much better than nautilus (dolphin works too but i don't like it as
much). You can install whatever window manager you want in the template
and use it in your appvms.

By the way does anyone know how to add the qubes specific functions
(move/copy to vm, open in dispvm) to the context menu in nemo? It would
be nice to not have to switch to nautilus for those functions (i know i
can use cli for it too tho).

> * Ignoring whonix (I do not use it... yet), there are two template VMs
> in the vanilla Qubes 4.0.1 installation: Fedora and Debian. However,
> they have not been treated equally, with Debian being the loser. The
> Qubes documentation indicates that Fedora was favoured for security
> reasons.

I'm also not sure about this. My understanding is that debian is
actually better than fedora from a security standpoint because of how
updates are done (fedora updates being more vulnerable to man in the
middle attacks).

> At least for some people, it seems Debian is a necessity, but it is
> not given the attention it deserves. At a minimum, a GUI software
> installer should be included in the Qubes distribution which would
> make it much easier for people to install other software they feel
> inclined to use.

I'm not sure about the default debian template in 4.0, but i remember
the default debian 8 template in 3.2 had a gui package install/update
tool (labelled "Packages" or "Package Updates" or something like that).
I remember using it a few times, but i mainly just use cli to install
software.

If the new debian template doesn't have that by default, as airelemental
said you can install one.

> Using Linux and now Qubes, I not only do not shutdown the computer
> (i.e. power-off), but I do not logout -- I simply "Lock the Screen"
> and power-off my monitor.

I do the opposite, i reboot every day, and i never had any problems with
copy and paste between qubes, and i very rarely have other problems like
crashes. I would at least reboot after installing dom0 updates.

> [Question] So, what do other Qubes users do to protect their families
> in case they die/get killed, get imprisoned, go missing?

In addition to (very) occasional full backups using default qubes tools,
i also backup important data to an external hard drive with a luks
encrypted partition, so it can be easily accessed outside of qubes if
needed.

--
Jackie

John Goold

unread,
Mar 16, 2019, 8:43:06 PM3/16/19
to Qubes Users Google-Groups
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 3/16/19 6:35 PM, js...@bitmessage.ch wrote:
>
>> [Question] So, what do other Qubes users do to protect their
>> families in case they die/get killed, get imprisoned, go
>> missing?
>
> In addition to (very) occasional full backups using default qubes
> tools, i also backup important data to an external hard drive with
> a luks encrypted partition, so it can be easily accessed outside of
> qubes if needed.
>
But that still needs someone (spouse, child, executor of your estate) to
have access to a key phrase (if that is the right term). What about
bank account numbers, etc. If you use KeePassX 2 or similar, what about
access to it?

Do you have the necessary passwords written down with instructions,
sealed in an envelope and stored in a safety deposit box? Something
else?

We tend to keep more and more financial, legal and medical information
on our personal computers rather than keeping paper copies (I am an old
guy but my wife and I keep everything in electronic form unless
required by law to keep a paper copy -- so I expect the "younger" crowd
probably tends to do so as well).

We keep at least two backups of such data -- copies to our shared file
server and backups to external drives.

One of our children has the master password to our password vaults --
there is a non-negligible possibility that both of us could be badly
hurt (or killed) in the same accident (e.g. plane or car crash).

Anyway, with our emphasis on Qubes and security, I was curious about
this other aspect of people's affairs. Do you have all your important
data locked down in Qubes so *only* you can get at it?

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

iQEzBAEBCAAdFiEEe8Wcf7Po7bts2Rl4jWN9/rQYsRwFAlyNmBMACgkQjWN9/rQY
sRyUAwgAggvJpp6yKTRGfsM+W3EmkAb/nS/reESCCFbyifgFgqr5b2IWclFzZyAi
Nra9Q3KiuCaj4rS4YduTE0HcEsFKNoj9fY/mkS+EalriIhyw4DWMeoupZ/q4Nun1
7pbLiPKDhJAccLo1ZNEsQQYpgGnUhUMeR3hFhdawgerss9TASt8lInmnfTNrp9ei
uv5l7LOc/sAgy0yEvqYqxJFKIA70xgThK/SWHcqwQx02TX5LCAPXAtM4VFNAw08U
BbL+wNUp8c/FcZ2dELtH2iy2Hyraj11b2UCDh7QXv/Uih6358hqkfIT+PZWpyVJq
DpLe09Ef5FuWltS4HGVqvDJl+4kjKg==
=urg+
-----END PGP SIGNATURE-----

js...@bitmessage.ch

unread,
Mar 18, 2019, 1:17:01 AM3/18/19
to qubes...@googlegroups.com
John Goold:
I'm the only one who can get into my qubes box. Actually i've been
thinking about it since you started this thread but i'm not sure of the
best way to solve that problem of giving someone trusted access to
important data if needed. i've neglected that so far (i guess i've been
pretending i'm immortal?)

Anyways, first it has to be someone i really trust, since there really
isn't a good way to make sure they have access after i die but they
don't have access before (although maybe something like that could be
worked out with the safe deposit box you mentioned?)

And second is the problem of preventing access by people other than the
trusted person. I can write down a passphrase for them and put it in an
envelope, and tell them don't open it unless i die, but then my
passphrase is written down and anyone who gains access to the envelope
can get access to my important data.

And third is the problem that the only people i *really* trust are
probably going to die before i do, but that's not exactly a technical
problem..

Anyways, if you have a keepassx database you can just put it on a flash
drive or some other storage since the database file is encrypted, but
anyone you want to access it will still have to have a passphrase either
way.

--
Jackie

Stuart Perkins

unread,
Mar 18, 2019, 10:11:40 AM3/18/19
to qubes...@googlegroups.com


On Fri, 15 Mar 2019 21:31:02 -0500
John Goold <jrg.d...@gmail.com> wrote:

Welcome to Qubes. I've been using it about a year, and I'm still on 3.2. I have a motherboard issue with my laptop, and have another one to replace it with...just haven't taken the time yet. USB ports are non functional on this one, and I want them to work before going to 4.? I am running a Lenovo T520 with the open source bios burned onto it to eliminate the Intel ME. My replacement board has the BIOS burned, but I haven't taken the time to re-install it yet.

My setup and backup routine is as follows:

I have kept my "important" information in a Luks Encrypted container for some time now, pre-dating my Qubes use. I went Linux on my laptop back in '08, and went to whole disk encryption shortly after that. When I went with Qubes, I modified it for performance reasons where only the important data is actually encrypted. My Qubes laptop has the main OS drive encrypted (160GB SSD) but the extra space is not (2TB HDD) and most of my user data is on VM's with their drive space on the HDD for size reasons. On Qubes, there are two VM's of concern.

One is "mail", where I gather all of my e-mails (28 or so of them) with claws-mail (stores as discrete files, so recovery/search is possible without a specific program..I've used this since I've been on Linux, and I converted my old Outlook database to it so I have e-mails literally 30 years old).

The other is "money", where I keep a Dosbox Ryan-McFarland Cobol system I wrote in the 80's for my personal bank account records and GnuCASH for my business records.

I also run the delivered "vault" VM with keePassX (and NO network connection) where I have all of the various accounts and passwords recorded. It is not by default included in the encrypted backups, but I keep a recent copy of the data file with my "money" records too.

Scripts back these up to a copy of the Luks container on my home server as often as I run them, which is at least daily, or more often. My home server is a Debian server (no GUI/DE) running a small number of VirtualBox VMs for different things. I do have a static IP at home since I host my own web page for my farm (Drupal in a VM) which makes connecting home simpler than a dynamic IP.

I am creating a "Doomsday.doc" document with instructions on how to run my laptop in the event of my incapacitation/demise. While I don't expect my wife or other survivors to continue to use my setup, at least they can get to all of the logins as needed to finalize bank accounts and bills, crypto currency wallets etc...

Once I am happy with the document, I will print it and put it in my safe at home. If I had assets, I would include it with a will at an attorney's office, but I'm pretty much medically broke right now trying to make sure one of my children actually survives me. Making medical history is expensive.

I have had zero issues with the stability of Xen, Dom0 or the data storage on Qubes 3.2...but...I am not doing logical volumes. I may delve into that when I do the 4.x install, but I may not as well as it is an additional failure point as far as I'm concerned. The main justification is to be able to add drives and therefore space without having to completely copy everything, but I'm not dealing with 10's of TB's of data either.

Anyway, it is good to see another old Mainframe guy using Qubes. It is almost like running an entire datacenter on your laptop. I got my start with the PC's before they were called "PC's" with the Ryan-McFarland stuff, then jumped over to the Mainframe world for a while...enduring the "upgrade" from VS Cobol to VS Cobol II...dabbling with IMS, IDMS and DB2 with a little ALC programming thrown in for good measure. I've been pretty much exclusively working with the Lawson ERP for the last 20 years. The one thing I miss with Qubes is the fact that my old copy of ISPFPC (4.0) won't run with Xen. :)

jrsm...@gmail.com

unread,
Mar 18, 2019, 11:40:36 PM3/18/19
to qubes-users
“The install appeared successful. I was able to add
Chromium to an appVM. When I started the appVM and launched Chromium
from the menu... nothing! No window, no error message. I tried a number
of times (the reason for just re-trying will be mentioned below). ”

This stood out for me and was not addressed by others, so I’ll ask the obvious question. Did you install the software in the appVM as you stated or did you install in the template VM the appVM was based on? For most installed software, it needs to be installed in the Template VM for it to be there after the appVM is bounced. Installing in the appVM causes the install to be lost on the next reboot of that appVM since it gets its installed software from the Template. I usually clone the distro templates and install my stuff there and then create appVMs with my copies. That way I can be sure that the distro templates remain upgradable via QM.

John Goold

unread,
Mar 19, 2019, 10:17:32 AM3/19/19
to jrsm...@gmail.com, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

In the template. Used the Qubes Manager to "add" Chromium to the
appVM's menu.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEe8Wcf7Po7bts2Rl4jWN9/rQYsRwFAlyQ+fEACgkQjWN9/rQY
sRxddgf+N2OOb0ktEzhJzi1PvwYw12Ui6KKyhBucowacBqekRAWoiDYnMNyPlbS0
xnoZrc0gFEo++HXmmduuyrodD66chkntvdBhYmJ/n4bb1XmzOCaInBeLxghvI1xX
rNMRHFMJTBL56syTmK8gRa5yvujMr9JCAig+q7AP4wrZo3xdfUZUIhZnF0wC2XNC
Z2M0+Gotlbm2PBfpuAEGIK49Z9q1n1UuUP9WLVoHkVJoJ+jr/tJ2wLsC+QyfCYKr
dAtHHVgiv0RKNw7bxtq3M8iSE9CnXqqtP830yHuTbVrZ+m+zJMP/rfGFDiEp9ZAK
yZ4rR1Qi0E0jA5hkOs1k3lx4ZqOgLw==
=CWNi
-----END PGP SIGNATURE-----

jrg.d...@gmail.com

unread,
Mar 30, 2019, 8:18:06 PM3/30/19
to qubes-users
Chris mentioned:

"The current Firefox ESR does have a tendency to freeze temporarily when
memory gets low. I'm considering switching to the non-ESR 'firefox'
package in Debian to see if the newer versions are better in this respect."

My computer (Intel NUC7i7) has 32 GB RAM, so I doubt I am having low memory issues -- but I suppose with my tendency to open a lot of tabs, it could happen.

I finally got around to trashing the ESR version of Firefox and installing the latest "regular" release. It is too early to tell (less than a day), but I have not run into a problem yet (I had been running into the problem at least once or twice a day).

Marc Griffiths

unread,
May 10, 2019, 11:19:14 AM5/10/19
to jrg.d...@gmail.com, qubes-users
Hi everyone. Nice critique John. To throw in my perspective as an experienced Linux user switching to Qubes as sole laptop OS a few months back. Primary usecase for me is #1 increased security when using crypto exchanges and #2 the feeling of spinning up an environment that I have confidence in being private, for the writing of personal notes and reflections.

The concept is awesome, perfectly designed for protection against malicious applications, websites and devices. Although it offers no protection against Intel Management Engine.

My experience of installing on a Lenovo Yoga 720 was seamless, everything worked including the touch screen. However, I experienced a lot of random browser crashing. Chromium dead birds on a fairly regular basis. Vivaldi, Chromium, and Firefox browser windows disappearing without error, on both Fedora and Debian. Upgrading to Fedora 29, and upgrading dom0 didn't resolve the problem. A few times the desktop became unresponsive, and while I was able to ctrl+alt+F2 to dom0, it wasn't clear how I could view processes running on a particular VM.

I'd be interested in knowing what audience Qubes is aimed at. With the rapidly increasing public awareness on cyber-security and privacy, Qubes could very easily find itself in high demand. At present though it's only going to appeal to experienced Linux users, which is a shame, because it wouldn't be that much work to make it far more accessible.

If the Qubes team is interested in a larger audience, I would suggest:
  • Include Ubuntu based VM as default, or at least make the process of adding a Ubuntu template significantly easier
  • Include a brief getting started guide that covers essentials such as cross VM copy/paste, accessing devices, upgrading software etc
  • If we're limited to XFCE, then include guides on customising to be more like other environments. Most critical for me was adding shortcuts for switching desktops and moving windows between desktops: System tools > Window Manager > Keyboard
  • A guide on the limitations: what does Qubes protect you from, what does it not protect you from, what are the next steps to improve security. Having a colour-coded grid to communicate this would be excellent.
Next step for me is ordering a T400, which doesn't have Intel Management Engine, supports Libreboot, and has proven itself as an uncrashable workhorse. I used to run Windows and SUSE on this laptop back in 2008-2011, it never crashed, despite running a complex J2EE dev environment. I will miss having 16GB RAM, but the i7 I can happily part with.

Marc Griffiths 

--
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.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9fbf11f4-2ca3-45f5-ba11-b708b405ba3a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Chris Laprise

unread,
May 10, 2019, 2:09:09 PM5/10/19
to Marc Griffiths, jrg.d...@gmail.com, qubes-users
On 5/10/19 12:16 PM, Marc Griffiths wrote:
> Hi everyone. Nice critique John. To throw in my perspective as an
> experienced Linux user switching to Qubes as sole laptop OS a few months
> back. Primary usecase for me is #1 increased security when using crypto
> exchanges and #2 the feeling of spinning up an environment that I have
> confidence in being private, for the writing of personal notes and
> reflections.
>
> The concept is awesome, perfectly designed for protection against
> malicious applications, websites and devices. Although it offers no
> protection against Intel Management Engine.

There is much more to low-level vulnerabilities than IME: PortSmash,
Foreshadow, Rowhammer, etc. Overall, AMD processors appear to be less
vulnerable than Intel.

>
> My experience of installing on a Lenovo Yoga 720 was seamless,
> everything worked including the touch screen. However, I experienced a
> lot of random browser crashing. Chromium dead birds on a fairly regular
> basis. Vivaldi, Chromium, and Firefox browser windows disappearing
> without error, on both Fedora and Debian. Upgrading to Fedora 29, and
> upgrading dom0 didn't resolve the problem. A few times the desktop
> became unresponsive, and while I was able to ctrl+alt+F2 to dom0, it
> wasn't clear how I could view processes running on a particular VM.

Sorry to hear about the stability issues. You might try updating your
UEFI firmware to see if that helps.. the precise way that it configures
advanced hardware features (seldom used by other operating systems) does
have an impact on both compatibility and stability. This is also a good
reason to stick with business-oriented computers because vendors take
more care to get advanced features working correctly on them; its one of
the reasons why Thinkpads are so popular among Qubes users.

>
> I'd be interested in knowing what audience Qubes is aimed at. With the
> rapidly increasing public awareness on cyber-security and privacy, Qubes
> could very easily find itself in high demand. At present though it's
> only going to appeal to experienced Linux users, which is a shame,
> because it wouldn't be that much work to make it far more accessible.
>
> If the Qubes team is interested in a larger audience, I would suggest:
>
> * Include Ubuntu based VM as default, or at least make the process of
> adding a Ubuntu template significantly easier
> * Include a brief getting started guide that covers essentials such as
> cross VM copy/paste, accessing devices, upgrading software etc
> * If we're limited to XFCE, then include guides on customising to be
> more like other environments. Most critical for me was adding
> shortcuts for switching desktops and moving windows between
> desktops: System tools > Window Manager > Keyboard
> * A guide on the limitations: what does Qubes protect you from, what
> does it not protect you from, what are the next steps to improve
> security. Having a colour-coded grid to communicate this would be
> excellent.

You're not limited to XFCE, and in my experience KDE works better.

>
> Next step for me is ordering a T400, which doesn't have Intel Management
> Engine, supports Libreboot, and has proven itself as an uncrashable
> workhorse. I used to run Windows and SUSE on this laptop back in
> 2008-2011, it never crashed, despite running a complex J2EE dev
> environment. I will miss having 16GB RAM, but the i7 I can happily part
> with.

I doubt that Qubes will install or run on a T400. Qubes was initially
developed on Sandy Bridge-era hardware, and the requisite virtualization
features in chipsets was still maturing up to that point.

I feel obliged to mention that if you want to avoid management engines
and a raft of other processor vulns, you should look to the AMD 15h
generation of chips (circa 2013). In the form of a Lenovo G505s A10,
installing Qubes first requires re-flashing the firmware with
Coreboot... an exercise that I'm about to try. :)

David Hobach

unread,
May 11, 2019, 2:12:32 AM5/11/19
to Chris Laprise, Marc Griffiths, jrg.d...@gmail.com, qubes-users
On 5/10/19 8:09 PM, Chris Laprise wrote:
> On 5/10/19 12:16 PM, Marc Griffiths wrote:

>> My experience of installing on a Lenovo Yoga 720 was seamless,
>> everything worked including the touch screen. However, I experienced a
>> lot of random browser crashing. Chromium dead birds on a fairly
>> regular basis. Vivaldi, Chromium, and Firefox browser windows
>> disappearing without error, on both Fedora and Debian. Upgrading to
>> Fedora 29, and upgrading dom0 didn't resolve the problem. A few times
>> the desktop became unresponsive, and while I was able to ctrl+alt+F2
>> to dom0, it wasn't clear how I could view processes running on a
>> particular VM.
>
> Sorry to hear about the stability issues. You might try updating your
> UEFI firmware to see if that helps.. the precise way that it configures
> advanced hardware features (seldom used by other operating systems) does
> have an impact on both compatibility and stability. This is also a good
> reason to stick with business-oriented computers because vendors take
> more care to get advanced features working correctly on them; its one of
> the reasons why Thinkpads are so popular among Qubes users.

The browser stuff sounds more like memory issues to me (not enough
memory assigned to disposable VMs).

I can confirm the ctrl+alt+F2 desktop issue with awesome WM as well.
Usually it became responsive after going back from the console to the WM
though.
This was "introduced" ~3 months ago or so; I guess it's a well hidden
bug, possibly not a Qubes one.

> You're not limited to XFCE, and in my experience KDE works better.

And awesome, i3, ... But yes, KDE was even standard with Qubes 3.

brenda...@gmail.com

unread,
May 20, 2019, 8:58:26 AM5/20/19
to qubes-users

As much as is really quantifiable...what percent of the real-world risk of the Intel ME to end-user is related to the fact that the manufacturer-whitelisted networking chipsets are directly usable by the firmware, primarily in support of the AMT feature set (and anything remotely hijacking via AMT, potentially without local compromise)?

Which is to say: isn't one important mitigation of remote pwnage the disabling and/or removing (as appropriate) of the manufacturer-supplied network connections? Without a custom firmware, one can always use a USB-based wifi/ethernet connection..and with custom firmware (when possible) you can bypass the hardware whitelist and supply your own third-party wifi/bt card that the local AMT portion of the firmware has not been designed to talk to.

Brendan

Marc Griffiths

unread,
Jun 27, 2019, 8:11:34 AM6/27/19
to brenda...@gmail.com, qubes-users
Thanks for your input Brendan, David, Chris.

Having switched to KDE, the laptop is now completely stable, and in my opinion far more usable than XFCE.

I'm also running Trisquel on a Thinkpad X200 flashed with Libreboot, which feels more secure although requires more care over choosing what to install. I would be keen to see a laptop that supports Libreboot and is powerful enough to run Qubes.

What are your thoughts on LXD? Lightweight enough to run on an X200/T400, although of course not offering the same compartmentalization as XEN, sharing the same kernel etc

[and yes something can 'feel' more secure, insight deeper into the stack results in more trust]

Marc Griffiths
marc.d.g...@gmail.com


--
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.
To post to this group, send email to qubes...@googlegroups.com.

Sphere

unread,
Jun 28, 2019, 3:19:04 AM6/28/19
to qubes-users
About corruption and reliability of data being stored, regardless of whether or not it is sensitive data or day to day files, is not entirely the responsibility of the Qubes OS itself. There are many factors to consider, the software being used, the filesystem being used, the components of the distro being used, and etc.

This is based on my personal experience on using qubes on a daily basis for almost over a year already.

So far I've only encountered corruption of data through the use of qvm-copy/qvm-move commands to move stuff from vm to vm and this is a rare case too since it probably only happens once or twice over a hundred times. With this in mind, the LVM thin fs of Qubes I believe, is extremely reliable.

So with that I believe the problem most likely leans more towards the software that you are using, with respect to the distro that you are using as well.

I haven't had much trouble using any software so far in my experience of using qubes provided they have the right dependencies installed, with respect to my usage of fedora minimal template.

Despite that however, I agree with your sentiment about USB devices and the detaching notification though I am not entirely dependent on it since I can go ahead and confirm myself whether or not the usb device was detached by running "sudo lsblk" on the qube where the USB was attached and on the sys-usb qube itself. Convenience-wise, it is bad yes and there is definitely room for improvement.

Also mind you that flash is a HUGE BLOB of SECURITY RISK. If you're using qubes for security reasons then using flash is really counterproductive against it not unless you really know what you're doing.

Reply all
Reply to author
Forward
0 new messages