Doing it wrong? software installation theory

[redacted]

my understanding of qubes and how it’s supposed to be used leads me to believe that there are basically 4 ways to install software on qubes, and the answer to which one to use is inevitably: “it depends.”

1. Install the software in the base template vm.

in general, just don’t do this.

2. Install additional software in specific AppVMs

generally, don’t do this either. unless you do funny business it won’t persist through reboots.

3. StandaloneVMs for specific needs

dedicate a whole vm to the software or specific set of software you need. gives you some isolation from the rest of your system but we’re not even really doing qubes things here yet. it’s just a vm. you will have to manage it’s updates separately. unlike an appvm you or the internet can wreak havoc on the os and you are done.

4. Custom TemplateVMs for different software configurations, with AppVMs based on the custom templates

THIS. this is how qubes should be used. clone the base template, install the software packages you need, then create AppVMs based on the custom template. the custom template is protected by using app vms, you have centralized updating through the custom template, everything is great.

ok, so?

in actual use what i find is that #4 falls apart really quickly. lets say that i need signal messenger. i hypothetically use it for work, for personal messaging, and a public account that i can share online. perfect, clone fedora base template, install signal into the new cloned template, and then create a personal, work, and public qubes all based off the custom template right? right. too easy.

but wait. for work i need zoom messenger. for personal and public i also use the matrix client element. maybe i need chrome for work and brave browser for personal use.

so what do you do here? of course it depends lol.

you could just create one cloned custom template with zoom, signal, element, brave, and chrome all installed or , create 3 standalone vms for each use case or create 3 copies of the base fedora template. install signal, zoom, and chrome in the work template, signal, element, and brave in the personal template, and signal, element in the public template.

whatever the hypothetical software packages are doesn’t really matter, the point is that typically you will have multiple sets of software that you need for different use cases, in my hypothetical example we now have 4 full copies of fedora, 3 of which with just a couple pieces of extra software installed. this seems silly to me, but 2tb m.2 drives are really cheap now so whatever.

---

What is your point?

I don’t know everything but i’m pretty sure qubes os is doing it wrong.

how should qubes do it?

it’s obvious: tesseracts.

qubes isn’t complex enough. i think we need an intermediary layer. here is my untechnical proposal of how it should work:

Proposed Three-Layer Approach

1. Unmodified Base TemplateVM (Layer 1): Contains only the core operating system, without any additional applications.
2. Software TemplateVMs (Layer 2): Overlay additional applications on top of the base TemplateVM. Each Layer 2 TemplateVM could be tailored for specific application sets.
3. AppVMs (Layer 3): Used for daily activities, storing personal settings and data, and based on the Layer 2 TemplateVMs.

Comparison

1. Resource Efficiency:

• Current: Requires cloning the entire base TemplateVM for each new set of applications, consuming more disk space.
• Proposed: Potentially more disk space efficient as Layer 2 TemplateVMs only store the additional applications, not the entire OS.

2. Complexity and Maintenance:

• Current: Simpler in structure but can be cumbersome when managing multiple application sets across different VMs.
• Proposed: Adds a layer of complexity in managing the relationships between layers, but could simplify application management and updates.

3. Flexibility and Customization:

• Current: Limited to the applications installed in the base TemplateVMs. Customization mainly occurs within AppVMs.
• Proposed: Offers greater flexibility in managing different sets of applications, allowing for more tailored environments.

4. Security and Compartmentalization:

• Both approaches maintain Qubes OS’s core principle of security through compartmentalization. The proposed method might offer more granularity in managing application-specific risks.

5. Implementation and Compatibility:

• Current: Straightforward implementation aligning with Qubes OS’s existing architecture.
• Proposed: Would require significant architectural changes in Qubes OS to support layering, potentially impacting compatibility and stability.

Conclusion

The proposed three-layer system for Qubes OS, with its distinct structure for managing the operating system, applications, and user environments, offers several potential advantages beyond improved disk space efficiency:

1. Enhanced Flexibility in Application Management:

   • Allows for more tailored Software TemplateVMs to cater to specific sets of applications or use cases.
   • Easier to create and manage different application environments without affecting the base OS.

2. Streamlined Updates and Maintenance:

   • Centralized updates for applications within their respective Layer 2 TemplateVMs, without the need to update the entire base OS.
   • Simplifies the process of updating and maintaining applications across various VMs.

3. Improved Scalability:

   • Facilitates the addition of new applications or sets of applications without needing to modify the base OS or create multiple full copies of the TemplateVM.
   • Better supports growing or changing software needs.

4. Reduced Redundancy:

   • Minimizes duplication of the base operating system across multiple TemplateVMs, leading to a more efficient use of disk space.
   • Each additional TemplateVM only adds the unique applications, not the entire OS stack.

