Andrew David Wong: > On 2017-03-13 22:09, Chris Laprise wrote: >> On 03/12/2017 06:09 PM, 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. 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. > > > I agree. > >> 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. > > Only if "cloud-centric" means that the "StorageVM" is functioning like > cloud storage. > >> 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). > > > This sounds right to me. > >> 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. > > > Largely agree (details in other reply). > >
This is basically what I meant when I said > By the way, I'll call it "trivial" when there's an easy to use script, > complete with .desktop, readily available that does it. Writing said > script is more like "medium difficulty" for the average user. Qubes could probably be made more secure if users take the time to write their own FLASK policies too, but I really hope you don't expect end-users to do that. Even so, a script only handles one specific use case, like email in this example. We might as well ship Qubes with a set of VMs, one for retrieving email, and a DispVM for reading it (with automatic copying), that handles all this transparently as was described. This way the user wouldn't have to install a script, and we wouldn't lose anything because the script would have to be tailored to specific guest software for a specific use case anyway. But that's back to being regardless of the sudo configuration, and thus I think a topic for another thread. In other words, the DispVM debate still doesn't address the sudo debate. You can have one with or without the other. There are 2^2 possibilities here: persistent/disposable VMs with/without sudo. This thread was supposed to be about the latter. I still haven't heard any rebuttals against how sudo can help mitigate attacks against the virtualization (persistence aside). Without sudo, unprivileged processes can access /proc/xen/privcmd, raw sockets, memory mappings, etc., and load kernel modules that have even greater capabilities. We can be naïve and just assume that Xen and the kernel are completely secure, or we can be realistic and do a cost-benefit analysis of enabling Dom0 approval of sudo access. How often does the average user really have to elevate privileges anyway? Considering most directories not writable by user:user (with the notable exception of /usr/local and /rw) are non-persistent anyway, I'm not sure there's very much legitimate use for sudo. I can't figure out what use cases would require it so often that clicking "yes" in Dom0 would be especially inconvenient. And I'm speaking in the general case here; there's nothing to prevent someone from installing a specific VM, elevating via Dom0 once, and overriding /etc/sudoers via bind-dirs in that VM (or template) if they have a need for it. And I'll say it again: all this is in the absence of MACs like SELinux, AppArmor, or Grsec, or internal firewalls e.g. to restrict access to localhost. Obviously, if anything like that were enabled, it would be useless without requiring sudo approval. Since AFAIK there are no plans to enable anything like this in any of the stock templates, one could argue that /etc/sudoers should be overridden by specific templates that need it (have MAC or internal firewalls), but I don't know enough about the template building process to say. ------------------------------------------------- ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! -- 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/4192912a-29d3-3efe-1bfd-4f2b47cb7b30%40vfemail.net. For more options, visit https://groups.google.com/d/optout.
