Security Best Practice: Cache web passwords in custom VM's or not?

[Cube]

Assume you have a disconnected Vault VM with your passwords, and a Shopping VM where you access Amazon, etc. Highest security is to copy/paste passwords over from the Vault as needed. Less secure (but still highly secure) is to cache them in the Firefox database.

What path do people generally take?

[Alex]

As far as I am concerned, it heavily depends on the type of passwords.

For example, I have zero problems in saving the passwords for my test
web application endpoints in the browser. The test web applications are
online only as long as the debugger is active, they are accessible only
from localhost, they are connected to a test database (i.e. no
interesting data) and it would be a major PITA having to type the
passwords again and again.

For specific services (say, the mentioned Amazon) I keep a keepassx
database on the specific AppVM in which the service is expected to be
used - the Amazon account I use to buy work stuff is saved in the
keepassx database in the Work appVM, the personal one is saved in the
personal appVM.

And there are some types of password I keep in a non-internet-connected
AppVM, together with some OTP generator scripts. They are meant to be
used for targets that may be sensitive to large scale attacks (say, home
banking credentials, amazon AWS otp generators, etc.) where attackers
may have the financial power to aggressively attack the target AppVM -
so my line of defense here is to be sure not to have the sensitive
information available on the filesystem at all.

--
Alex

[Cube]

On Saturday, August 27, 2016 at 9:31:31 AM UTC-7, Alex wrote:
> On 08/27/2016 05:59 PM, Cube wrote:
> For specific services (say, the mentioned Amazon) I keep a keepassx
> database on the specific AppVM in which the service is expected to be
> used - the Amazon account I use to buy work stuff is saved in the
> keepassx database in the Work appVM, the personal one is saved in the
> personal appVM.

Interesting idea. For the downside of having to remember extra passwords (for the databases), backups (albeit part of the general backups), and managing the running instances of XKeyPass, you can save a few keystrokes pasting between VM's. It does seem like there are more disadvantages, why not just keep them together in one Vault XKeyPass?

> And there are some types of password I keep in a non-internet-connected
> AppVM, together with some OTP generator scripts. They are meant to be
> used for targets that may be sensitive to large scale attacks (say, home
> banking credentials, amazon AWS otp generators, etc.) where attackers
> may have the financial power to aggressively attack the target AppVM -
> so my line of defense here is to be sure not to have the sensitive
> information available on the filesystem at all.
>

Well they're in the AppVM though so are on the filesystem, aren't they? What you buy is network isolation, effectively air gapping, but even better.

[Alex]

On 08/27/2016 07:36 PM, Cube wrote:
> On Saturday, August 27, 2016 at 9:31:31 AM UTC-7, Alex wrote:
>> On 08/27/2016 05:59 PM, Cube wrote: For specific services (say, the
>> mentioned Amazon) I keep a keepassx database on the specific AppVM
>> in which the service is expected to be used - the Amazon account I
>> use to buy work stuff is saved in the keepassx database in the Work
>> appVM, the personal one is saved in the personal appVM.
>
> Interesting idea. For the downside of having to remember extra
> passwords (for the databases), backups (albeit part of the general
> backups), and managing the running instances of XKeyPass, you can
> save a few keystrokes pasting between VM's. It does seem like there
> are more disadvantages, why not just keep them together in one Vault
> XKeyPass?

I see, this may be a personal preference. Me being obsessed with
architectural research, I like to explain this with "isolation". Actual
benefits may be that I can share the personal keepassx database with
another device with simple tools, say - the laptop I use to only watch
cat videos on youtube when I'm done at the workstation.

>> And there are some types of password I keep in a
>> non-internet-connected AppVM, together with some OTP generator
>> scripts. They are meant to be used for targets that may be
>> sensitive to large scale attacks (say, home banking credentials,
>> amazon AWS otp generators, etc.) where attackers may have the
>> financial power to aggressively attack the target AppVM - so my
>> line of defense here is to be sure not to have the sensitive
>> information available on the filesystem at all.
>>
>
> Well they're in the AppVM though so are on the filesystem, aren't
> they? What you buy is network isolation, effectively air gapping, but
> even better.

It depends on the point of view; yes, they are on the same dom0
filesystem, but they are on different filesystems from the AppVM's point
of view. May as well be on another machine, or another universe, if Xen
isolation keeps.