5. Greater Customization for Users:

   • Users can more easily customize their Qubes OS environment to their specific workflow or security needs.
   • Promotes a more user-friendly approach to managing diverse application requirements.

6. Enhanced Security Through Isolation:

   • By segregating applications into different Layer 2 TemplateVMs, there’s potential for even finer-grained security control.
   • If one set of applications is compromised, it doesn’t necessarily affect other sets in different TemplateVMs.

7. Potentially Easier Backup and Recovery:

   • Backing up and restoring specific sets of applications or configurations could be more straightforward, as they are more modular.

8. Opportunities for Advanced Configurations:

   • Could allow for advanced setups like having different sets of applications for different security levels or purposes.
   • Opens up possibilities for integrating more complex software ecosystems within Qubes OS.

Considerations

1. someone would have to code the significant architectural changes in Qubes OS.

2. i really truly don’t know what i’m talking about and there are probably really good reasons i haven’t thought of why it isn’t done this way.

[gonzalo-bulnes]

Moderation note

You’ve clearly put some effort into writing this @redacted, please edit away the offensive references to people.

They remove strenght to your argument and border with the outer bounds of the Community Guidelines.

[Zeno]

@redacted

1. Install the software in the base template vm.

in general, just don’t do this.

Reasoning?

[alfonsius]

For installation of flatpak or gnome, etc-programs; I council to do a clone of each Deb/Fed-Template. On the clone templates You can install any software for working or testing, in that way you can the templates always on the safe side and clean. You can do any app based on the clone-templates, where you already have installed LibreOffice, Gimp etc as your requirements. This works for me avoiding the risk to corrupt a Template used for secured purposes…

[redacted]

again, i’m just figuring this all out too, but it seems like better practice to keep a clean version of the base templates. say some extra software you install has some exploit discovered in it, and you installed it in your base fedora template. now every vm based on that template has an exploit, where if you cloned the base template and installed it in the clone, only vms based on the cloned template would be affected by the exploit. i’m probably just being paranoid, but that’s why we are all here, no?

[solene]

@redacted

say some extra software you install has some exploit discovered in it

Code not running isn’t exploited. If a program is installed but not run, you can’t exploit it.

If someone broke into your qube and run the installed program with the exploit, that’s already too late anyway.

[redacted]

ok, maybe not a fully thought out example, but the point i’m trying to make is to keep the attack surface minimal. like do you really want microsoft teams installed in the same qube as your bitcoin wallet, whether or not it’s running? a huge part of the qubes ideology is security through compartmentalization. also it makes it easier to just keep cloning the clean base template to build out new templates for specific use cases / software configurations. saves you from bloat dependency hell during template upgrades too.

to flip it around back to you, what reasons are there to install software directly in the base template instead of just cloning it? i can think of a few things, like i don’t care for firefox, so i could uninstall it from the base template and use my browser of choice in all the qubes based on it, but even then it still seems better to create a clone of the base template and remove firefox there.

[solene]

@redacted

to flip it around back to you, what reasons are there to install software directly in the base template instead of just cloning it?

Less bandwidth usage for update, less time for updating, a lot easier to maintain.

There is nothing wrong using multiple templates and specializing them though, but I don’t buy the argument that installing more software make the system security weaker.

[redacted]

i mean, directly from Introduction | Qubes OS

In building Qubes, our working assumption is that all software contains bugs. Not only that, but in their stampeding rush to meet deadlines, the world’s stressed-out software developers are pumping out new code at a staggering rate — far faster than the comparatively smaller population of security experts could ever hope to analyze it for vulnerabilities, much less fix everything. Rather than pretend that we can prevent these inevitable vulnerabilities from being exploited, we’ve designed Qubes under the assumption that they will be exploited. It’s only a matter of time until the next zero-day attack.

In light of this sobering reality, Qubes takes an eminently practical approach: confine, control, and contain the damage. It allows you to keep valuable data separate from risky activities, preventing cross-contamination. This means you can do everything on the same physical computer without having to worry about a single successful cyberattack taking down your entire digital life in one fell swoop.

compartmentalize everything.

[solene]

@redacted

compartmentalize everything.

My take on compartimentalization is that it separates the places where I run the software

[oxpoz]

@redacted

do you really want microsoft teams installed in the same qube as your bitcoin wallet

Obviously not. Not sure if this is really the best way to do it, but for a bitcoin wallet it is enough to create an appVM based on whonix-workstation and then to add Electrum under settings/applications (while removing unnecessary apps and not using it for anything else). As mentioned: Compartmentalization. Here are threads with more complex setups for wallets though.

