On 03/12/2017 06:09 PM, 7v5w7go9ub0o wrote:
On 03/12/2017 12:45 PM, Andrew David Wong wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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.
- --
Andrew David Wong (Axon)
This is the first I've seen your 4/1/15 note - sorry - wish we could
have discussed it then. 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.
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.
Thank you for the thoughtful analysis of 4/1/15; apologies for not
responding at that time.
Without a fleshed-out concept and implementation details, there is not
much to criticize or praise.
But with the focus on email and browsing thus far, I'm getting the
impression this involves restraining the user from using the system as a
normal PC and becoming cloud-centric for personal data. It can isolate
particular (but not many) user-facing processes from the risk of network
protocols (but not so much from the risks of document/data parsing...not
without degradation).
If that is the case then it sounds OK for certain audiences. But
expecting users in general to go for this may be going several bridges
too far.
--
Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/f8727958-e604-4a28-d590-7c4427acd7e9%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
