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
Interesting!!
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/84df6c4b-4849-a3ae-fa55-8bd62c79f7c4%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
