On 11/15/20 2:10 PM, Matt McCutchen wrote:
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.

Same here.

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?)


For me, the advantage of TemplateVMs over StandaloneVMs (even if there's only one TemplateBasedVM based on the TemplateVM) is that it's easier to update the TemplateVM and back up the TemplateBasedVM.

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),

I just let it run overnight.

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.

No need. Just make your changes in one template, then clone that template as needed. That way, you only have to make the changes once.

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.


If you use minimal templates, even having a lot of them doesn't take up much space.

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


--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
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/813384d7-8adf-0b64-3a1c-40b1c935be6f%40qubes-os.org.

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to