Minimal minimal templates?

[unman]

There's a recent issues on GitHub (#8980) about removing "non-essential"
packages from the Debian minimal template.

The argument is that minimal templates should contain only "vital packages".
OP argues that a minimal system is one from which nothing can be removed
without breaking anything else, and therefore the minimal templates
should be trimmed accordingly.

Debian has the concepts of minbase and base systems.
Minbase is a variant in debootstrap - it installs only essential
packages and apt.
The base system, or core installation, consists of essential packages,
and those tagged as required or important.

The Debian minimal template is a core system, with some Qubes packages
installed.
In my view the minimal template contains a base system - it contains
packages that any user of Debian would expect to find installed.

The docs say that "The minimal templates are lightweight versions of
their standard template counterparts. They have only the most vital
packages installed, including a minimal X and xterm installation."

It may be that Qubes wants to ship a micro template, with only selected
packages installed, as well as the existing minimal templates. Or trim
down minimal templates to minbase, or smaller.
In either case, we would need to decide what packages should be included.
Any decision should be applied for all official templates.

(I should say that building with minbase in debootstrap makes very
little difference once Qubes packages are installed, and that not all
packages correctly set out dependencies on packages that are assumed o
be present.)

Thoughts would be appreciated.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Generally, I think minimal template should be as minimal as possible,
while still allowing reasonable easy customization. The latter
especially means:
- - working package manager (thanks to updates proxy, it doesn't require
all kind of networking packages)
- - some terminal emulator
- - being able to target with salt (or ansible in the future)

The last two are debatable. Terminal emulator may not be strictly
required since there is qvm-console-dispvm. And also salt is rather
arbitrary choice here, but IMO since minimal templates in practice must
be customized to be useful, being friendly to automating this
customization makes sense (BTW, this is currently broken in Fedora
minimal templates).

If there is some smaller base Debian variant to start from, IMHO it's
worth a try. Currently the main difference is that minimal template
skips installing "standard" task:
https://github.com/QubesOS/qubes-builder-debian/blob/main/template_debian/02_install_groups.sh#L45-L54
and also there is a smaller list of packages to be installed:
https://github.com/QubesOS/qubes-builder-debian/blob/main/template_debian/packages_minimal.list
many of the latter list probably can be removed. If some of those are
actually required by other packages, it should be set in package
dependencies. And if that's isn't the case, it's a bug to be fixed.

Whether to actively remove packages that were installed automatically
but aren't "vital" is another question. I suspect it might be quite
fragile (something that wasn't essential before may become essential at
some point, and thus removing will break stuff). I'd prefer the approach
that prevents installing non-essential packages in the first place, so
dependencies still can do their job. Minimal templates are built with
"no-recommends" option[2] already. But maybe there is some place that
doesn't use that properly and some "recommends" (not "depends") packages
are installed anyway?

[2] https://github.com/QubesOS/qubes-release-configs/blob/main/R4.2/qubes-os-r4.2-templates-itl.yml#L131

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXocJAACgkQ24/THMrX
1yzREAf+K3SnbpqCuQx8zyVyVZP1GqYpcvZ4yAn1+KMisiinpI1/x+3/wmOdP3f7
9AyuNBJ3wVBMgliYWAtQMLdZ2sqyS41KTEQd6BwVvuK9qjYp6cO72GdUdvK1WWbK
1cw6nq0gux+livKIbXjxgyjloABrGmzfG6F5/4QAi/Ce7TrED1DqlTW5RSjqORRj
N8LWY0wZ+oyPn/fTNnNGh4KxZb5Ps+T8fHloK1E2A+N6mcBPkDaAsqvZ0+x2lqCR
FxVgygFjoEo3LJBtjNamzg7ELjwWGDDXoKaYO0AfqIt93i04YNE3TtXh/YTH/QA+
1omKuMoRjIj/0vJV+ACI/mnTYVyvfw==
=tZfX
-----END PGP SIGNATURE-----

[qubist]

Just a little clarification to avoid potential misunderstanding:

> OP argues that a minimal system is one from which nothing can be
> removed without breaking anything else, and therefore the minimal
> templates should be trimmed accordingly.

There is no such argumentation in the opening post. I just said in a
comment that this was my personal definition of a minimal system, which
may apply to the issue or not, i.e. I don't claim it is universal or
that it must be enforced as a principle in resolving the issue.

The actual argument in the GitHub issue is based on the goal of minimal
templates, as described in documentation - reduced resource usage and
attack surface.

> Thoughts would be appreciated.