I may have poorly expressed myself in the quoted paragraph; the "target
AppVM" can be one of the internet-facing AppVMs, like the Banking or
Work or Personal ones, while the one I keep the sensitive passwords on
is like a VaultVM from your original message.

--
Alex

[johny...@sigaint.org]

> On 08/27/2016 07:36 PM, Cube wrote:
>> On Saturday, August 27, 2016 at 9:31:31 AM UTC-7, Alex wrote:
>>> On 08/27/2016 05:59 PM, Cube wrote: For specific services (say, the
>>> mentioned Amazon) I keep a keepassx database on the specific AppVM
>>> in which the service is expected to be used - the Amazon account I
>>> use to buy work stuff is saved in the keepassx database in the Work
>>> appVM, the personal one is saved in the personal appVM.

BTW, keepassx rocks. I'm working on some scripts to make it a little less
painful with all the Ctrl-Alt-C and Ctrl-Alt-V'ing (which also conflicts
with the standard konsole paste shortcuts).

Using keepassx on Tails is so much more streamlined, without the extra
level of copying/pasting. It'd almost be nice if there were some explicit
dom0 support for it somehow.

While it'd be more convenient to put keepassx in the same VM as your main
browser, keeping keepassx in a network-less vm makes so much more sense.

(Some day, true feature-by-feature access isolation for apps will be
possible, kind of like what Android "promised." Cough, cough... Stupid
Google. But for now, the VM isolation is the way to go.)

And to digress further, does anyone have opinions on Keepass2? It looks
"shinier," but I'm not sure needing to haul in all of Mono *adds* to one's
peace of mind...?

> I see, this may be a personal preference. Me being obsessed with
> architectural research, I like to explain this with "isolation". Actual
> benefits may be that I can share the personal keepassx database with
> another device with simple tools, say - the laptop I use to only watch
> cat videos on youtube when I'm done at the workstation.

You have a dedicated cat-video laptop, too? Awesome. :)

One thing in my paranoia-induced-retreat-to-Fedora made me notice, is how
conservative Fedora is with regards to playing videos and such.

I realize some of the factors are licensing issues, but having to go to a
non-Fedora-approved, non-Fedora-Reviewed, repository (Fusion) to simply
view mp4 videos with mp3 audio didn't sit well with me.

And half the "howto's" about adding that repository involved a
--nogpgcheck flag, which isn't cool with me, either. :) I guess there
are signing keys around, and people say "yeah, sure, you can trust
rpmfusion, it's been around forever" but it just doesn't seem as provably
trustworthy as the core repo. It'd be a great vector for attack.

(Which gets one looking at how debian can play mp4/mp3 videos/audio by
default, by trusting nonfree/contrib repos by default... Hmmmm.)

I've settled on the compromise of having all those
non-free/contrib/non-reviewed stuff in AppVM's with no network
connectivity. Any exploits can have their fun nuking my downloaded cat
videos.

For work + personal browson and email, I stick to core Fedora AppVM's with
no third party non-certified add-ons. Feels right. :)

>>> And there are some types of password I keep in a
>>> non-internet-connected AppVM, together with some OTP generator
>>> scripts.

I'd really like to see some default OTP stuff for the major distros and
Qubes. I'll probably hook in otpw or oath myself for fun, but it'd be
nice to see some of these more powerful authentication systems supported
"out of the box."

>>> They are meant to be used for targets that may be
>>> sensitive to large scale attacks

These days, I think anyone is subject to attacks on a mass scale, for
anyone who is willing to pay to get access to the hacks. Many a time I've
been led to believe that things are simply hacked by default, and up for
sale if the price is right, to anyone with enough money or craziness to
invest in it.

Just my cynical point of view. :)

>>> (say, home banking credentials,
>>> amazon AWS otp generators, etc.) where attackers may have the
>>> financial power to aggressively attack the target AppVM - so my
>>> line of defense here is to be sure not to have the sensitive
>>> information available on the filesystem at all.

Agreed. I keep my keepass database on one removable device, with a
keyfile on a separate removable device plus a password. Some cowardly
creep/crook wants to tamper with my system while I'm out, they're not
going to get very far.

Since moving to that approach, I've noticed a lot more "noise" from the
ones I suspect of being involved in my harassment. Ironically, probably a
good sign.

