Hi qubes-users,

I have a bunch of VMs based on one Fedora TemplateVM.  In most cases,
I'm willing to install any Fedora package needed by any of the VMs in
the TemplateVM.  However, due to security concerns, I have one VM that
runs Zoom, one that runs Skype, one that runs Google Chrome, and one
that runs Visual Studio Code... you get the idea.  Each of those
applications offers its own dnf repository, but I don't want to add
those repositories to the TemplateVM.  And I don't want to use
StandaloneVMs because that will multiply my management work; even if
there are management tools that could handle most of my needs, I'd
still have to learn and configure them.

So far, I've been manually downloading the RPMs and extracting them
into the user home directory.  (Fortunately, none of them have had
dependencies on absolute paths that would break this approach.)  This
is enough of a pain that I rarely update the applications, which may be
bad for security.

Does anyone know of a better but still convenient solution?

I was considering writing a tool to automatically update specified
packages in a TemplateBasedVM every time it boots.  There are various
ways this could be implemented.  My latest idea is to actually add the
repository files to /etc/yum.repos.d in the volatile layer of the root
filesystem and do a normal "dnf install" but find a way to cache the
RPMs under /rw to avoid re-downloading them when they haven't changed.
 Compared to installing under /rw in some fashion, this approach does
extra installation work on every boot but produces a true systemwide
installation, avoiding any problems with absolute paths and the like
(though granted, I haven't experienced any such problems under my
current approach with the particular applications I use).

Proposed detailed design (untested): The TemplateBasedVM keeps a
directory of repository files, a list of package names to install, and
a cache directory of RPMs.  On boot:

1. "dnf clean packages"

2. "createrepo" on the VM's cache directory.

3. Copy the repository files to /etc/yum.repos.d and generate one for
the VM's cache directory too.

4. "dnf --setopt=keepcache=1 install" the requested package names.
 This may pull in additional dependencies, and all packages that were
installed will be left in the system dnf cache, including any from
repositories that were already in the TemplateVM.  (I don't have any
packages of the latter type, but other users with scenarios different
than mine might.  For that matter, other users could use the tool
purely to install extra packages from repositories already in the
TemplateVM (so the directory of repository files to add would be empty)
and/or for reasons unrelated to security.)

5. Sync the packages from the system dnf cache to the VM's cache
directory, deleting any obsolete packages from the VM's cache

6. "dnf clean packages" again.

I would welcome feedback of any kind.  After working out the design, I
realized that though I've suffered from the problem for years, it
happens that starting tomorrow I will rarely have a need to use any of
the proprietary applications, so actually developing the tool may fall
down my priority list unless others express significant interest.

As an aside, I'm aware that some people in this community might be
inclined to tell me off for adopting an approach to security that they
believe is poor in some way.  I haven't researched whether this is
actually a common problem; if it isn't, please do not take my statement
as an insult to the community.  FWIW, I think it's great that the Qubes
OS technology allows users to achieve a range of security levels higher
than that of mainstream OS distributions depending on how much trouble
users are willing to go to, and I'd like to see the community
accommodate all of them.  So I'll ignore any derision but consider any
reasonable suggestions to improve my own security or make my tools
suitable for users who want higher security.

Thanks for your attention!


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 

Reply via email to