On 10/12/2016 02:22 PM, Robert Mittendorf wrote:
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- 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.

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.


Dang! Right you are - I miss-wrote! I do indeed copy; e.g.:

qvm-run -q --pass-io vault 'tar -c -f - keepass' | qvm-run --pass-io $x 'tar -x -f -'

(where $x is the newly-created DispVM.)

So I'll add an additional, similar command that would copy the system executable (e.g. keepassx) to the DVM, and instead of executing an installed app - which I do now:

qvm-run -q $x 'keepassx /home/user/keepass/keepass.kdb' &

I'd start executing a recently-copied app; e.g. something like (./ may not be needed):

qvm-run -q $x './home/user/keepass/keepassx /home/user/keepass/keepass.kdb' &

Don't know how much this will save me, as I don't have a lot of "stuff" installed, but it should reduce DVM size and attack surface (at the acceptable cost of dynamically creating DVMs before executions).

In terms of browser extensions, I think they *ARE* an issue, and I routinely copy only places.sqlite back to the vault; the rest of the DVM is discarded.

IF I do want to update extensions, then I'll start the FF DVM, update extensions, ublock, etc.; copy the whole shebang back to the vault; and then shutdown - without exposing FF to anything else.

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