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.
OpenPGP_signature
Description: OpenPGP digital signature
