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!