Scenario A
Step 1->Install Chrome in template
Step 2-> Use same Template for appvm1 and appvm2
Step 3-> On appvm1 login to chrome install extensions etc…Same on appvm2
Vs
Scenario B
Step 1->Use template without chrome installed
Step 2->Install chrome into appvm1 and appvm2 directly
My questions is: Which scenario is more secure when trying to protect against one chrome instance being compromised ? If they both point to the same Template installation, wouldnt a compromise of one compromise both? If so, would it not make more sense to install directly into the appvm and leave the template without chrome to ensure isolation between chrome instances ?
If you have 2 qubes using the same template, they are using a copy of the template root filesystem, which is not persistent. This means that the template can’t be modified by the qubes themselves, everything is removed at shutdown. This is why scenario A is better, it will isolate both from connecting to each other (from a security perspective).
Scenario B will require bind mounts to work anyway, since anything written to the root filesystem will be discarded.
In both scenarios, compromising Chrome in one app qube won’t affect Chrome in the template (if it exists there) or in other app qubes. However, scenario A is more standard. With scenario B, you’d have to install and update Chrome in a non-standard way.
No, because qubes are securely isolated from each other:
Unless you mean that Chrome in the template becomes compromised via a malicious update, for example. In that case, yes, all instances of Chrome based on that template (including the one in the template) would be compromised, but this doesn’t break the security model of Qubes itself. Qubes is still doing everything it should be doing in this scenario, because Qubes doesn’t claim to be able to prevent malware from being installed in a template (or any qube). All it claims to do is contain the damage by keeping qubes securely compartmentalized. In this scenario, the damage is still contained in the sense that other templates and other qubes based on those other templates remain unaffected.
That is a very good explanation that has helped fill in some knowledge gaps, thanks. On your last point-> I guess the question is does Qubes prevent malware from spreading from an appvm to a template? If it does for the most part, it would be very difficult to have a template or its chrome install get exploited.
P.S. You can consider to install chromium from flatpak. with --user flag. There will be completely different instances in both appvms, it is similar to Scenario B, but installation with user privileges.
Ur PS: Is to install chrome w/ flatpack + user falg in what ? Template or appvm?
It is a good idea, but based on the discussion and observations simply using the the same template for multiple chrome appms seems sufficient to isolte.
Takes a while to wrap ones head around qubes, but I think I have gained a better understanding thanks.
If an app is installed directly in the AppVM (scenario B) and it gets compromised during usage, it stays compromised. So the complete AppVM becomes untrustworthy and, probably, will have to be abandoned.
If an app is installed in the template (scenario A), it will not be executed there. Instead, it will be executed in AppVMs based on that template. In case of compromise, this will affect only the running AppVM and not the template or other AppVMs based on that template. After a restart of this AppVM, it will have again the original, uncompromised app, inherited from the template.
So, for scenario A, the consequences of such a compromise are much smaller.
I meant flatpak installation (with --user arg) inside the appvm.
I though about it, but unfortunately it is not completely true. Any malware will add itself to autostart in the user’s home directory, not requiring root rights nor access to template. Even if it not QubesOS-targeted attack. It will start each time qube starts.
The autostart trick will survive restarts only if the started software / malware is lying completely in the user directories (/home/user, /rw, and possibly more if bindings are used, or, for Windows, on drive Q:) - greetings from flatpak. with --user flag!
To be completely (99% ) secure from this scenario, you will have to do all work from disposables and store all permanent data in a qube without network access and without any apps installed there, possibly based on a minimal template. That’s not too convenient, but still better than being infected.
) secure from this scenario, you will have to do all work from disposables and store all permanent data in a qube without network access and without any apps installed there, possibly based on a minimal template. That’s not too convenient, but still better than being infected.