On Tuesday, March 14, 2017 at 9:45:23 AM UTC-4, sm8ax1 wrote: > 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!
yes I agree having to click yes in a dom0 popup will not be cumbersome for most. But is it that easy for the devs to implement? Even so, I'd rather they work on more important things. Because I feel that someone attacking a Qubes system is probably personally targeting someone or very sophisticated, and in that case then I don't really think it matters. Sudo will not help you. The sophisticated attacker probably has plenty ways to privilege escalate. And a personal attacker almost as sophisticated will be too persistent to fend off eventually. We already know an attacker doesn't need root for a persistent compromise. Isn't privilege escalation the main reason not to trust the linux kernel in the first place? Isn't there more 0 days exposed for this every year? For my nooby use,, and For most things I too also use dispvm. probably 85-90%% of my activity. I don't need scripts I just make shortcuts for programs or to inherit specific vm firewall rules. Mostly its using the browser, Using a separate dispvm for each task. For things I need persistent storage with I use a separate appvm. I have about two dozen seperate static appvms for specific tasks that only connect to one site or server. Half don't have internet access. Rarely am I ever doing something untrusted or random in a persistent appvm. I trained my family the same way. If I need to bookmark some shady site I'll do it in untrusted vm, and if some script kiddy wants to spy on it I don;t really care. In fact I enjoy wiping my vms and recreating them at the slightest anomaly because it is so easy in qubes. I just wiped and recreated the untrusted vm yesterday lol. I guess the Qubes devs feel, and me as well nowadays, that privilege escalation is so trivial they can't be bothered with it, or would feel guilty even implementing it. Sort of how most average users know that mac address filtering on routers is worthless. (even though I always use it) Threat model is again ok to use here, regarding myself, even if not regarding usability, but regarding time of the devs I will have to depend on cause I wouldn't be able to implement it myself. Maybe Chris and Unman can develop the feature? apt28 is probably laughing at us thinking sudo is going to help anyone... -- 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/d037aacd-e81d-4429-93b2-bef05e9f2ee9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
