Choosing a TemplateOS for security

[fiftyfour...@gmail.com]

If I were looking to maximize security, which would you say is better--Debian, Fedora, or some other distro, like Gentoo or Arch? If you've changed your sys-net, sys-usb, or other templates to something other than Fedora, why? And to what?

I've read that Debian is generally considered more secure than Fedora because of, among other things, AppArmor and tighter oversight of packages. This makes me wonder why it is that Fedora is the default template for basically everything while Debian has its default AppArmor disabled. Are there any downsides to basically removing Fedora from my Qubes?

I've also considered that the nature of Qubes makes this discussion seem moot to some, but my stance is that I should increase security where feasible.

[Chris Laprise]

On 1/20/20 6:02 AM, fiftyfour...@gmail.com wrote:
> If I were looking to maximize security, which would you say is
> better--Debian, Fedora, or some other distro, like Gentoo or Arch? If
> you've changed your sys-net, sys-usb, or other templates to something
> other than Fedora, why? And to what?

IMO, Debian is the best choice for secure templates. Its security focus
is at least "normal" while Fedora's philosophy is haphazard "test the
new stuff quick". Essentially all the worst systemd bugs will show up in
a current Fedora release, for example. OTOH, my experience with systemd
in Debian has been much smoother.

Fedora is also the only major distro that doesn't cryptographically sign
its top-level repo metadata, allowing a MITM attacker to selectively
prevent individual packages from updating. I interpret this as a
decision forced on Fedora project from Redhat's marketing dept. so they
can easily scare mission-critical Fedora users into purchasing RHEL
licenses. There is no other possible explanation, IMO, as even CentOS
fully signs their repos.

Debian is also more flexible: There are many more packages, and for the
very latest stuff Debian lets you grab from the testing, unstable and
experimental repos. And you get to choose whether you want shorter or
longer upgrade cycles; with Fedora its always short which is a cause of
disruption.

Finally, Debian templates are produced via Qubes official channels. That
means something at least in terms of the level of oversight for
building, distributing and updating the templates. OTOH, if this isn't
so important to you, then Ubuntu and CentOS templates are alternatives
to consider.

>
> I've read that Debian is generally considered more secure than Fedora
> because of, among other things, AppArmor and tighter oversight of
> packages. This makes me wonder why it is that Fedora is the default
> template for basically everything while Debian has its default AppArmor
> disabled. Are there any downsides to basically removing Fedora from my
> Qubes?

IIRC, the choice of Fedora was sort of an accident; it was what the
Qubes core developer was most familiar with at the time.

There is an open issue about moving away from Fedora to another distro
like Debian.

Note: Debian does come with the Qubes install media (and Whonix
templates are based on Debian as well) so at least its easy to choose.

>
> I've also considered that the nature of Qubes makes this discussion seem
> moot to some, but my stance is that I should increase security where
> feasible.

There is one thing I don't use Debian for: The Update VM (which may be
sys-net or sys-firewall, but you can assign it to a separate VM). The
reason is that dom0 uses rpm/dnf and Fedora template is needed to handle
it properly.

Also, Fedora template is currently required for building Qubes itself
and Qubes templates.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[fiftyfour...@gmail.com]

Many thanks for the swift and detailed response. 

I'll enable AppArmor (using your instructions from another thread) and install your qubes hardening project. I was slightly hesitant before, but I did some quick Googling and realised you're on the Qubes team. Would you happen to have any other major security tips? Are there any ways to secure my booting process without a TPM?

I feel like this sort of information can be compiled into a handy-dandy security hardening guide for the documentation section. I wouldn't mind writing it up if you provide the technical details (I'm not very technical, but I can write).

[Chris Laprise]

On 1/20/20 10:56 AM, fiftyfour...@gmail.com wrote:
> Many thanks for the swift and detailed response.
>
> I'll enable AppArmor (using your instructions from another thread

> <https://groups.google.com/forum/#!topic/qubes-users/cNwCH3rcIGk>) and

> install your qubes hardening project. I was slightly hesitant before,
> but I did some quick Googling and realised you're on the Qubes team.
> Would you happen to have any other major security tips? Are there any
> ways to secure my booting process without a TPM?

