GUI-only software installation: Thoughts? (fedora)

[deeplow]

As far as I know in order to use the “Software” graphical installer on fedora (which shows in the application list of fedora-32 by the way) on has to enable internet access to the TemplateVM. (or use the updates proxy, but activating that requires the terminal, which we are avoiding in the first place)

This discussion follows because some tutorial for Qubes compelled users to do this (and it may be bad advice).

I wanted to know the community’s thoughts on this. I’ll outline mine bellow.

The problem

Using the terminal is a big usability pain point. And for a regular user only thing that is probably needed to do on the terminal on a semi-regular basis. So if this could be avoided, this would possibly avoid a lot of not-IT people dropping out of Qubes.

As such one potential workaround could be to use the graphical software installer for fedora (a default AppVM application). Unfortunately, it doesn’t work unless one gives the template access to the internet (which may be bad for security).

The following image is what one sees if the fedora is opened on a TemplateVM with no internet access:

As you can see, no software is presented and the application is unusable.

Benefits

Just contrast the following image of the graphical software installer with the hard-to-use dnf utility that relies so much on recall.

Potential user-related dangers

Updating to fedora-33 via “Software application”

As you can see on the picture bellow, there is an option to upgrade from fedora-32.

After testing a bit it seems the “restart and update” button gets stuck which prevents the user from completing the potentially problematic action. But this can lead to user confusion as the software didn’t perform what was expected by the user.

User starts doing internet-related tasks on TemplateVM

note: as suggested by @unman, this would be solved by making the “Software” application go through the updates proxy by default.

Because in order to make this work, one has to enable internet access, it may be possible the user starts using stuff like a web browser on the template VM, which defaults their entire purpose.

Opening the browser by mistake

On the templateVMs we want to minimise as much as possible running software. And the browser is probably the most complex software that could be ran.

When visiting a particular piece of software’s installation page, the interface present two buttons [website] and [Donate] which when clicked will open the browser.

Making it simple to enable third-party repos

The software center makes it extremely easy to enable third-party repositories. Which may not be desireable for the user from the security standpoint.

Potential technical risks

Increase attack surface (complex code)

Running a complex GUI application, can increase the attack surface.

Increase attack surface (internet access)

I don’t know exactly how the software center for fedora works under the hood, but I can imagine there is much less scrutiny as to how the protocol works. For typical package mangers, the protocol is probably well defined and it can even work with mirrors, but with the software center, I can imagine it only fetches the images from one source, for example

[deeplow]

On another thread, @unman suggested that it would be trivial to make the software installer go through the qubes proxy application.

Although this may be trivial, we should consider that for someone who has never touched a terminal (which we were trying to avoid in the first place), thigh might be a bad first experience.

So, probably replacing the .desktop with one which goes through the proxy, but default, could be a solution. But it only addresses one of the issues raised " User starts doing internet-related tasks on TemplateVM"

[unman]

I know this is said so often, that it’s almost become canon, but that
doesn’t make it true.
Here’s the thing - if you spell out the benefits of Qubes, and the user
really needs those benefits, they wont be put off by the terminal. Any
more than people who need Tor wont complain (too much) about the speed,
or the fact they cant use Bittorrent.
There are people who run devices inside Faraday cages, hop off WiFi
connections, change their passwords very frequently, swap out their
machines regularly - NONE of this is easy.

Does this mean that Qubes is a niche product? To some extent, it is,
like Tor is niche, or PGP, or indeed, Linux.
That doesn’t mean it’s not for “a regular user” - I’ve been arguing this
for years, based on my experience of working with all sorts of Qubes
users. Yes, a “regular user” will need help - undoubtedly so - but since
I’ve also worked in support positions I can tell you that regular users
need help with everything. Providing a GUI application is not (and
should not be) a substitute for enabling people to understand and use
the machines they are working with.
In my experience, the occasional use of a terminal does not lead non-IT
people to drop out of Qubes: why would it? They don’t have a prejudice
against terminals or typing commands (if explained properly) precisely
because they are not IT people.

There are people who wont use Qubes because of commands in terminals,
just as there are people who wont use Qubes because it wont install
on the brand new laptop they bought, or it doesn’t support their
iPhone 50, or Xfce is ugly, or , or …
In my experience, it’s simply not a pain point for genuine non-IT users.

I should say that I worked with one middle aged person who was
thrilled about using the terminal. They said it made them feel like a
real hacker: perhaps that should be a new strap line for Qubes -
“Qubes - makes ordinary users feel like hackers.”

Long, and unusually so, for me.
On the particular point, I think that Fedora GUI does require terminal
commands, but it also used to require Network Manager to be running: is
this still true?