[fsflover]

@solene

My take on compartimentalization is that it separates the places where I run the software

Do you imply that minimal templates are useless? Like you, I don’t use them due to the huge management overhead (and relatively small security improvement), but I do believe that their attack surface is smaller.

At least, if a tiny malicious program can access a huge number of installed programs, it may have a higher chance of being unnoticed (since it can be smaller itself) and gain more capabilities even in an offline qube.

[solene]

@fsflover

if a tiny malicious program can access a huge number of installed programs, it may have a higher chance of being unnoticed (since it can be smaller itself)

How would this program start itself in the first place?

@fsflover

Do you imply that minimal templates are useless?

They certainly have some use, but I never found those useful to me.

I’d like to remember in this thread that Qubes OS allows people to build their compartmentalized system the way they want. It’s not because I’m using a single template that it’s what everyone should do, I wanted to make a point that it’s not that bad.

It’s perfectly fine to have specialized template if one prefers doing so, or start from a minimal template and customize it heavily to your needs.

[fsflover]

@solene

How would this program start itself in the first place?

Running programs is the whole point of a computer / AppVM. My point is that a program you run may be malicious (unless you check all its code), and it can hide its actions easier when having access to a huge codebase.

@solene

I wanted to make a point that it’s not that bad.

I’m just asking if there is any security benefit in minimal templates, in your opinion. I would immediately agree if you say it’s small, but it seems you don’t believe it exists.

[renehoj]

@fsflover

I’m just asking if there is any security benefit in minimal templates, in your opinion. I would immediately agree if you say it’s small, but it seems you don’t believe it exists.

Are there any known cases of Qubes OS being compromised by a package in the main repo, where using the minimal template would have prevented it?

[solene]

@fsflover

it can hide its actions easier when having access to a huge codebase.

this seems hair-pulled

@fsflover

My point is that a program you run may be malicious (unless you check all its code),

if you actually run it in an AppVM, that doesn’t mean an AppVM with the same template will be affected if you don’t run it in the other one.

@fsflover

I’m just asking if there is any security benefit in minimal templates, in your opinion. I would immediately agree if you say it’s small, but it seems you don’t believe it exists.

the only real security risks increase when installing packages (from the official distro repo!) in a template is when you install binaries with the setuid bit set (like sudo, X, ping maybe etc…), there are many exploit that relies on setuid binaries to escalate to root. That also depends on your threat model.

If you already have no password for root or sudo, there is no use of using such exploit because it’s already super easy to escalate to root. So I don’t see much security benefit in a minimal template where you would already have to install stuff on top to make it useful.

[fsflover]

@renehoj

Are there any known cases of Qubes OS being compromised by a package in the main repo, where using the minimal template would have prevented it?

I don’t know the security field well enough to find specific examples, but doesn’t it seem reasonable that some malware may require common libraries installed to function? Let’s say, a keylogger would not need to reimplement xinput if it’s already installed.

@solene

if you actually run it in an AppVM, that doesn’t mean an AppVM with the same template will be affected if you don’t run it in the other one.

I never said otherwise.

@solene

to escalate to root

Enough damage can be done without root.

It looks to me that your threat model simply assumes that the official distro repos can never have any malicious software. This is of course a reasonable threat model to have, but what if someone else’s model is different?

[solene]

I’m dropping from this topic

[gonzalo-bulnes]

@fsflover

but what if someone else’s model is different?

Then they’ll make different decisions? I’m failing to see what you’re asking here… I don’t think @solene is saying one size should fit all. I was reading quite the opposite actually after the broad “do this don’t do that” statements that opened the thread without any threat modelling context.

Maybe I read that wrong but it seems to me like the arguments have been laid out for everyone to make informed decisions, and I don’t think that reaching an explicit agreement is necessary or particularly useful to future readers once the different perspectives have been acknowledged. Their own circumstances will require them to make all the decisions for themselves anyway. What we can bring are questions to ask in context and considerations to have in mind when making those decisions, which you’ve both done a great job at IMHO!

Again, I may be missing something, I hope not!

Edit: Just saw your last post @solene. Not trying to pull you back in!

[Zeno]

@solene

Code not running isn’t exploited. If a program is installed but not run, you can’t exploit it.

from @unman post: Why Use Minimal Templates?

It doesn’t matter if an application is started, or used.
Most packages bring in libraries and associated packages, any one of
which might provide a foothold for an attacker. That’s how the attack
surface increases, not just by bugs in running applications.

---

Eventually, everything has vulnerabilities.
It’s a matter of tradeoffs. After all, you can go out of your house, fall and die, but it doesn’t mean you’re going to sit at your home now, right?