Admin privileges of a GuiVM

[PeakUnshift]

Hello,

When using a GuiVM, several issues appear regarding permission errors. I
created a topic on the forum and opened an issue:
-
https://forum.qubes-os.org/t/grant-full-admin-privileges-to-sys-gui-sys-gui-gpu/24368
- https://github.com/QubesOS/qubes-issues/issues/8934

My message here is more general about what privileges a GuiVM should
have. Currently:
- dom0 is not accessible from sys-gui, but we can CTRL+ALT+F2 to access
tty or login back to XFCE's dom0 session.
- there is no way to access dom0 from sys-gui-gpu because the GPU is not
attached to it.

Then, we need a way to get full admin privileges from the GuiVM:
- Should we grant full admin privileges to the GuiVM?
- Should we grand full admin privileges to a dedicated AdminVM?
- Should we create multiple adminVMs for different tasks, but all
together, give full privileges?
- Is it just a question of policies or is there other development needed
in order to execute dom0 commands from a domU?

I'm aware that the GuiVM is still highly experimental, I try to gather
information in order to clarify the correct path to follow and thus help
future contributions.

Thanks!

[Marek Marczykowski-Górecki]

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

Generally, the goal is to have specific qrexec services for everything
that needs dom0 action, and then grant access to those, based on some
sensible policy (in default GuiVM case, user controlling GuiVM is fully
in control, but there can be a case where there is separate management
VM for some tasks). It shouldn't be necessary to access dom0 shell at
all. In the current implementation, several of those services are
missing. We collect them in this project:
https://github.com/orgs/QubesOS/projects/15/views/1

So, any missing part should get a ticket that we can add to the project
above. In the meantime, some access to dom0 shell is likely useful -
for sys-gui you found it already, but for sys-gui-gpu probably the
easiest way is to setup something like qubes.VMShell. But remember it
gives sys-gui-gpu unlimited access to dom0 - be careful what you install
in the template for that qube and in the qube itself.

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXWvoEACgkQ24/THMrX
1yzQJQgAhGLTcIqVZHyNgSFk/J4QmqbIQFhqOobMYiLuEnTbwXKRawtja8mMzZux
fmAwpgGv7BQxGgCJaAsB1vx7oDlz8Vl3yYKLtJapeSfXrMSHrJEKx0Nmudq3YRD1
QN4VMUkVibVbbUwjbZrwaN+t8S2zCFYkxgky4u9n3a2x18NmD2yO7vOsaSFZVb/p
02kEN/8RQJfbsc2BCp+BiK5LNVIFrjZMZ2Gb/ASJAbiVkMEK/KrtEB5BnritQ+hM
GkuUAiKod/CuJKu09nSmmeMXZN2jANVr9WMic/JR1AlMkOUNLvN6wggD5Iadd1Pm
f+IF2ggy7tb2oVbTzlE/nq5BTxQ7mQ==
=oX8Z
-----END PGP SIGNATURE-----

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I will add that certain parts of the Admin API (such as modifying qrexec
policy) can be used to obtain full shell access in dom0. This is by
design, but is obviously undesirable in certain situations.

Is it possible to have a sys-gui that is powerful enough to be usable,
but which is still considered to be strongly isolated from dom0? Or
does this require features that have not been implemented?
- --
Sincerely,
Demi Marie Obenour (she/her/hers)

Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmXW0JIACgkQsoi1X/+c
IsFmew/9H1VajzSyJMoMdIbzid27R6Zxaycw5ePeGppFDtHCgNEZtcJ/+iNhEAye
DVASqH9NX4K3/aanzqjZmGXwc3HyB5AhnkdhuJfdsSGb1a3VIDdnp++9xwin3Lvb
p3ExBDwu0Dpo8yIspgSB8T6TakuUBdAgYPvsYR+LJ5VbOYA0l6w1StECbJS9Tk2v
v0qRhb0XHaBzFmInNpJ2uY+6hjGIlZ2YJXhQ50ecePuNv4pRO0SZFfhOylS39BaW
OfNMLbFDUIlbuiuYtrpPsR66Zner0EMd5jbrAY/Hw7SPydOgfiUYOUY9RTIAchRS
TPeLQ9im9xQeexForRfA7O5fzXpHoJAbabF596H4M5DH/8+2Is+p//yzk3idnKyJ
0S72CU9o3wvqMkwKlGkaVT2kkConuvKhT/CRi+T/8gZi3Lf/olnKWTS14OGXTVz7
MR9z4wVpuqQyx4iMQl7o8mcZ4cj5sGv6Tw9tWOdWjPH0OvwQILwDyr5L7tW70Vj2
pmoBwaUjcYcJ2+rONNYhd18wSjavOq0OQEC6EcxS1IyUX93LV/GjK6/S6voIYGek
idJjXpzrfmhOqQ/nC+EtigoclMln+iRQ3I97/t0iqCCUpQAHztt2LrVzGdbLEgFH
qgHszeCZp0VoQ5UbuNi7y6evG65FcupEgJ9xCToj8VZPmQS105k=
=YXXj
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

Currently several parts are missing (see above project), but
the goal is to make it possible. I'd like to have enough integration to
support two scenarios:
1. Full control by the user of GuiVM, including all kind of
configuration changes. This doesn't add much security boundary between
dom0 and GuiVM, but should still allow nice things:
- much smaller dom0 (no desktop environment there), possibly base OS
immutable with dm-verity
- updates of desktop environment not tied to updating dom0

2. Limited user - any pre-made qube can be used normally, but user
cannot make changes to any configuration. Possibly cannot also get shell
in templates (only dedicated service to install updates, if not
completely automatic). Configuration can be changed through dedicated
management vm.

There are a lot of options in between, mixed scenarios etc, but some may
require extra features that are out of scope for now.

- --
Best Regards,
Marek Marczykowski-Górecki

Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXXN/UACgkQ24/THMrX
1yz01Qf9HAIHlfzW5/21AbUl7zj413z30lwtzswlSYs21erB3OwhotTZdna4IR74
T3qzc3DWfWQdAep8z7kHwxgftXCZXE0b6heEojcQ7aGGbsTiIv2mx4ZVt87hlyQS
456og0xGTHHFNt0ln889v5Trx+HhAR6b9LH1tyUj0aLkdczU5H/YimlnTB0zzz0V
PJ70dhBCz0YtMpzEXDdYdeGYIes2W1mmI2CeeDaCoiWtfWRP46wOFsFmDYsZywZi
CGHdL3rObybiCC/LlVi8jobTr46SeXLoPxotriaJAZlsYF/RbES//r3PHEBvcYO5
cCWS5M6ur/Rad/WmTagdBsq+kcNssw==
=TP+y
-----END PGP SIGNATURE-----