(It's funny when you change a password on a certain site, and suddenly
several people contact you that you haven't heard from in ages.
Similarly, after cleanly changing a password without any errors, and then
seeing several "sorry you're having trouble logging into your account"
messages is another pretty good indicator that someone's actively messing
with you.)

>> Well they're in the AppVM though so are on the filesystem, aren't
>> they? What you buy is network isolation, effectively air gapping, but
>> even better.
> It depends on the point of view; yes, they are on the same dom0
> filesystem, but they are on different filesystems from the AppVM's point
> of view. May as well be on another machine, or another universe, if Xen
> isolation keeps.

That reminds me: one thing I think I read in some Qubes architecture docs
or online reviews, was the mention that each AppVM's filesystem was
individually encrypted with its own key, which is clearly not currently
the case.

Are there any plans to support this in the Qubes VM Manager?

Currently, I just keep personal communications, documents, etc., in a
separate, encrypted, mountable device that I can assign to a VM as needed.
But having individual keys for each VM would go further towards one
stated goal of disallowing each VM or dom0 from being able to snoop on
each other.

Right now, the overall dom0 filesystem is encrypted, which is cool, but
nothing beyond that, unless you do it yourself. Yeah, more passwords are
a pain, but if you choose to do so in the name of security, it'd be nice
if the Manager supported it.

Also, does anyone see any potential security holes with the (fairly
convenient) "Additional Drive" feature of HVM's? I guess that can only be
configured from dom0 (and it's canon that if that's compromised, you're
screwed), but it strikes me as something that should be looked at pretty
carefully.

Sorry if I'm rambling off-topic a bit here, but these are a few security
concerns I've thought about since starting with Qubes.

Cheers.

JJ

[Cube]

On Saturday, August 27, 2016 at 1:50:22 PM UTC-7, johny...@sigaint.org wrote:
> BTW, keepassx rocks. I'm working on some scripts to make it a little less
> painful with all the Ctrl-Alt-C and Ctrl-Alt-V'ing (which also conflicts
> with the standard konsole paste shortcuts).

I have no problem with the special cut/paste. Doesn't mean I don't screw it up on occasion, but I do like the assurance of having to do the step

Actually you betray yourself with the correct solution above; the Qubes shortcut to copy/paste between VM's is Ctrl-Shift-C/V which conflicts. I, like you, map that to Ctrl-Alt-C/V so no conflict. I've wondered why that isn't the default since the other is such an obvious conflict.

> Using keepassx on Tails is so much more streamlined, without the extra
> level of copying/pasting. It'd almost be nice if there were some explicit
> dom0 support for it somehow.

Yeah but Tails suffers from the same thing other OS's do which is one big system. So if it was theoretically compromised your streamlined copy/paste is exactly what you don't want.

Nothing you don't know, but I don't want the inter-VM copy/paste to change a bit. It's a small burden for a huge benefit. It also has an additional benefit of each VM having it's own Paste buffer, which ends up being very convenient.

>
> Agreed. I keep my keepass database on one removable device, with a
> keyfile on a separate removable device plus a password. Some cowardly
> creep/crook wants to tamper with my system while I'm out, they're not
> going to get very far.

I'd argue that your actually less secure with that scheme. Johanna made some comments to that effect, what you are doing is a kind of air-gapping, but you have a large attack surface through USB. If an Evil Maid controls your system it does you no good to bring in your passwords on a USB. So, if you're really concerned with that you should be implementing Anti-Evil-Maid on your system as the only defense - not keeping passwords separate.

> Since moving to that approach, I've noticed a lot more "noise" from the
> ones I suspect of being involved in my harassment. Ironically, probably a
> good sign.

OH, OK then you have a situation with a probably not too computer sophisticated opponent. Never mind then.

> But having individual keys for each VM would go further towards one
> stated goal of disallowing each VM or dom0 from being able to snoop on
> each other.
>

That should only be useful against Qubes bugs which allow sibling VM peeking, but otherwise doesn't help.

> Right now, the overall dom0 filesystem is encrypted, which is cool, but
> nothing beyond that, unless you do it yourself. Yeah, more passwords are
> a pain, but if you choose to do so in the name of security, it'd be nice
> if the Manager supported it.

The main problem with it is that the Qubes team is busy and underfunded enough to work on that feature. Their time is better spent making sure there are no chance of sneaky/peaky.

[Andrew David Wong]

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