[adw]

Interesting. I think our documentation assumes (and has for a long time) that the the user can use either GUI or CLI in order to interact with the package manager in order to install and update packages in a TemplateVM. Perhaps the underlying assumption was that the GUI is just a GUI for the same underlying package manager (why wouldn’t it be?) and hence that this doesn’t require any changes to the relationship between the package manager and the updates proxy, which we know already works.

[unman]

I’ve just tried in a Fedora-32 template, and dnf works fine, but
“Software”, not so.
Under “Explore” only shows installed packages, at a guess,
and under “Updates” reports “Go online to check for updates”, and yes,
it looks as if network manager needs to be running.
So it looks as if that assumption is incorrect.

On the other hand, being neither a fedora or GUI person, i could just be
completely wrong about this.

[deeplow]

Perhaps that is true, but the key issue I think is that images and more elaborate software description are probably not obtained through DNF (as far as I know), otherwise they would work.

So my assumption is that even though the dnf command might go through the updates proxy, the rest of the UI calls do not go though, thus failing to present any results.

But I would need to have a look at the code to confirm this hypothesis.

[deeplow]

Added another potential problem:

@deeplow

Opening the browser by mistake

On the templateVMs we want to minimise as much as possible running software. And the browser is probably the most complex software that could be ran.

When visiting a particular piece of software’s installation page, the interface present two buttons [website] and [Donate] which when clicked will open the browser.

After testing a little bit I can see that with no internet from the start it doesn’t display any applications (as probably nothing is cached). The following image is what one sees when the template does not have internet connection: (sorry about the images @unman)

After connecting the templateVM to the internet and turning it off after it does the first catalog download

The interface works almost entirely. We can search for packages and even click on them and see all the metadata and description

Most software images don’t load as they are probably only cached when we open a particular software’s page. But the critical part that also does not work is installing software. It hags with the message “pending installation…”.

This further seems to that the software is not limiting itself to talking to the dnf or else it would work.

Another hypothesis is that it is indeed only using dnf but it’s calling dnf directly from the binary and possibly not wrapper that forces it to go through the proxy (no idea how this is actually implemented in Qubes, just throwing some ideas around)

[deeplow]

@adw

Interesting. I think our documentation assumes (and has for a long time) that the the user can use either GUI or CLI in order to interact with the package manager in order to install and update packages in a TemplateVM.

Should an issue be opened for this, then?

[Rooftop]

What about dnfdragora - this provides a relatively simple GUI and will work in the template VM since it just uses the dnf backend. It’s not as pretty as “Software”, but on the other hand it does allow installation of all software, not just the subset that “Software” seems to offer.

Kind of a half-way point between the CLI and “Software” crowds

[deeplow]

@Rooftop

dnfdragora

It kind of resembles the “synapse” for debian-based systems.

[adw]

Sure, but I suggest that the issue be a feature request for supporting a graphical package manager (the thing you actually want), not about fixing the docs (a side effect of not having the thing you actually want). The doc fix is minor enough that I can just remove the relevant portions right now, and of course it should be updated again if/when a graphical package manager gets supported.

Given your findings, it sounds like running this in a template would be pretty risky, so some kind of “split package manager” where the risky part runs in a DisposableVM might be worth considering. Perhaps a graphical frontend that the user interacts with in the DisposableVM, then an unspoofable prompt in dom0 confirming the actual package name to be installed in the TemplateVM. But now this is starting to sound like quite a big project.

[adw]

I’ve removed the one mention of which I’m aware:

Remove mention of GUI software installer

If anyone spots any others, let me know.

[deeplow]

@adw

Sure, but I suggest that the issue be a feature request for supporting a graphical package manager (the thing you actually want), not about fixing the docs (a side effect of not having the thing you actually want).

Done:

Graphical Package Manager Support

@adw

Given your findings, it sounds like running this in a template would be pretty risky, so some kind of “split package manager” where the risky part runs in a DisposableVM might be worth considering. Perhaps a graphical frontend that the user interacts with in the DisposableVM, then an unspoofable prompt in dom0 confirming the actual package name to be installed in the TemplateVM. But now this is starting to sound like quite a big project.

Yes, that makes sense. I think the risk there would be making the mental models even harder to form due to the complexity.

[adw]

@deeplow

I think the risk there would be making the mental models even harder to form due to the complexity.

It should be transparent to the end user. (Ideally and eventually.)

[noti2p]

It would be usefull if somebody would read Wikipedia (snap part) before …

I found Gnome-software being a very helpful tool against some hardware attacks and crap mistakes (firefox being the best example).

It will NOT protect against willfull sell-outs (list widthheld to protect the guilty).