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.
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/20240307122113.2839a949%40localhost.