I approach it as a security/convenience trade-off, just like
everything else. How many times per day do I have to access this
account? How bad would the damage be if someone else got access? If I
have to log in multiple times per day, and there's not much to lose,
I'll cache the password. If access is infrequent and the need for
protection is great, I'll copy/paste each time.

It may not make much of a difference, though. A determined attacker
who gains access to the target AppVM could simply wait for the
password to be pasted into the login prompt, then scrape the contents
of the local clipboard.

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

iQIcBAEBCgAGBQJXwntGAAoJENtN07w5UDAwk8wP/3cMoOHBUaqvwLUFfHjVRv30
lKNF02Ip2r5TNTBG3uzqyPtkqhwqbKeXR6ULpY7ySj6rxTmvC5OE4MrIY+ahnYr3
aWlZrnRk7l+u0GMWzZepUON27NiC6eyPcM3ZZgKAyPssqj9uRFNNHGw/ICI5uFYw
yvY6ERUPLUaNfdMh+aViwoceHyFySJQpziI6SqaCT5WF+1VePmOui90HL6td8KQA
1fjOFTgd/MgMQxfyEag8gW6FlTWrh6q4mp8KjduJ0enJ2yUz5BC9NDEJnbfWSU22
rUdwZDeFFcqF2FPassXSFW75VbyFynES+uLkUe8JdX9uHhAEF04pZt+ixGSKT3t5
xjEspn2wENbKVYn6j9BFD5k4h6kpT8WdP27dA2IXeYNiBLEjCGx3dRomPMrpSbD3
IZryi1+EDZ3qdwiUpuEFaH5Tjs5+YGdxpAlKnorocKXbi8yp9R3SHy2YxtvKchy1
8/94VkU/JaFBtHCUUEGmRk0XFP0FYnYY8nqBaHUHk1NBQdoBptfXq9cRprM3ZfXR
kefcQ7KHzmFiLfUVLT73FRV0+1XIFJwMA12yzDjM1cbYUUKYYNoH9tHyuMZuJrWs
z3zeD2lelPuLb3kSXXwa34zyoHrt8A6qhyXyuvFw51tPBxpLfXNQIgkinAmb6EP+
D15Vo9TcyN5OT46457DF
=b3nC
-----END PGP SIGNATURE-----

[Alex]

On 08/27/2016 10:50 PM, johny...@sigaint.org wrote:
> BTW, keepassx rocks. I'm working on some scripts to make it a little
> less painful with all the Ctrl-Alt-C and Ctrl-Alt-V'ing (which also
> conflicts with the standard konsole paste shortcuts).

That would be nice. KeepassX used to have a working auto-type feature
before v2, in which it was completely broken on Qubes. I did not try the
auto-type of keepassx2 on any other fedora installation...

> And to digress further, does anyone have opinions on Keepass2? It
> looks "shinier," but I'm not sure needing to haul in all of Mono
> *adds* to one's peace of mind...?

I tried that, because I used to use that on Windows before moving my
main workstation to qubes. It's even more broken than keepassx2.

And I say that as a professional cross-platform C# developer, so
absolutely no prejudice against Mono.

> I realize some of the factors are licensing issues, but having to go
> to a non-Fedora-approved, non-Fedora-Reviewed, repository (Fusion) to
> simply view mp4 videos with mp3 audio didn't sit well with me.
>
> And half the "howto's" about adding that repository involved a
> --nogpgcheck flag, which isn't cool with me, either. :) I guess
> there are signing keys around, and people say "yeah, sure, you can
> trust rpmfusion, it's been around forever" but it just doesn't seem
> as provably trustworthy as the core repo. It'd be a great vector for
> attack.

> [....]

> These days, I think anyone is subject to attacks on a mass scale,
> for anyone who is willing to pay to get access to the hacks. Many a
> time I've been led to believe that things are simply hacked by
> default, and up for sale if the price is right, to anyone with enough
> money or craziness to invest in it.
>
> Just my cynical point of view. :)
>

I understand your cynical point of view, but just two paragraphs above
that you seem to heavily discriminate against "non-core" repositories
(i.e., rpmfusion) wrt Fedora's official repositories.

I can't agree with you on that: for me, the Fedora repository is just as
exploitable as any other repository can be, be it rpmfusion or debian;
did you ever question your blind trust in Fedora's repos above the
others? Why do you think one is preferable than the others? I'm sorry if
I sound a little aggressive, English is not my primary language, I just
want to understand your point of view.

