-----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. > 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? > 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. 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. 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. 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. 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. :) > Thank you for the thoughtful analysis of 4/1/15; apologies for not > responding at that time. > - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYx4jIAAoJENtN07w5UDAw6xYQAJ7106A4MqS2rW93/NCjGQ33 WSBSfEbHQyFIWUjjZFYrWYwxZdpK2eDMPYvriXpMkTumuP8bFkPaVdcAkewenql1 BB4VgxgKKytmIDS9Vy2hMvXQ8IdnFVKOOElodKP50O+JmjHh/uHcaHP1pqb30oCx tvjvS6lY1lZQRFaMkbJDwfHZKYovcdWsrgSl/QpOJMYJDnHKROxfMVVWKWXTpCf9 nKZtO8JwPuiEttcW9EqKKuN2Vl4pZ9+FELuz8MK6Nh9Yy+VlPGwP1sxYg3Dl7Ief IcADhrEBSnF7tQ+X8KFFijJTVwgsHdQUfXIJYKzBakZDDgC+LccN+LSGK/9KJaEU HWb5LB+Z1RJZIEUFb0W0NNF2cZtdUPalXcEw2q5GwncYt/y7Yan7cMzBzbLXyhBr KOloGDeti7Ux7m1fGFPi2XjqjZUTw7Qu1u/yDxH7EsVUvHQF1OF76c7hQYaEQ+hC e3ry5Dac9ZLVNLaO0RNceDT23fC4L+CZawcxxfx6sHdV2C04dXi1AQeLJk7r1cVt RICXEeThbBGdONGaMkIFHb/wDRMqB3Ng2pblf36XQWzM9ZHtS/lE/16ZOa6KAdMI CmbygQiVmAqz8qKoEf9BNVb+o3W5W5kQWXKjUnFVOv+KQjWhSUtM0O9U6Z53VPk8 Ct20UQlvxJxVdlWJLm6t =Xnxt -----END PGP SIGNATURE----- -- 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/c5cf520b-8303-b95f-163a-ae5db822278f%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
