Ensuring AppVMs and TemplateVMs are as up-to-date as Possible

[ahimta]

The problem you're addressing (if any)
I have about 10 updateble templates in Qubes OS R4.0 (including dom0) and I want to keep them always up-to-date and avoid using any derived AppVMs that are out-of-date. The Qubes OS behavior I observed however is that I only get a notification for a template from Qubes Updater when I start a derived AppVM which is implied to be not up-to-date (otherwise Qubes Updater wouldn't notify me to do the update).

Unfortunately, this observed behavior can mean that a Qubes OS user can be at least one update-batch late when using an AppVM. And I think keeping your system up-to-date is one of the top-three tips for any computer-system user. I take this very seriously when using Ubuntu at work by setting auto-security updates, auto-daily update notification, and always upgrading everything first when booting before opening any apps.

This can be a strong case against using Qubes OS because it's much harder to always be up-to-date:sweat_smile:.

I don't think there's an easy obvious solution for Qubes OS unlike OSes like Ubuntu. But I think setting some goals/parameters can help in choosing a reasonable solution.

Describe the solution you'd like
Assuming the highest priority is to ensure the user is using an AppVM with the latest updates, then checking for updates more periodically even when a template is not used can be a start but it's far from a complete solution and there may be a dead-end in the future:sweat_smile:.

Where is the value to a user, and who might that user be?
Any user who is using a program (e.g: a web-browser) where it's possible that an urgent security update is issued will definitely appreciate this:smiley:.

Describe alternatives you've considered
What I do right now is whenever I get a notification from Qubes Updater for a template, I check all templates so that they are all updated:sweat_smile:.

Additional context
Add any other context or screenshots about the feature request here.

Relevant documentation you've consulted
Couldn't find anything on https://www.qubes-os.org/doc/

Related, non-duplicate issues
Couldn't find any open or closed issues on https://github.com/QubesOS/qubes-issues/issues/

[andrewdavidwong]

It's a chicken-or-egg problem: In order for a system to check for updates, the system has to be running. If it finds updates available, it's already been running without those updates. This is the same problem for every system.

However, Qubes has an advantage: The system that discovers updates doesn't have to be the same one that benefits from them. For example, by default, sys-net is usually running and checking for updates, which can then be applied in the TemplateVM before other VMs are even started. By contrast, conventional operating systems are always already running whenever they discover available updates. They have no ability to run only with all available updates applied, whereas you could easily do this for a subset of your Qubes VMs. The design of the Qubes architecture gives it an inherent advantage over conventional operating systems in this regard.

---

With this in mind, allow me to address some of your specific points:

Unfortunately, this observed behavior can mean that a Qubes OS user can be at least one update-batch late when using an AppVM.

Exactly the same as with a conventional OS, for the reasons explained above. (Note that, when your AppVM detects available updates, you can simply update the TemplateVM, then restart your AppVM before using it.)

And I think keeping your system up-to-date is one of the top-three tips for any computer-system user. I take this very seriously when using Ubuntu at work by setting auto-security updates, auto-daily update notification, and always upgrading everything first when booting before opening any apps.

You can do the same thing in Qubes, but better. Ubuntu is already running when it discovers and applies these updates. By contrast, not all of your VMs have to be running when updates are discovered and applied. You could have a personal policy of always checking for updates before starting certain sensitive VMs (or even most of your VMs, if you like) in order to guarantee that those VMs never run without the latest available updates applied. This is impossible on conventional OSes like Ubuntu.

And, of course, it is also possible on Qubes to update everything first before opening any apps.

This can be a strong case against using Qubes OS because it's much harder to always be up-to-date 😅.

On the contrary. As I have explained, Qubes has a distinct advantage over conventional OSes in this area.

[ahimta]

Thanks for the detailed and timely response:smiley: but it seems a tad biased towards Qubes OS:sweat_smile:.

This is a complex issue/topic and anyone can write convincing arguments for Qubes OS, Ubuntu, or even Windows NT:sweat_smile:.

I will detail my experience and frustration with this issue which is (very much biased)⁴² but I hope many users can relate:sweat_smile:.

Some Ubuntu major advantages over Qubes OS:

1. Security updates are applied automatically.
2. The user is notified daily about all regular updates.
3. The user can list and know what apps require updates.

What increases the impact of missing this in Qubes OS is the following:

1. Most my templates are based on the fedora-29 TemplateVM so when I get a notification for updates for any template, I will get the notification for updates whenever I open any AppVM based on a template that is based on fedora-29 (which is almost all of them):sweat_smile:. And right now, I would just check all templates whenever I get the notification for a single template.
2. Since I can't easily know which apps require updates from the UI, I give most updates more weight than I probably should:sweat_smile:.
3. Updating the AppVM on update notification or the template and then restarting is an expensive step because I'm doing something else routinely and the total time of doing the chore of either would take a non-trivial percentage of my total usage time:sweat_smile:.
4. There are regular-updates almost every single day for many templates so I will have to rinse and repeat (a lot):sweat_smile:.
5. Long running AppVMs can be outdated for a long time (e.g: sys-net, sys-usb):sweat_smile:. I almost never turn off my laptop (I just suspend it/close the lid) and some desktop users may never turn off their PC. One mitigation would be to periodically run the terminal in the AppVM and upgrade from there or disable service/net on most dependent AppVMs then restart service AppVM but, honestly, who would do that:sweat_smile:.

For me, personally, software-updates are a solved problem on Ubuntu. Sure some services/daemons/kernel may be outdated but some of them are still restarted automatically whenever updated and apps are updated only once.

On Qubes OS, I basically check all templates whenever I get a notification to make sure everything is up-to-date and I use outdated software on the AppVMs because I'm using multiple AppVMs and the time required to update them is longer than the time I will use them:sweat_smile:. This is not out of paranoia but as I explained before because most my templates are based on fedora-29.

Qubes OS isolation is awesome but the current updates situation is definitely one disadvantage from my perspective:sweat_smile:.

There's also the paswordless sudo in DomU (e.g: AppVMs that install and use NPM packages can freely use sudo) which is a very controversial topic on its own but I think it adds to my personal opinion that the security in Qubes OS is more different than absolutely better as compared other OSes:sweat_smile:. Feel free to ignore this:cry::cry::cry:.

I understand that even mitigating this can be 3+ major releases ahead and this alone may have its own milestone but I think this should be acknowledged and may be a better workaround should be documented:sweat_smile:.

[andrewdavidwong]

It sounds like this isn't really about Ubuntu vs. Qubes, but rather Ubuntu vs. Fedora.

Consider this: You can use Ubuntu VMs inside of Qubes. If you were to do so, almost all the problems you perceive would go away, so they are not inherent to Qubes.

Also consider this: If you were using baremetal Fedora instead of Qubes, most of the problems you perceive would still remain, so they are not specific to Qubes. It would make sense for you to propose these improvements to the Fedora project. Then Qubes would automatically benefit from them when they're implemented upstream.

The few things that are Qubes-specific seem to be based on your personal preferences, e.g., almost never restarting sys-net and sys-firewall. You claim that this is because you never shut down your computer (instead utilizing suspend), but this point is a red herring, since you can restart sys-net and sys-firewall in a matter of seconds without shutting down or restarting your computer. It sounds like a lot of your problems are self-imposed.

[ahimta]

I think this is more related to Qubes OS than Fedora because:

1. Fedora is a single OS and I can just do dnf update -y or use the UI whenever I get an update notification:sweat_smile:.
2. The time between the user getting an update notification for everything and using an outdated software is much longer in Fedora but in Qubes OS getting an update notification and using an outdated software can happen in a less than a minute when I open apps to do something else and these updates may be needed for multiple templates I just opened related apps for:sweat_smile:.
3. I can more easily see all the packages that will be upgraded for the system either in the CLI or the UI. And I can know whether I'm using them right now or how important they are to me:sweat_smile:.

And all the issues I talked about would still remain for Ubuntu on Qubes OS because I would still be notified about updates when I open an AppVM and multiple templates which derive from Ubuntu will need to be updated too:sweat_smile:.

I admit I'm (very biased)⁴² towards my usecases and habits:sweat_smile: but I honestly don't know of how to update service VMs without either using their AppVMs to update them periodically or disabling the network for all running AppVMs to restart the serrvice VMs after a related template update:sweat_smile:.

The right thing is to keep service VMs always up-to-date but it's way too easy to do the wrong thing and we can guess what most users would do in this case:sweat_smile:.

There can be mitigations for the ServiceVMs like using a minimal OS that would require less updates than fedora-29 but this may not be very straight forward to implement:sweat_smile:.

This is a hard problem and it only exists because Qubes OS has a superior isolation to other OSes in the first place:sweat_smile:.

[andrewdavidwong]

I think this is more related to Qubes OS than Fedora because:

1. Fedora is a single OS and I can just do dnf update -y or use the UI whenever I get an update notification:sweat_smile:.

Why can't you do the same in each Fedora-based AppVM?

2. The time between the user getting an update notification for everything and using an outdated software is much longer in Fedora but in Qubes OS getting an update notification and using an outdated software can happen in a less than a minute when I open apps to do something else and these updates may be needed for multiple templates I just opened related apps for:sweat_smile:.

Isn't this a good thing? In both cases, there are updates available that you don't yet have. In Qubes, you learn about them sooner. In Fedora, you learn about them later. If Fedora seems better, it's just an illusion because you don't learn about your outdated state until later.

3. I can more easily see all the packages that will be upgraded for the system either in the CLI or the UI. And I can know whether I'm using them right now or how important they are to me:sweat_smile:.

I guess we could find some way of exposing the package list when available updates are found. Would that address this point?

And all the issues I talked about would still remain for Ubuntu on Qubes OS because I would still be notified about updates when I open an AppVM and multiple templates which derive from Ubuntu will need to be updated too:sweat_smile:.

I don't understand. If you use Ubuntu inside of Qubes OS, then each Ubuntu VM is literally no worse off then a baremetal Ubuntu installation (unless Qubes interferes with the insides of an Ubuntu VM in some way that you haven't specified). Just imagine that you had 10 different physical computers each running Ubuntu instead of 10 Qubes VMs running Ubuntu.

I admit I'm (very biased)⁴² towards my usecases and habits:sweat_smile: but I honestly don't know of how to update service VMs without either using their AppVMs to update them periodically or disabling the network for all running AppVMs to restart the serrvice VMs after a related template update:sweat_smile:.

Both of those are viable options, as is simply restarting all the relevant VMs periodically.

The right thing is to keep service VMs always up-to-date but it's way too easy to do the wrong thing and we can guess what most users would do in this case:sweat_smile:.

Can you give an example of how it's "way too easy to do the wrong thing"?

There can be mitigations for the ServiceVMs like using a minimal OS that would require less updates than fedora-29 but this may not be very straight forward to implement:sweat_smile:.

This is a hard problem and it only exists because Qubes OS has a superior isolation to other OSes in the first place:sweat_smile:.

[ninavizz]

Cross referencing to consider with #5679

[andrewdavidwong]

Effectively a duplicate of #4621.