To correct a misunderstanding... I'm not a member of the Qubes project.
I'm listed on the Qubes page as a contributor, e.g. contributing to the
project from the outside.

I think a TPM-like device is important for physical security if you
don't expect too much of it. It makes evil maid type attacks more
time-consuming and complicated. Beyond that, you could search about ways
to make computers physically tamper-evident.

>
> I feel like this sort of information can be compiled into a handy-dandy
> security hardening guide for the documentation section. I wouldn't mind
> writing it up if you provide the technical details (I'm not very
> technical, but I can write).

There was an effort like that years ago. The doc is here and you can
still suggest edits:
https://www.qubes-os.org/doc/security-guidelines/

But there are also a number of other security guides on the doc page:
https://www.qubes-os.org/doc

[fiftyfour...@gmail.com]

To correct a misunderstanding... I'm not a member of the Qubes project.
I'm listed on the Qubes page as a contributor, e.g. contributing to the
project from the outside

 When I said 'team' I meant something more along the lines of 'recognized contributor' than 'member', but it's my fault for wording it so vaguely. Either way, it significantly decreases the riskiness of the hardening package in my eyes.

There was an effort like that years ago. The doc is here and you can
still suggest edits:
https://www.qubes-os.org/doc/security-guidelines/

I meant including information on Fedora versus Debian security, the re-activation of AppArmor (or at least a bigger sign pointing to its deactivation), the existence of your hardening project, etc. I've read every single document and don't recall seeing any of those. Anyway, I'll suggest edits later using some of what you've included here and elsewhere, which will be attributed to you, if you're fine with that.

[tortuga verde]

 

 

20.01.2020, 16:27, "Chris Laprise" <tas...@posteo.net>:

I have considered changing from fedora templates to debian templates, but this is what holds me back:

 

https://www.qubes-os.org/doc/templates/debian/#starting-services

 

I'm not a linux expert, so I don't know what/if services are starting, and if after an update new services are introduced or begin starting. It just seems like it would be an ongoing concern that doesn't exist on fedora. Is it easily remedied?

 

I'm a basic user, I'm not running any servers. However, I certainly would like to have templates that are more secure by default. I would use the debian minimal template for all sys and vpn VMs. I would clone it and expand it to include libreoffice, rhythmbox and all the other things for a more full-featured template, that is still smaller than the default template. Any insight/feedback would be appreciated.

[tortuga verde]

 

 

20.01.2020, 20:02, "tortuga verde" <tortuga...@yandex.com>:

As an example:

 

I just downloaded debian-10-minimal. According to the qubes minimal template page, I installed several packages, one of them being network-manager-openvpn, so I can use this template for VPN VMs too. During the install progress I saw that once the dependency 'openvpn' was installed it started the service. Suspecting this is the sort of thing the qubes' debian page warns about, I built a temp VM based off it.

 

I opened xterm on the VM and ran systemctl status. I didn't see anything specific to openVPN, so I then ran systemctl status openvpn. It is there, active (exited).

 

To compare, I created a temp VM based off my fedora minimal, which also has networkmanager-openvpn installed, and where the my VPN VMs work as intended. I ran systemctl status openvpn, and it returns Unit openvpn.service could not be found. Good.

 

Is this correctly illustrating the difference between fedora and debian? Do I need to worry about an increased attack surface since this might accidentally be running in every appVM based off the debian template? In this specific example I'm aware of it, so I will disable it. But what if this happens in the future with other packages? I do need to be constantly worrying about some service running amok without my knowledge? Is there a simple one-time mitigation so that it behaves more like fedora?

 

Also, since it was not listed in systemctl status, how would I be able to easily enumerate all such services, so that if I want to see if any service is running because I failed to disable it at install time, I can find and disable it now? Is the debian way a bad idea?

 

I do like that the template with the necessary packages installed is significantly smaller than the fedora (1.6gb vs 2.1gb).

[Chris Laprise]

On 1/20/20 3:09 PM, tortuga verde wrote:
> 20.01.2020, 20:02, "tortuga verde" <tortuga...@yandex.com>:

> I have considered changing from fedora templates to debian
> templates, but this is what holds me back:
> https://www.qubes-os.org/doc/templates/debian/#starting-services
> I'm not a linux expert, so I don't know what/if services are
> starting, and if after an update new services are introduced or
> begin starting. It just seems like it would be an ongoing concern
> that doesn't exist on fedora. Is it easily remedied?
> I'm a basic user, I'm not running any servers. However, I certainly
> would like to have templates that are more secure by default. I
> would use the debian minimal template for all sys and vpn VMs. I
> would clone it and expand it to include libreoffice, rhythmbox and
> all the other things for a more full-featured template, that is
> still smaller than the default template. Any insight/feedback would
> be appreciated.
>
> As an example:
> I just downloaded debian-10-minimal. According to the qubes minimal
> template page, I installed several packages, one of them being
> network-manager-openvpn, so I can use this template for VPN VMs too.
> During the install progress I saw that once the dependency 'openvpn' was
> installed it started the service. Suspecting this is the sort of thing
> the qubes' debian page warns about, I built a temp VM based off it.
> I opened xterm on the VM and ran systemctl status. I didn't see anything
> specific to openVPN, so I then ran systemctl status openvpn. It is
> there, active (exited).

Yes, I thought of that specific example when you mentioned services. And
its an interesting point.

But the details...

* openvpn is not actually started because there is no configuration
(unless the user adds one).

* On Qubes, auto-started services that do run+listen in appVMs won't be
reachable unless the user makes exceptions in the Qubes firewall.

* Debian is conservative about what they add to their basic installation
over time. IIRC the Debian template is the basic install + Qubes
packages + keepassx + some wifi drivers that Debian doesn't install by
default.

> To compare, I created a temp VM based off my fedora minimal, which also
> has networkmanager-openvpn installed, and where the my VPN VMs work as
> intended. I ran systemctl status openvpn, and it returns Unit
> openvpn.service could not be found. Good.
> Is this correctly illustrating the difference between fedora and debian?

So far, there's not much effective difference.

> Is there a simple one-time mitigation so that it behaves more
> like fedora?

Yes, run it on Qubes. :)

This is what has to be done to make services in a qube accessible to the
Internet:

https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world

> Also, since it was not listed in systemctl status, how would I be able
> to easily enumerate all such services, so that if I want to see if any
> service is running because I failed to disable it at install time, I can
> find and disable it now? Is the debian way a bad idea?
> I do like that the template with the necessary packages installed is
> significantly smaller than the fedora (1.6gb vs 2.1gb).

[shroobi]

You just need to learn more commands for systemctl. Debian generally has fewer services
running than Fedora, but there are some that you might want to disable. Some services will
work in an AppVM but fail in the TemplateVM because there is no network access.

$ sudo systemctl list-units (--all)
$ sudo systemctl list-timers (--all)
$ sudo systemctl list-sockets (--all)

Read the man page, especially the section about commands to learn how to disable and
troubleshoot.

$ man systemctl

[Dan Krol]

FWIW it looks as though Debian tends to support their OSes for longer before EOL. I'm tending toward Debian regardless just for familiarity, but this fact makes it an easier choice. Supposing "security concerns" include the time it takes to maintain your system (as it does for me), I see this as another point for Debian.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1345411579539750%40sas1-30406100349c.qloud-c.yandex.net.

[Peter Thurner]

On 1/20/20 9:02 PM, tortuga verde wrote:
> 20.01.2020, 16:27, "Chris Laprise" <tas...@posteo.net>:
>
> On 1/20/20 6:02 AM, fiftyfour...@gmail.com

> <mailto:fiftyfour...@gmail.com> wrote:
>
> If I were looking to maximize security, which would you say is
> better--Debian, Fedora, or some other distro, like Gentoo or Arch? If
> you've changed your sys-net, sys-usb, or other templates to something
> other than Fedora, why? And to what?
>
>
> IMO, Debian is the best choice for secure templates. Its security focus
> is at least "normal" while Fedora's philosophy is haphazard "test the
> new stuff quick". Essentially all the worst systemd bugs will show up in
> a current Fedora release, for example. OTOH, my experience with systemd
> in Debian has been much smoother.

I think a good choice here is the distro you are most familiar with, as
you change given defaults to a more secure setting - and you have to
know about those settings in the first place. For debian I know all the
bells and whistles to switch but not I don't have much idea about fedora.

Imho the best choice here would be:

