Make Qubes-OS a "flavour" of a vm-isolating-os

General Discussion
1

Would it be much work to make qubes os a security-focused derivative of (invisble os), a more generic system? (Or to make a new security-focused derivative of qubes os, for that matter.)

The question stems from my observation that there seem to be different usages with contradicting goals.

Another way to think about this: if I were a company that would like to sell a system much like Qubes, but with different objectives, how would i be able to contribute improvements to the overall system?

2

Flavoured offshoots I can come up with right now would be:

  • security,
  • anonimity,
  • soft(ware)-air-gapping,
  • compartmentalized software development (per customer, per language etc.),
  • bookkeeping (digital coin),

.

3

What is missing in existing, original Qubes OS that prevents you from using it for anonymity or air-gapping?

4

I did not mention that something is missing.

The idea is that a flavour would be an easy pre-configured setup for specific use-cases, unburdening the user of the software of the need to know all ins-and-outs.

For instance providing a version that starts with a browser listing secure-drop locations.

The other is that it could make installation easier.

Perhaps a pre-selected set of installation arguments would also suffice for that use-case, is such a thing possible? (For instance, I install several times, but certain questions (keyboard, timezone) I always set to certain answers.)

1 Like
5

Somewhat related, I came across a SecureDrop WorkStation qube-template from freedomofpress. Which in its read me mentions it is based on a / the whonix qube-template. Both not complete OS-installs, but they are geared towards specific usages.

6

I failed to understand your question.
What exactly do you want/propose? Can you please provide examples or use-cases in details that are not fitting current state (not general examples, but exact scenarios)?

7

How would i create different types of Qubes-OS (installers/iso’s)?

Would it be useful to have different types/versions of Qubes-OS ?
Each type would meeting different criteria/goals.
A shared disk, for instance, is not really secure, so does not meet the ‘reasonably secure’-criteria, and should not be enabled/possible in the ‘secure’ version, but a shared disk could be quite usable (and acceptable) in other situations.

Would it be “easy” to make a Qubes-OS version (.iso) that is geared towards

  • whistle blowing / leaking documents,
  • anonymous online (group/protest) communication,
  • development-flavours, like: qubes-os, android, ruby, ci, python, web-applications, command-line,
  • bookkeeping / digicoin-administration,
  • a (default) dark-themed dom0 & domU’s,
  • a specific locale, pre-set keyboard, timezone, activated qubes,

I guess it comes down to me having to look better at/into the “Development workflow” documentation.

8

The current installer deploy the templates and ask the user for the dom0 interface (currently only xfce), so it should be totally possible to reconfigure Anaconda (the installer) to run extra commands and generate an ISO with this.

9

The recurrent difficulty with the idea of maintaining different flavors of Qubes OS is that while folks thinking of scenarios mean well:

  • they are usually not proposing to be the ones who take on the additional maintenance burden

  • they often haven’t set up systems for the scenarios they suggest, and as a result fail to realize how much defining concretely any of those scenarios is difficult because each covers a multitude of use cases that depend on:

    • personal preference (hint: themes, locales, development tools…)
    • threat models and acceptable trade-offs (the other examples)

Again, I don’t mean that as a harsh criticism of the proposal, but as a possible explanation, based on my own experience, of why we don’t see any of those flavors despite the fact that the idea is discussed regularly. I think it’s a good idea in theory, that happens to not really match the practicalities of actual Qubes OS deployments.

Coming back to the actual question: “Would it be “easy” to make […] ?”

“Make” is probably only part of the effort, “maintain” is another, assuming that what needs to be made and maintained is clear in the first place. Summary: probably not easy enough to justify the effort given the projected benefits.

1 Like
10

When you install Qubes OS, there is an option to not configure anything and not create any VMs. After you have such a clean system, you could run one of the preinstalled (perhaps Community-made) Salt forumulas to achieve anything in your list. So your suggestion is effectively a suggestion to create more Salt forumals. I don’t see a reason to modify the .iso.

11

Salt, or custom tailored templates.

Having x-qube for x task wouldn’t be solved with a new x-Qubes OS, it would just be Qubes OS with x-template.

12

I do not think it would. It would bring a bigger chaos, the all information and issues will be related to different sub-distros, and instead of telling the version (like R4.1) we would have to search for specific sub-version and some disto-specifics. And if these sub-distros would be not that different, what would be the reason to make them different. I still did not understand the exact use cases when different version of OS is required instead of templates or changing themes/layout/locale/backgrounds in the DE of dom0 as it happens with all other GNU/Linux distributions.

13

I think it was stated quite clearly:

i.e., simplify the configuration for non-technical people. This can be of course achieved by the Salt formulas prepared in advance.