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
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.
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.
Robert
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
https://groups.google.com/d/msgid/qubes-users/eb54e356-fb48-a64c-e6dc-dd8d0146841b%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
