-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, Feb 21, 2024 at 11:41:54PM -0500, Demi Marie Obenour wrote: > On Thu, Feb 22, 2024 at 04:24:49AM +0100, Marek Marczykowski-Górecki wrote: > > On Mon, Feb 19, 2024 at 10:47:45PM +0100, PeakUnshift wrote: > > > 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. > > > > 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. > > 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?
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----- -- 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/Zdc39RJKcJbBHuf3%40mail-itl.