If it is not too much effort, it would be good to decouple X packages
from qubes/xen, which are dependencies now. This would allow an even
smaller system, which is useful for headless service qubes, which are
more exposed to potential attacks. Additionally, if applied to all
templates, as you suggest, it may turn out beneficial even for dom0 at
certain point in time.

[unman]

On Wed, Mar 06, 2024 at 01:06:50PM -0000, qubist wrote:
> Just a little clarification to avoid potential misunderstanding:
>
> > OP argues that a minimal system is one from which nothing can be
> > removed without breaking anything else, and therefore the minimal
> > templates should be trimmed accordingly.
>
> There is no such argumentation in the opening post. I just said in a
> comment that this was my personal definition of a minimal system, which
> may apply to the issue or not, i.e. I don't claim it is universal or
> that it must be enforced as a principle in resolving the issue.
>
> The actual argument in the GitHub issue is based on the goal of minimal
> templates, as described in documentation - reduced resource usage and
> attack surface.

This is a misunderstanding.
We should *start* by deciding what minimal templates are for,
and what the use case is, and then produce those things. As I read it,
the "goal" is to have lightweight versions of the standard templates -
reduced resource usage and attack surface is a potential effect of this,
not the primary aim. ( I note that that is a fairly recent addition to
the page and is dependent on the clause "When properly configured and
used.." )

>
> > Thoughts would be appreciated.
>
> If it is not too much effort, it would be good to decouple X packages
> from qubes/xen, which are dependencies now. This would allow an even
> smaller system, which is useful for headless service qubes, which are
> more exposed to potential attacks. Additionally, if applied to all
> templates, as you suggest, it may turn out beneficial even for dom0 at
> certain point in time.

That's a separate issue and has definitely been raised before.
Can you spell out which service qubes you see this as being useful for,
(for most users), and how the current GUI interactions , like
NetworkManager, GPG user prompts, etc, would be replaced in those qubes?
Qubes is a constant balance between usability and security - I suspect
that for most users, this would tip the wrong way.

[qubist]

On Thu, 7 Mar 2024 09:16:35 +0000 unman wrote:

> This is a misunderstanding.
> We should *start* by deciding what minimal templates are for,
> and what the use case is, and then produce those things.

OK. That is an important clarification.

Considering the mentioned text in the docs, I have assumed this has
been decided. Now, I understand from you that is yet to be done.

> As I read it, the "goal" is to have lightweight versions of the
> standard templates - reduced resource usage and attack surface is a
> potential effect of this, not the primary aim.

If those are a side effect and not the primary aim, it makes sense to
ask:

- What is the actual aim?
- What does "lightweight" really mean? What purpose does it serve?
- How will users, who have assumed the potential effect is the goal,
react to the goal being swapped with a new one?

Currently, "lightweight" is an abstraction, because it needs to be
evaluated in relation to something else, which is unknown, i.e. there
is no objective measure and without a clear goal that makes the whole
thing sound confusing.

> Can you spell out which service qubes you see this as being useful
> for, (for most users),

Disclaimer: I cannot speak for most users, as I neither represent
anyone, nor I have any data about who uses what and how. Also (as
currently stated), minimal templates are not aimed to be used by most
users but rather by qualifies ones (who know A, B, C and are
comfortable with D).

That said, and considering the important initial clarification, whether
it is useful or not, and for which particular qubes, would depend on the
re/defined goal. My previous reply was based on the assumption of
minimal resource/attack surface, i.e. applicable to all service qubes in
general.

> and how the current GUI interactions , like NetworkManager, GPG user
> prompts, etc, would be replaced in those qubes? Qubes is a constant
> balance between usability and security - I suspect that for most
> users, this would tip the wrong way.

I understand your point. Is it not possible to have the GUI in guivm
(dom0 currently) and get the messages exchanged between the service
qube and the user input in the guivm? For example, I have some shell
scripts in dom0 which accept text as user input, then call qvm-run
based on that input and check error code. Is it not possible to have
similar functionality through GUI with policies?

BTW, another related example, which you might want to consider along
the lines of minimalism and efficiency:

Currently, qubes-core-agent networking installs nftables and iproute2
(and others) as dependencies. Practically, this makes any network
connected qube have the full functionality of a firewall, a router and
a gateway. If more fine-grained compartmentalization ("the qubes way")
should be possible, one may want to separate these 3 functionalities in
separate qubes without having to install unnecessary software.

I am mentioning this, because there may be other similar cases. I have
not investigated all qubes-* packages.

[qubist]

Someone shared interesting info on the forum which might be related:

https://forum.qubes-os.org/t/nanos-unikernel-and-qubes/25496/