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. -- 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/58c5c72f.4e45370a.6f1e8.199b%40mx.google.com. For more options, visit https://groups.google.com/d/optout.