OpenBSD: Paranoid by design - sadly no working template (or is there by
now?!? :) )
Gentoo: Reduce attack surface by only installing (compiling) what you
actually need, plus compiling into the programs only what you actually
need. Downside: Time consuming to maintain.
Personally I'd love to see https://github.com/CLIPOS in a qube :) But
I'm not sure how much work that is... When ClipOS was released to the
public I've been playing around with it and didn't get it running, but
maybe that changed. From what I understand it can be "installed" on top
of Debian

Personally I use the debian-10-minimal template in Qubes and install
only what I need exactly for each Qube. Then on top of that, I apply
regular hardening... But I'm sure that something like OpenBSD or ClipOS
would be a better approach as they are build for the paranoid. I think
ClipOS would be "a" really good solution to run in a qube.

I think this is a good point in time to emphasize that we (the Qubes
community) should put some effort into actually creating a hardened OS
template for the qubes VMs (Please OpenBSD or ClipOS) :) as that is kind
of missing from the project. Something with preferably a host and
network IDS :P But I realize that this is lots of work too ofc..
We could make that better by providing a template for example hardened
with "thunderbird" pre-installed.

>
> Fedora is also the only major distro that doesn't cryptographically sign
> its top-level repo metadata, allowing a MITM attacker to selectively
> prevent individual packages from updating. I interpret this as a
> decision forced on Fedora project from Redhat's marketing dept. so they
> can easily scare mission-critical Fedora users into purchasing RHEL
> licenses. There is no other possible explanation, IMO, as even CentOS
> fully signs their repos.
>
> Debian is also more flexible: There are many more packages, and for the
> very latest stuff Debian lets you grab from the testing, unstable and
> experimental repos.

I'd like to add that for this you can also use qubes-builder to build a
ubuntu template.

> And you get to choose whether you want shorter or
> longer upgrade cycles; with Fedora its always short which is a cause of
> disruption.
>
> Finally, Debian templates are produced via Qubes official channels. That
> means something at least in terms of the level of oversight for
> building, distributing and updating the templates. OTOH, if this isn't
> so important to you, then Ubuntu and CentOS templates are alternatives
> to consider.
>
>
> I've read that Debian is generally considered more secure than Fedora
> because of, among other things, AppArmor and tighter oversight of
> packages. This makes me wonder why it is that Fedora is the default
> template for basically everything while Debian has its default AppArmor
> disabled. Are there any downsides to basically removing Fedora from my
> Qubes?

I have done this - replaced everything including sys-net and stuff for
templates based on debian-10-minimal. Works lovely.

Now I only have fedora in dom0 ofc... I think there was some guy who was
trying to get this running with debian but not sure.. I don't do $things
in dom0 so I'm not sure how much it matters. If this would be debian, it
would be very cool though.

>
>
> IIRC, the choice of Fedora was sort of an accident; it was what the
> Qubes core developer was most familiar with at the time.
>
> There is an open issue about moving away from Fedora to another distro
> like Debian.
>
> Note: Debian does come with the Qubes install media (and Whonix
> templates are based on Debian as well) so at least its easy to choose.

Sidenode: whonix has its own very interesting hardening guide on the
whonix wiki.

>
>
> I've also considered that the nature of Qubes makes this discussion seem
> moot to some, but my stance is that I should increase security where
> feasible.

:thumbsup:

I think its not the best idea to say "we have Xen so we can do whatever
we want in the VM - lets get rid of passwords for sudo". Something I
never liked about qubes.. I realize that by doing this, Qubes is easy to
use for most people, but I think templates should be created by the
community which serve the more paranoid power-users.

>
>
> There is one thing I don't use Debian for: The Update VM (which may be
> sys-net or sys-firewall, but you can assign it to a separate VM). The
> reason is that dom0 uses rpm/dnf and Fedora template is needed to handle
> it properly.

Yeah... I've had my fair share of trouble with that update thingy ;)

So as I only use debian here is what I found:

https://github.com/rickysarraf/apt-offline

This fancy tool allows you to install / update apt packages on airgaps -
which are, in a way, kinda like qubes VMs themselves.

I've written some bash / qvm-run magic to:

- Download packages in "sys-apt"
- Package them into an archive using apt-offline
- Copying and installing this archive on the target template VM

This way:

- you only download things once, not 20 times if you have multiple VMs
where all VMs need "cmatrix" installed
- for me it fixed me somehow breaking the updateVM all the time for
$reasons (the updateVM is then only required for dom0)
- you can create new qubes with packages you have downloaded already
while offline

At the moment my bash script around all that for qubes is a bit hacky
but I'll see to finishing it and putting it on github.

>
> Also, Fedora template is currently required for building Qubes itself
> and Qubes templates.
>
> --
>
>

> Chris Laprise, tas...@posteo.net <mailto:tas...@posteo.net>

> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
>
> I have considered changing from fedora templates to debian templates, but this
> is what holds me back:
> https://www.qubes-os.org/doc/templates/debian/#starting-services
> I'm not a linux expert, so I don't know what/if services are starting, and if
> after an update new services are introduced or begin starting. It just seems
> like it would be an ongoing concern that doesn't exist on fedora. Is it easily
> remedied?
> I'm a basic user, I'm not running any servers. However, I certainly would like
> to have templates that are more secure by default. I would use the debian
> minimal template for all sys and vpn VMs. I would clone it and expand it to
> include libreoffice, rhythmbox and all the other things for a more full-featured
> template, that is still smaller than the default template. Any insight/feedback
> would be appreciated.
>

> --
> 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...@googlegroups.com

> <mailto:qubes-users...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/1345411579539750%40sas1-30406100349c.qloud-c.yandex.net

> <https://groups.google.com/d/msgid/qubes-users/1345411579539750%40sas1-30406100349c.qloud-c.yandex.net?utm_medium=email&utm_source=footer>.

[tortuga verde]

While using qubes' debian minimal template page, I was successful in the debian 10 minimal template working for sys VMs, I failed at getting to mount usb devices without passwordless root, or get tasket's qubes-vpn-support working. How do you do it? If you could provide a wiki or builddoc for what it takes to successfully use it for those purposes, it would help us unwashed masses migrate from Fedora to Debian.

 

 

23.01.2020, 12:13, "Peter Thurner" <p.th...@blunix.org>:

To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b0c94552-e03f-78cf-8170-4bef7666012d%40blunix.org.

[awokd]

tortuga verde:

> While using qubes' debian minimal template page, I was successful in the debian
> 10 minimal template working for sys VMs, I failed at getting to mount usb
> devices without passwordless root, or get tasket's qubes-vpn-support working.
> How do you do it? If you could provide a wiki or builddoc for what it takes to
> successfully use it for those purposes, it would help us unwashed masses migrate
> from Fedora to Debian.

Sys-usb works with debian minimal too. Don't try to mount usb drives
directly in sys-usb- use qvm-block to pass them through to a different
AppVM and mount them there.

--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

[fiftyfour...@gmail.com]

> CLIP OS

I just checked out CLIP OS: If Qubes is like Inception*, wouldn't using CLIP OS in it be like going down a level deeper? I'm not a techie, but it feels like it'd be really unstable because of technological challenges. Really cool if implemented though, even if its government links make it feel sketchy.

*Title of a movie where people have dreams within dreams. I want to make a post about how Qubes is exactly like a certain theory of Inception where the whole movie is basically Dom's dream (yes--Dom is dom0) but I'm not sure if qubes-users is the place to post it.

[Peter Thurner]

On 1/24/20 7:54 AM, fiftyfour...@gmail.com wrote:
>> CLIP OS
> I just checked out CLIP OS: If Qubes is like Inception*, wouldn't using
> CLIP OS in it be like going down a level deeper? I'm not a techie, but it
> feels like it'd be really unstable because of technological challenges.
> Really cool if implemented though, even if its government links make it

> *feel* sketchy.

Yeah I also thought about the government link.

When it was initially released to public I read about it on a news site
and setup an old laptop to give it a shot. I stumbled a bit and opened a
few github issues which were answered within hours, so the support seems
to be great, but in the end didn't get it running correctly. But that
was about a year ago or so. Maybe it works better now - we should try out.

I think the question here is what you want to defend against. If you run
a IT company or if you are a freelancer and care about keeping your
customers reasonably secure and you want to protect from 3v1l h4x0rs
trying to get bitcoin from or blackmail you or similar, I think ClipOS
is a good choice.