That distrust in software repositories is one of the very reasons for
the templated infrastructure of qubes: isolate vms, create different
templates with different software to minimize exposure of data to
untrusted software.

>>>> (say, home banking credentials, amazon AWS otp generators,
>>>> etc.) where attackers may have the financial power to
>>>> aggressively attack the target AppVM - so my line of defense
>>>> here is to be sure not to have the sensitive information
>>>> available on the filesystem at all.
>
> Agreed. I keep my keepass database on one removable device, with a
> keyfile on a separate removable device plus a password. Some
> cowardly creep/crook wants to tamper with my system while I'm out,
> they're not going to get very far.
>

I think you are mixing threat models, and I myself lost once in that sea...

Being Qubes a single-user OS for local-console-interactive workstations,
the question about caching web passwords in browser or not does not
belong to analysis of physical exploits; thus my threat model, which
does not include any physical attacks beyond evil maid.

But judging from your paragraph, I can't discern your threat model. Is
it a software exploit? Is it an untrusty person walking up to your
computer? It seems to me quite inconvenient to have to juggle with 2 usb
thumb drives, with all the added burden of connecting each to the
correct AppVM...

About that: connecting USB thumb drives to AppVMs it's just a couple
clicks more, but the added work drove me in using thumb drives less than
before. And I think that's a relatively healthy habit to acquire... But
I'm going too much OT.

> That reminds me: one thing I think I read in some Qubes architecture
> docs or online reviews, was the mention that each AppVM's filesystem
> was individually encrypted with its own key, which is clearly not
> currently the case.
>
> Are there any plans to support this in the Qubes VM Manager?
>
> Currently, I just keep personal communications, documents, etc., in
> a separate, encrypted, mountable device that I can assign to a VM as
> needed. But having individual keys for each VM would go further
> towards one stated goal of disallowing each VM or dom0 from being
> able to snoop on each other.

I don't agree this will add any security. Since the keys should actually
be in dom0 (or pass through that, if entered by a user), having a
compromised dom0 will ultimately lead to global vulnerability, be the
disk images encrypted or not. This will negatively impact performance,
instead.

Again, depending on the threat model, you may want to be able to give up
some functionality to increase security in specific scenarios, but - as
for the two thumb drives - does the burden really pay out for the users?
What benefit to the world does it give an OS which is nearly unusable
because of some very unlikely scenarios? I think Qubes fits the general
purpose secure OS model, with isolation and segmentation, and I think
this makes it fill a long-standing gap between the
Windows-with-administrator-user and air-gapped military mainframes.

If some user is so concerned with security, they may want to move to
military tools or remember that thermorectal cryptanalysis (or the XKCD
wrench, if you like) breaks any software security scheme...

--
Alex

[johny...@sigaint.org]

> On Saturday, August 27, 2016 at 1:50:22 PM UTC-7, johny...@sigaint.org
> wrote:
>> BTW, keepassx rocks. I'm working on some scripts to make it a little
>> less
>> painful with all the Ctrl-Alt-C and Ctrl-Alt-V'ing (which also conflicts
>> with the standard konsole paste shortcuts).
>
> I have no problem with the special cut/paste. Doesn't mean I don't screw
> it up on occasion, but I do like the assurance of having to do the step
>
> Actually you betray yourself with the correct solution above;

Speaking of "betraying yourself," that's why I am working on a few scripts.

More than once, I've thought I've copied they URL (from sigaint, for
example) and gone to paste it, but I copied/pasted the password instead
into the URL bar. D'oh! Even if I didn't load the page, with SIGINT
stuff, I don't like having my password show up on the screen.

Some scripts to let keepassx in a non-network VM interact with a networked
VM's browser could avoid such betraying-yourself screwups.

A few Qubes features are described as not protecting you from others, but
protecting you from yourself. This falls into that category, IMO.

> the Qubes
> shortcut to copy/paste between VM's is Ctrl-Shift-C/V which conflicts. I,
> like you, map that to Ctrl-Alt-C/V so no conflict. I've wondered why that
> isn't the default since the other is such an obvious conflict.

Agreed. It's way too obvious a conflict. There's just not enough key
combos on the damn keyboard it seems sometimes. :)

