Hi Steve,

Thanks for your thoughtful response!

On Sun, 2020-11-15 at 16:31 -0500, Steve Coleman wrote:
> My way of dealing with it is to just clone your pristine fedora-32 
> template and add the required packages to that template clone, then
> create an AppVM that uses that template. This way you limit any
> potential data loss or damage to just that one AppVM which you then
> use whenever you need one of those proprietary apps. The question now
> is what data would they share in that AppVM and is it reasonable for
> them to share the same AppVM? If the answer is yes then there is no
> problem. If no, then create another AppVM based on the same template
> for the other app.

For proprietary apps packaged by their vendors, I don't trust the
package installation scripts any more than the apps themselves.  Thus,
if I wouldn't be willing to run two apps in the same VM, I wouldn't be
willing to install both apps in the same template either.  This being
so, the approach you suggest degenerates to the StandaloneVM approach I
mentioned.  (At the other extreme, if the apps were packaged by an
entity that I trust to ensure that no proprietary code runs without
user consent, then I could just install the packages in my main
template and the whole problem would go away.  Is there an intermediate
scenario in which having a second template shared by multiple AppVMs is
useful?)

> The downside is you now have to update two templates instead of one,
> but that of course can be automated. 

While I could probably get used to kicking off the dnf upgrade in all
templates and letting it run unattended (it's often slow), my bigger
concern is the custom tools and configuration changes in my main
template that aren't currently packaged for dnf.  I could probably
package them and/or do without some of them in some proprietary-app
VMs, but I think that would end up being a bigger hassle than
developing and using my proposed tool.  Also, I'm low on disk space and
making many templates would make it worse, though maybe it's time that
I just bought a bigger disk.

> How many specialized AppVMs you create is then based on your own
> risk/benefit analysis. I would think it's reasonable for instance to
> have Zoom and Skype share the same memory space unless the topics
> discussed in each app are highly confidential.

You're probably right that the additional risk of sharing a VM between
Zoom and Skype (for example) is small compared to the other unsolved
security problems I currently have.  However, inasmuch as I continue to
use the proprietary apps, I'd be more inclined to just develop the tool
to automate the use of separate VMs (anticipating that other people
might reuse it) than to address this question.


Matt

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/535e22152b2f63400aa59c22a971e6a19bbc19da.camel%40mattmccutchen.net.

Reply via email to