On 03/14/2017 06:08 AM, Andrew David Wong wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2017-03-12 15:09, 7v5w7go9ub0o wrote:
On 03/12/2017 12:45 PM, Andrew David Wong wrote:
On 2017-03-11 19:41, Unman wrote:
On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise wrote:
On 03/11/2017 11:56 AM, Unman wrote:
On Sat, Mar 11, 2017 at 04:43:41PM +0000, sm8ax1 wrote:
7v5w7go9ub0o:
Yep! And ISTM this is an argument for using dispvms to
handle mail (or any other WAN-exposed client/server):
start a dispvm; copy mail client and mail "file" into
it; do your mail; copy out and save the updated mail
file (which is text); flush away the dispvm - all
handled by a script(s).
How do you figure that's less of a pain in the ass than
typing a sudo password?
You're missing the point - that procedure is trivial to set
up in Qubes and addresses real security concerns. Just
putting a password on root access, or requiring some dom0
interaction doesn't.
This is important - security IS a pain in the ass. Qubes
can make it less so.
Yes, sm8ax1 got you there. :)
DispVMs are nice to have when we think that certain
operations carry threats. But its ridiculous to expect a
typical user to do a majority of their tasks in them.
No, it isn't ridiculous to expect a typical user to work in
disposableVMs. I've set up a number of users with a range of
experience, and they are very comfortable with this. If the
implementation is kept hidden generally speaking everything
goes fine. Some scripting to make things easier, and support
is probably no greater than usual ,except for "that funny copy
thing". I've said this before.
Set up right I don't think that Qubes is outrageously difficult
to use, even with disposableVMs doing most of the heavy
lifting. But that's a separate issue.
Agree with all of this. Working in a DispVM (e.g. browser, or mail)
is the same experience as working in a VM. Only difference is
clicking a script to start it up; inform the script of the DispVM
to work in; and telling the script to shutdown (copy updates) at
the end - in my case by entering a <n/l>
I'd be interested in hearing more about this (in a separate
thread, perhaps).
In particular, no one has, to my knowledge, attempted to rebut
the arguments I advanced against the "doing everything in
DispVMs" approach here:
https://groups.google.com/d/msg/qubes-users/nDrOM7dzLNE/Kr5W3BUkcG4J
RATS! I missed that.
Granted, that was almost two years ago, and some of the things I
wrote there no longer apply. However, I still haven't seen a
strong case made *in favor* of this approach to begin with. I
would like to see one.
This is the first I've seen your 4/1/15 note - sorry - wish we
could have discussed it then.
I also forwarded that message to you directly and invited you to have
an offline discussion about it (shortly after receiving no reply from
you on-list), but no worries.
Dang! Sorry again!!
You have the basic idea except for the vital point of what happens
at end of DispVM session (copying as few as possible user files
back to a VM or Vault). I take your point 4 on space, and point 6
on RAM and CPU usage.
I disagree on critical point 5.
For example running a browser in a VM is indeed "more secure" than
running it in a VM because only specific updated files (bookmarks
- places.sqlite) are retained and copied back to the vault at end
of session; no other user-land files (and surprise relics) are
copied back; this is contrary to what is presumed in that write up.
If if the bookmarks weren't changed, simply flush the DispVM away.
Doing mail in a DispVM is also "more secure" for the same reason -
only specific updated files are retained at end of session - no
other user-land files (and relics) are copied back to a VM. This is
key, and why this is more secure.
I think I understand the setup now. I agree that this is technically
more secure in the sense that your inter-session persistent attack
surface is reduced (fewer persistent files; a greater number of files
are "templatized"). However, it seems like a very minor security gain
for a huge cost in initial setup and inconvenience (see below).
Do you
agree that the security gain is relatively minor, or do you have some
reason to think that it is significant?
Aha!!
The key issue!!
1. Is the security gain very minor? (and is its huge cost in initial
setup and inconvenience worth it?)
(Heh.... as a side, of course the same questions can be asked of Qubes
itself - for users who use their computers to check their text-only
email and don't go "surfin", the realized security gain likely doesn't
appear to outsiders worth the cost. Box gets infected, go get a new one
for 2 or 3 hundred.)
My DispVM is no more resistant to a WAN attack than an AppVM. One is
really asking the value (security gain) of eliminating persistence, if a
bug is ingested.
I subscribe to a number of Usenet and mail accounts; I surf
voluminously; my "safe hex" is not as safe as it could be. My exposure
to a full range of bugs is great.
The unknown risk of infecting Wan-connected FireFox, TBird, messaging,
music streaming or other dedicated VMs user files with bugs silently
taking notes; or perhaps acting as bots waiting instructions; or perhaps
mischievously sending out garbage in my name as a joke; or perhaps
acting as an occasional porn server - is a terrible prospect. That one
of these VMs could be taking notes (or sending porn) over a period of
weeks would not only drive me crazy, but the ongoing reveal of my
activities would likely prove a dramatically greater and more damaging
security loss than a one-time hit.
So avoiding the consequences of having an infection *persist* over time
is my privacy/security consideration: and should it occur, it does
indeed render a significant increase in damage to Privacy and perhaps
security.
.
At startup, the user configuration file (.Thunderbird) is copied
into the DispVM, followed by the latest volatile user data files.
(If there is need to permanently change something in the user
configuration - I haven't in years - one simply starts up the
DispVM/tbird proggy, makes the configuration change doing no mail,
usenet, etc., and promptly copies the newly changed, whole user
configuration back to the vault, followed by immediate shutdown.)
Also disagree on your second part of 6; I've been using this and
other DispVM scripts since Q2.0 or Q2.1; I've become lazy as they
just work! Infrequently I'll get a "failed to start" DispVM
message, in which case I'll start one manually and tell the script
to use it (script pauses 'til the DispVM is up and running).
And also on point 6; yes there is a startup delay, but it is a
completely acceptable trade off to me for the reassurance and
relaxed comfort of running mail, browser, etc. in a DispVM.
Some of those performance issues have been fixed since I posted that.
However, it still seems like this entails huge inconvenience on the
user's part. Maybe it's easy once you get all the scripts set up, but
getting all the scripts set up in the first place seems to require
immense effort that would yield greater security benefits if focused
elsewhere.
2. ...and is its huge cost in initial setup and inconvenience worth it?
Well..... the question becomes, how difficult is it to page through the
instruction manual and write a couple of scripts - and as you noted, to
*maintain* the scripts within a changing environment? If you're talking
about casual social networkers and emailers jumping from Windows or
Apple to Qubes then I agree - it might be huge, immense and as you
suggest, not worth it.
And as you also noted, maintaining those scripts over time may be more
laborious and error-prone than creating them.
I'm no rocket scientist and most of the folks around here know much more
than I - but devising the scripts took a morning of creation and a few
subsequent tweaks. And I learned a lot and it was fun.
Guess I can't speak for others; for me it was worth it - for peace of
mind if nothing more.
At a minimum, it sounds like the user would be required to figure out:
1. Which files can be saved or discarded for each program without
losing data or config settings.
2. Which files have to be copied over into each fresh DispVM for each
program without missing data or config settings.
3. How to script starting the right program (for each program).
4. How to script copying the right data for each program from each
StorageVM to each fresh DispVM.
5. How to script copying the right data for each program from each
DispVM back to each StorageVM without copying unwanted files but
without leaving behind important data or config files.
Yes to each of those.
You have to figure all of these things out for every program you use,
and god help you if:
6. The program gets an update and suddenly changes where important data
or config files are stored.
Yep.
7. The program ever crashes in a DispVM, and it was the first window
open in a DispVM, so the DispVM destroys itself and you lose all of
your data for that session.
Yep - though you simply flush and reload if it was the first window; the
PITA occurs if it crashes at the end of a long and important session. I
presently stop and restart frequently - thereby saving updated files and
freeing space - but 'twould be easy enough to put a "snapshot data
files" in the script. Given I keep some of these up for days, I think
I'll consider it.
I'm suspect that I would run into a list of issues at least 20x as
long if I ever tried to implement this approach, but perhaps this is a
good start for discussing it. :)
Naw...... the big issue is understanding the concept; which you
obviously do.
The second issue is believing that there is the possibility of
WAN-facing clients being quietly infected, and that eliminating the
possibility of persistence would be worth the time....... which is
questionable.
(FWIW, I suspect that statistically any of this is questionable - most
Linux users will get by fine with limited use, "security through
perfection", and "safe hex". They can justify neither Qubes nor
DispVMs. (Heh....But of course not the case with Windows users - they
accept that their core OS is betraying their privacy, and soon their
tranquility with advertising))
Thank you for the thoughtful analysis of 4/1/15; apologies for not
responding at that time.
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/6f2eb29f-e577-be02-4893-928ebd9e812f%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
