Am 10/12/2016 um 04:00 PM schrieb 7v5w7go9ub0o:
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-
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
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
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.
Interesting idea. However I would not use the "move to VM" command like
this, as I experienced those requests getting lost One time files were
actually deleted, since that time I always use copy instead of move.
This is a problem with Linux (package based setup, dependency hell) - in
Windows you can run most Tools from their folder which you can place
anywhere you like. They may create files in other places (like the
registry), but they mostly run on a system they are copied to.
Depending on how you copy malware still might be able to persist. I
think about a browser extension, for example.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.