>> Using keepassx on Tails is so much more streamlined, without the extra
>> level of copying/pasting. It'd almost be nice if there were some
>> explicit
>> dom0 support for it somehow.
>
> Yeah but Tails suffers from the same thing other OS's do which is one big
> system. So if it was theoretically compromised your streamlined copy/paste
> is exactly what you don't want.

I'm a bit torn on that issue. Calling it "one big system" when Qubes is
arguably more complex, I'm not sure is correct. I guess it depends upon
your perceived threats. There have been times when things got "weird" on
Qubes, and retreating to a Tails DVD-rom felt safer. But the Xen-on-top
(with IOMMU protection against DMA attacks, etc.) ultimately should be
safer. So confusing at times.

> Nothing you don't know, but I don't want the inter-VM copy/paste to change
> a bit. It's a small burden for a huge benefit. It also has an additional
> benefit of each VM having it's own Paste buffer, which ends up being very
> convenient.

I hear ya. Right now, I *trust* the inter-VM copy/paste mechanism. I
don't want features introduced that make it more complex/less trustworthy.
And I think the tools are there with qrexec and the permissions system
implemented to do what I want it to do, without changing the core. So
yeah. :) If it's working, don't break it.

>> Agreed. I keep my keepass database on one removable device, with a
>> keyfile on a separate removable device plus a password. Some cowardly
>> creep/crook wants to tamper with my system while I'm out, they're not
>> going to get very far.
>
> I'd argue that your actually less secure with that scheme. Johanna made
> some comments to that effect, what you are doing is a kind of air-gapping,
> but you have a large attack surface through USB.

Trust me, every time I hear those three letters, U.S.B., I think "security
compromise." Why they ever let programmable firmware and stuff into the
mix totally escapes me.

If WW3 every happens, I swear it will be triggered by some USB security
screwup. :)

I actually load most of my keys off of 3.5" diskettes. :) Sometimes
retro feels more secure, less hackable.

> If an Evil Maid controls
> your system it does you no good to bring in your passwords on a USB.

No TPM here, just BIOS, so I don't think anti-evil-maid is something that
applies to me. I could be wrong, need to research it more personally.

I have a couple of personal anti-tampering approaches I use myself in lieu
of that, which I might suggest as additions to Qubes at some point; but I
won't talk about them just yet.

> So,
> if you're really concerned with that you should be implementing
> Anti-Evil-Maid on your system as the only defense - not keeping passwords
> separate.

I'll read up on that more.

Can't afford a maid, but I think there are other evil actors about. :)

>> Since moving to that approach, I've noticed a lot more "noise" from the
>> ones I suspect of being involved in my harassment. Ironically, probably
>> a
>> good sign.
>
> OH, OK then you have a situation with a probably not too computer
> sophisticated opponent. Never mind then.

The biggest mistake I've made (repeatedly) is underestimating the
opponent. I have been totally naive throughout a lot of the grief.

(In reality, I think there's a mix: one or more sophisticated opponents;
and mostly likely expensive hired help. And one or more obviously
not-to-sophisticated actors, that make obvious screw-ups now and then.
Which makes things all more interesting.)

>> But having individual keys for each VM would go further towards one
>> stated goal of disallowing each VM or dom0 from being able to snoop on
>> each other.
>>
> That should only be useful against Qubes bugs which allow sibling VM
> peeking, but otherwise doesn't help.

The more I think about sibling-VM-peeking, the less I think it's a threat.
I've argued against this type of thought before, but if inter-VM-peeking
succeeds somehow, you're pretty much screwed overall on the system.

(Inter-VM peeking is pretty much a dom0 escalation, in essence.)

>> Right now, the overall dom0 filesystem is encrypted, which is cool, but
>> nothing beyond that, unless you do it yourself. Yeah, more passwords
>> are
>> a pain, but if you choose to do so in the name of security, it'd be nice
>> if the Manager supported it.
>
> The main problem with it is that the Qubes team is busy and underfunded
> enough to work on that feature. Their time is better spent making sure
> there are no chance of sneaky/peaky.

Understood. And I hope to help contribute to their efforts someday in
some small way, to help with that situation.

As mentioned, simply having a separately encrypted device (sadly, often
USB) that one can attach to a VM, addresses most of my desires for
individual VM filesystem encryption. I really don't keep anything of
value or interest on the VM's private filesystem.

(Nor do I really have anything of value or interest at all, lol. I just
want some peace of mind and privacy.)

Appreciate the response and the thoughts.

Cheers.

JJ