On 11/19/20 4:50 AM, Matt McCutchen wrote:
On Wed, 2020-11-18 at 22:49 -0800, Andrew David Wong wrote:
On 11/18/20 5:54 AM, Matt McCutchen wrote:
I assumed the update process was the same for a TemplateVM or a
StandaloneVM (though I've never tried the latter),

It mostly is, but I personally find it easier to be able to update and
install packages in the TemplateVM separately from the TemplateBasedVM.

Why?

Just a lot of little things. For example, if I screw up the TemplateBasedVM, and I don't have any data in it, I can just destroy it and recreate it without having to reinstall any programs. Conversely, if I screw up the TemplateVM, I can keep the TemplateBasedVM and just recreate the TemplateVM.

One advantage I see to the StandaloneVM is that package changes
are immediately persistent and usable in combination with the private
volume.  When using a TemplateVM and TemplateBasedVM, I generally make
package changes first in the TemplateBasedVM for rapid iteration (where
they will be lost on shutdown) and later make them to the TemplateVM
once I am sure what changes I want.

I suppose I'm now at the point where I already know which packages I need, so that problem seldom arises for me now.

There's also the minor fact that I can update all of my templates with a
single qubesctl command, whereas StandaloneVMs would be left out.

That's strange.  If qubesctl has an option to target all TemplateVMs,
I'd think the case for an option to target all updatable VMs
(TemplateVMs and StandaloneVMs) would be equally strong.

Oh, and there's also a bit of a security benefit, which I forgot to
mention:

https://www.qubes-os.org/doc/templates/#note-on-treating-templatebasedvms-root-filesystem-non-persistence-as-a-security-feature

I'm of the firm opinion that auditing a home directory for user-level
rootkits is impractical, as suggested by that page.  IIRC, I came to
this conclusion long before I migrated to Qubes OS in 2014.

Yes, but even if you don't skip backing up templates, just being able to
include them in different backup sets and being able to back them up at
different frequencies is handy.

Another interesting point.  Currently, I just back up all my VMs
weekly.  If I were to try to improve that, rather than set different
frequencies for different VMs, I'd be more likely to try to find a
solution to back up each VM incrementally so I can afford to back up
all of them more frequently.  In the past, I've seen some discussions
of how to do this without significantly increasing the attack surface,
but I don't have the links on hand.


There's an open issue for this:

https://github.com/QubesOS/qubes-issues/issues/858

Though I suppose the more general
observation underlying my original proposal was that if the process to
generate the system volume from that of the main TemplateVM is
automated and reasonably fast, then there's the option to run it on
every boot of the TemplateBasedVM rather than persisting a separate
system volume at all.


I can't speak to that. My experience has led me to keep things simple
and in line with intended functionality, since I've found that erecting
elaborate custom processes that aren't necessarily supported by the
underlying system results in too high of a maintenance burden for me in
the future.

I personally am not worried about this.  While I was waiting for
https://github.com/QubesOS/qubes-gui-agent-linux/pull/107 to be merged,
rather than build a custom RPM and install it in my template, I elected
to set up a script that ran on every boot of the TemplateBasedVM in
which I wanted the functionality and overwrote module-vchan-sink.so
with my custom-built one.  Maybe modifying the template would have been
better, but modifying the TemplateBasedVM on every boot did work.
  Installing RPMs on boot differs only in degree.

Matt


--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e614ce1d-982f-d014-f166-32a61e5f551e%40qubes-os.org.

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to