sm8ax1: > 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. >
Oh, would you look at that. Xen Security Advisory 211 (CVE-2017-9603) came out just hours ago. > IMPACT > ====== > > A privileged user within the guest VM can cause a heap overflow in the > device model process, potentially escalating their privileges to that > of the device model process. Emphasis on "privileged user". Even if Qubes is not vulnerable, this demonstrates how some fraction of all exploits are only available to privileged users. ------------------------------------------------- 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/3913dbf5-ecf8-064a-1e3e-109e42449a37%40vfemail.net. For more options, visit https://groups.google.com/d/optout.
