Re: [qubes-users] Automatic updating of extra RPMs from add-on repos in Fedora template-based VMs?

[Matt McCutchen]

Hi Steve,

Thanks for your thoughtful response!

On Sun, 2020-11-15 at 16:31 -0500, Steve Coleman wrote:
> My way of dealing with it is to just clone your pristine fedora-32 
> template and add the required packages to that template clone, then
> create an AppVM that uses that template. This way you limit any
> potential data loss or damage to just that one AppVM which you then
> use whenever you need one of those proprietary apps. The question now
> is what data would they share in that AppVM and is it reasonable for
> them to share the same AppVM? If the answer is yes then there is no
> problem. If no, then create another AppVM based on the same template
> for the other app.

For proprietary apps packaged by their vendors, I don't trust the
package installation scripts any more than the apps themselves.  Thus,
if I wouldn't be willing to run two apps in the same VM, I wouldn't be
willing to install both apps in the same template either.  This being
so, the approach you suggest degenerates to the StandaloneVM approach I
mentioned.  (At the other extreme, if the apps were packaged by an
entity that I trust to ensure that no proprietary code runs without
user consent, then I could just install the packages in my main
template and the whole problem would go away.  Is there an intermediate
scenario in which having a second template shared by multiple AppVMs is
useful?)

> The downside is you now have to update two templates instead of one,
> but that of course can be automated. 

