-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2017-03-14 19:04, 7v5w7go9ub0o wrote: > On 03/14/2017 06:08 AM, Andrew David Wong wrote: >> 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!! >
No big deal. :) > >> >>> 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.) > IMHO, there's a huge difference. The cost-benefit calculation of switching to Qubes is a no-brainer for anyone who has valuable data (or, more generally, has "something to lose" with respect to their computer activities). Granted, many people are not like this. Their only interaction with computers is entirely trivial and not worth anything (to them). For those people, the cost of learning Qubes isn't worth it. But for people with something to lose (privacy, data, reputation, assets, etc.), it's entirely worth it. The security gain isn't just an incremental improvement over other OSes; it's a paradigm shift. Even if you're "careful" on a conventional, monolithic OS (i.e., don't click on email links, only visit "sites you trust," etc.), your entire digital life can still be rather easily compromised because, e.g., your NIC isn't isolated. Qubes allows those of us who aren't low-level security architecture experts to achieve a level of security that would otherwise be impossible for us. > 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. > Thanks for the explanation. Given your unique situation and goals, it makes sense to pursue that kind of DispVM strategy. > >>> 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. > Thanks for sharing your perspective. I agree that it's a personal issue. For some people it will be worth it, for others not. The great thing about Qubes is that it takes care of 99% of our security so that we have the leisure to discuss the marginal gains of the remaining 1%. :) > (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. "Statistically" in the sense of actual rates of compromise -- maybe. The problem is that it's impossible to know for sure whether a computer is compromised, and "safe hex" practices are not enough. Again, think about an un-isolated NIC in a safe-hex user's conventional Linux box. The whole box can be compromised without that user ever making an explicit mistake or ever realizing it has happened. (Of course, it's also impossible to know for sure whether a Qubes box is compromised, but at least you've reduced the risk by many, many orders of magnitude.) > (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)) > Agreed. > >>> 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----- iQIcBAEBCgAGBQJYydOHAAoJENtN07w5UDAw0y0P/iko35Xc3SYYcltxHKTmobfl uowYOtzVI7eQqxFkSaWhz0uG6/73wpUqRSIBIQkdJlSkzTWUSTY2zkCE5EnLDFyp OqTa0g6phwKKUiyFQ36VRCvP55OkP0Vu92oH6s8f42sPfOA2U+IEqCeefX/9Q051 vmrR0F7T2bIDkrBumLSB5pKdoekTiHKNs1A8Jz7GVK5Yb0U6WgoGtun4EYBxK2PJ yQZtas+bWTj5GCCu9S8YkYwfwoO+vpNfvih1BCQOp+Of6Jt7zU5rCPfgPI3EGpgu cektXOYErydDVlL6l6ofe/4BVrPRVzxjmgcntyyp64r3gDI6nk/1QZ54qqW6I9qi uhjWAKWyQEEOm3IqWE3s1lItXqWyjp86sRmMJBT4up+IQOABAvJjiYClqC1gTmpN IoX8p85GTGbXyZPw648roGDCHbfTfAjsEifCMoW0cLrPIkstYvbSGBGTX3PQ53vK h1XrUmiW3+Rm/hHhhhV2Uw2ZLYe1Pftn9IgYVrtWYwqpe+FsOppTeEqtr79UvplK KhooZnAP+0ILjCzVaKwUh1gXK6rySzCQpLLDL2nM3dQ2XChk7t/Tf9/SEVHdLRQh A3sw+WoRmj0n/j0mb2vd3njuqQrKIhh9pHDgfD7O7xS44o7Q8c9LZRx40wnmuDWb qhl5D1Q+lhpVex3YKR49 =1Yf0 -----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/c67e9f38-a954-fa53-96c1-6884676ffe98%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
