On 10/11/2016 09:30 AM, Robert Mittendorf wrote:
Software that you don't need is a security risk as it imposes additional attack surface - we all know that. Besides exploits those tools might cause additional threat (e.G. RDP- VNC-, SSH-Clients)
So you better do not install non-universal software* in a template VM.
*software that is not needed in every VM which is based on that template

So where to put non-universal software?

- user-space: allows malware to persist easily, because of persistent write rights. And does not allow usage of standard repositories - other (cloned) TemplateVM: You need to make sure that you keep all templates up-to-date for security reasons, you need much more storage space and cause more ssd aging


Since r2.x, I've run each of my user apps in individual, dedicated, dynamically-configured DispVMs; using scripts that: start up a new DispVM, copies the application-specific files from the vault into the DispVM; runs the application, copies any updated data (data only) back from the DVM to the folder in the vault; discards the DVM. Of course the vault remains offline, and programs are never invoked within the vault; it is used exclusively to store data that is accessed safely in dispvms.

If a DVM becomes compromised or corrupted I simply dispose of the DispVM and start anew. No worries about quiet infections of appvm user files, as only updated data (in most cases txt files) is retained from the DispVM back to the vault.

After your OP, it dawns on me that one could devise similar scripts to start up a "barebones" DVM, dynamically modify it to be a dedicated application DVM by copying both the application files AND the necessary system (app) files into that DVM. Run the app; copy any updated data (data only) back into the vault, and discard the DVM. (This is trivial with some apps; e.g. keepassx; but could be involved with big complicated apps)

This would keep the DispVMs smaller, and as you point out, with fewer attack surfaces.

This would require two AppVMs: a "barebones" DVM (As per Rudd-O's "minimal" point, I'll likely use the Qubes default with Firefox system and FF "user" files installed), and a second AppVM containing and maintaining the system and user application files - it would be brought online only for the purpose of package manager updating.

I plan on testing/configuring this way with r4.x.  Thank You for the OP.

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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to