If you try to defend against governments I think this is tough in
general, as governments (especially the one in the country you reside)
usually can get easy access to your hardware by just breaking into your
apartment. There is little to no real defense against physical access to
your hardware. They can also just install a camera somewhere in your
office to look at your screen, getting completely around all the neat
paranoia you setup on your workstation (PS: there are these "sheets" or
something you can put on your screen to prevent shoulder surfing
(somebody looking into your screen), where you can only see the screen
at more or less exactly the right angle - they are rather cheap:

"laptop screen privacy filter" on amazon.com or similar sites

Also the government can intercept your workstation being shipped to you
by the postal service and install all kinds of nonsense.

Maybe the government should work on giving security to us instead of
developing super hardcore exploits, which then get leaked, which then
cause billions in losses to their own industries xD Anyhow..

I think security in IT is about making yourself a very complicated
target - there is no such thing as absolute security. Hence, I think
ClipOS is a good thing to take a look at and if we can get it running in
a Qube, as the French gov seems to have put lots of resources into it.
Also it is open source so we can review the code.

We can not know if there is an intentional way to 0wn clip OS that its
developrs (the French gov) build into it, just as we can't know if some
gov approached a Qubes or a Debian or Linux Kernel developer and said
"here is 100.000 USD, please put a bug into that piece of software".
Hence I think we should just do the best we can - run Qubes and keep
enhancing it.


Is anyone interested in co-working on getting ClipOS running under
Debian in Qubes? I'd be happy to work together with anyone interested in
this! :) I'm very motivated to get this running to establish a hardened
setup for the actual qubes VMs based on Debian. The end result should be
an automated way to install ClipOS in a qube (like a community provided
template) and then run, say, thunderbird and similar in it, so lots of
less experienced Qubes users can make use of it.

Whos in? :)

[fiftyfour...@gmail.com]

>Threat modelling

I feel that as long as there are enough eyes combing through the code, the risk is dramatically lowered. Major distros (stem distros?) like Debian and Fedora have many, many more people poring over their code compared to something as obscure as CLIP OS. Yes, the government can pressure contributors to CLIP, or even Qubes or Debian, to insert malicious code that's hard to detect, but the legions of Debian users and those of Debian-based distros will likely spot it, the relatively large (*relatively*) pool of Qubes users have a good chance of catching something, but the small number of CLIP users most likely won't--it hasn't crossed that tipping point yet. 

Furthermore, you can't reliably attribute the insertion of malicious code to the government, and even if you did, they'd just shrug it off. Doing things physically (installation of cameras, etc.) is much, much more costly and riskier than doing it digitally. I still think the idea of running CLIP OS in Qubes is really cool and would love to see it; I just think your argument for it wasn't convincing.

Please correct me if I'm wrong about anything I said above, since I'm just speaking out of my ass. I'm neither a security nor a Linux expert--hell, I don't even know how to code. 

[Peter Thurner]

> small number of ClipOS users

Totally legit argument, True ;)

> I still think the idea of running CLIP
> OS in Qubes is really cool and would love to see it; I just think your
> argument for it wasn't convincing.

I totally get your points and generally agree. I still think the current
default of "install whatever you like in a Qube and fully trust the Xen
isolation", like debian with passwordless sudo, is something the Qubes
community should work on in the future. May it be something like
OpenBSD, ClipOS, Alpine or any other solution.

[fiftyfour...@gmail.com]

Wouldn't it be nice if there were community maintained (and vetted) templates for download? Like being able to download something like, say, "taskett_hardened-debian-10"?

A page with examples of Qubes setups would also be sweet--maps of Qubes layouts that users can post and share that are made with a image generator.

[unman]

There is community maintained documentation and scripts already.
It's referred to as "Qubess Community Documentation" in Qubes docs, and
is available at
https://github.com/Qubes-Community/Qubes-Community.github.io
There should be wider knowledge of the site.

unman

[*Null* **]

What about a rolling release model for all qubes like arch linux?

This way there is one static state for all VMs, in their default state.

No need to retool for version upgrades on at least two different distributions, three if you count dom0.

One standard template can be maintained like a service model rather than release based model.

Qube templates could be backed up and branched off from(via clones) as needed by the user.

Devs and others interested would only have one code base to review and improve on.