While I could probably get used to kicking off the dnf upgrade in all
templates and letting it run unattended (it's often slow), my bigger
concern is the custom tools and configuration changes in my main
template that aren't currently packaged for dnf.  I could probably
package them and/or do without some of them in some proprietary-app
VMs, but I think that would end up being a bigger hassle than
developing and using my proposed tool.  Also, I'm low on disk space and
making many templates would make it worse, though maybe it's time that
I just bought a bigger disk.

> How many specialized AppVMs you create is then based on your own
> risk/benefit analysis. I would think it's reasonable for instance to
> have Zoom and Skype share the same memory space unless the topics
> discussed in each app are highly confidential.

You're probably right that the additional risk of sharing a VM between
Zoom and Skype (for example) is small compared to the other unsolved
security problems I currently have.  However, inasmuch as I continue to
use the proprietary apps, I'd be more inclined to just develop the tool
to automate the use of separate VMs (anticipating that other people
might reuse it) than to address this question.


Matt

-- 
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/535e22152b2f63400aa59c22a971e6a19bbc19da.camel%40mattmccutchen.net.

Re: [qubes-users] Automatic updating of extra RPMs from add-on repos in Fedora template-based VMs?

[Steve Coleman]

On Sun, Nov 15, 2020 at 1:36 PM Matt McCutchen 
wrote:

>
> 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?
>
>
My way of dealing with it is to just clone your pristine fedora-32
template and add the required packages to that template clone, then create
an AppVM that uses that template. This way you limit any potential data
loss or damage to just that one AppVM which you then use whenever you need
one of those proprietary apps. The question now is what data would they
share in that AppVM and is it reasonable for them to share the same AppVM?
If the answer is yes then there is no problem. If no, then create another
AppVM based on the same template for the other app.

The downside is you now have to update two templates instead of one, but
that of course can be automated.

How many specialized AppVMs you create is then based on your own
risk/benefit analysis. I would think it's reasonable for instance to have
Zoom and Skype share the same memory space unless the topics discussed in
each app are highly confidential. If so, you could also just launch a
Disposable VM based on that one template, but for each and every instance
of conversation, and then nothing is ever shared since each instance starts
up with no user data. You just need to move any presentations between
AppVMs to support those conversations.

Steve

-- 
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/CAJ5FDnjiVg%3Dg0TTsb8RrjXTMtwOiYZRn7e4U2UxjA3_XtvVYVw%40mail.gmail.com.

Re: [qubes-users] unable to start gnome-terminal or terminal on fedora-32 template

[Steve Coleman]

On Sun, Nov 15, 2020 at 2:49 AM Franz <169...@gmail.com> wrote:

>
> qvm-run -a fedora-32 gnome-terminal
> fedora-32: command failed with code: 1
>
>
Try adding the -p option so you can see any error message coming from that
command on the other side. Whatever comes back will give you a clue as to
why it is not starting the terminal.
qvm-run -a -p fedora-32 gnome-terminal

Steve

-- 
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/CAJ5FDngE%3DdbXLB0hGZLW4gKwZfyZ%2B5ARqa5Nf%2B%3DCaWpQLiziaA%40mail.gmail.com.

Re: [Qubes OS Community Forum] [Mailing Lists/qubes-users] [qubes-users] R4.0.4 RC1 Unable to delete or backup certain qubes

[Steve Coleman]

On Sat, Nov 14, 2020 at 12:51 PM Mike Keehan via Qubes OS Community Forum <
qubes...@discoursemail.com> wrote:

> Mike_Keehan 
> November 14
>
> Well, the thin pool is LVM, but if the VM is offline, there should not be
> a problem. Guess you'll have to investigate all the logs you can
> find.
>
I finally have the answer!

Thankfully this problem has nothing to do with R4.0.4 but rather a brand
new disk drive failing (MTBF<=5.2 days, likely earlier)  in a rather odd
way. What had me stumped is why the VMs would would seem to run fine but
completely hung the backup process while reading the exact same volumes. It
appears that all the VMs that were acting odd were all allocated on the
same physical drive, but nothing ever gave any kind of an error when they
were reading the drive. It was likely the per-VM metadata needed for the
backup system that failed first.

Fortunatly the drives built in "smart" log holds the records for the last 4
errors, which can be easilly checked, and this allowed me to identify which
physical drive needed to be yanked and replaced. Being a brand new system I
did not yet know which logical drive mapped to which physical drive. To
analyse the problem I used a "smartctl" tool variant on another system to
check the logs that are stored physically within the drive.

Since checking each drive in this way is relatively efficient and easy it
seems to me that there must be an automated way to check these error logs
and notify the user when a drive is starting to fail. My Qubes system was
completely silent and it was only because of the odd behaviour of the
backup system that I was forced to investigate. If the backup process
didn't just hang then all my future backups could have been trash, and I
would have not even noticed the issue until it was too late. Why wait until
the system is completely unusable?

So, my question to the Qubes community is, has anyone out there set up this
kind of "smart" disk check up on Qubes? What are the best tools for a quick
check, say upon each boot, or one that could easilly be put in cron for a
periodic/daily go-no-go health check?

Thanks,

Steve

> --
>
> Visit Topic
> 
> or reply to this email to respond.
>
> To unsubscribe from these emails, click here
> 
> .
>
>

-- 
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/CAJ5FDniPDdysU6isxXotQvdkPWgkZ9LFCRVLVbkRwp12%2BMacVA%40mail.gmail.com.

[qubes-users] Automatic updating of extra RPMs from add-on repos in Fedora template-based VMs?

[Matt McCutchen]

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
directory.

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!

Matt

-- 
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/144929a2d3398657afbce8bbc10224a91e0dc07a.camel%40mattmccutchen.net.

[qubes-users] Missing kde plasma package groups and XFCE panel

[Effie ML]

Hello!

I was just trying to install kde plasma on 4.1, however it says that the 
following group packages are missing:


 * kdepasswd
 * qubes-kde-dom0
 * xsettings-kde
 * plasma-workspace-drkonqi
 * kcm-gtk
 * phonon-backend-gstreamer
 * ksnapshot

And so it can install.


I am also missing the panel in XFCE with error:

"GDBus.Error:org.freedesktop.DBus.Error.ServiceUnkown: The name is not 
activatable".



I can start programs and all, it's just a little irritating.

--
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/49527c79-994b-0fd1-7747-e5f50802d7a8%40encryptionin.space.


OpenPGP_0x442D72A468025A30.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature