I am currently testing the sysgui implementation in qubes, so the graphical stack runs in its own virtual machine. However, the Qubes management tools qubesmanager etc. still run in dom0 and are not visible in sysgui, can I get them to appear in the sysgui menus and also be able to start virtual machines through it. Do I need to enable some experimental settings through dom0?
I have installed sysgui according to the instructions on the wiki
No
Is the purpose of qubes to move the entire graphics stack to sysgui, so that qubes-manager and other management tools would also work there, I have understood that they would be made visible by manual synchronization e.g.
qvm-sync-appmenus
Of course this function is still under development, but have I understood it correctly, now I see e.g. the whonix template in the menus, which I cannot start, however
I got the management tools to appear by installing qubes-manager in sysgui. When I try to start firefox in qubes, for example, the window doesnât seem to render on the screen, when I try to use the command line qm-run vm name firefox I get a message that firefox is starting, I thought Iâd try the rc version, would this work any better, has anyone gotten vm windows to run in sysgui
I see that you donât understand system.
QubesOS is highly modified Xen Server.
Xen Server is intended for data center servers to sell virtual servers to customer. It consist two parts: xen hypervisor and domain-0 (dom0). Xen hypervisor runs on bare metal and allows to configure and run virtual machines. Domain-0 is a special, privileged and intertwined with hypervisor virtual machine to configure xen server and itâs user virtual machines - domain-u (domU).
Administrator login to dom0 to configure hypervisor with special xen tools (xl, xenpm, âŚ) but most importantly to make and configure paid virtual machines for customers. Itâs done by ssh or web interface. So normally dom0 have only network stack, firewall, ssh server, ftp server, web server. There is no usb or audio or gfx stack.
If customer buy VM with desktop then itâs going to be virtual gpu than you can do with few tausend dollars gpus.
And you canât create dom0 VM. Ever. Itâs one and only as integral part of Xen Server system.
Going back to Qubes OS.
Itâs highly modified to be⌠desktop system.
At first everything was packed in dom0.
But this is problem as third party drivers canât be trusted and can be attack vector on system.
So more and more parts was chipped away from dom0 to separate domU that started to have special handling.
First network stack, then usb stack. Now itâs time for audio and gpu stack.
sys-audio is in beta stage, can be used daily but few quirks need to be resolved by using third party tools. Itâs working but few thing in order for it to work is community unofficial solutions. Since itâs not fully official and you canât chose it to create during installation then itâs still in development.
sys-gpu is in alpha stage. It display desktop but many things donât work yet. And you canât do anything about it.
So. Back to your case.
You canât move management parts from dom0 to sys-gpu because itâs impossible. Things that donât works is because it wasnât yet implemented.
And then, if you want both gpu stack and management tools in one VM then itâs already in dom0 - then why doing sys-gpu?
1 Like
Thanks for this, I have been running virtual servers with proxmox and I thought I would test qubes, Since I am a completely blind user I use linux with a screen reader called orca, this of course cannot be installed on dom0 because the attack surface would be very large. So I thought about installing orca on sysgui which is a virtual machine among others and using qubesmanager to manage the virtual machines through it. I was wondering if it would be possible to open the virtual machine windows, e.g. firefox, thunderbird etc on sysgui so orca could read them or if this did not work, orca installed inside the app vm would read a specific app vm window. Apparently sysgui does not yet support displaying virtual machine windows, but dom0 is still used for this, have I understood things correctly
This shouldnât be impossible, I think - donât give up yet⌠when I tried last year, sys-gui was able to act as AdminVM for any qube for which it was the creator, by a special tag, or for which (from memory) it was directly configured as the AdminVM. I seem to remember there was policy for both. It was necessary to install templates before it was possible for sys-gui to create new qubes, but then it was fairly usable.
It was interesting to be able to create a qube, but not to be able to touch its NetVM - at the same time it showed the possibilities of separation of privilege and it was very frustrating after using ânormalâ QubesOS. All qubes were - of course - fully accessible in Dom0.
I remember that it was also possible to move sys-net and friends to be visible and manageable in sys-gui, but I donât have those notes right now⌠maybe it was by playing with tags âŚ
Yes, management works very well through sysgui, I tried it and I can create a new VM or change settings, can I still open the VMâs windows or software through sysgui, e.g. firefox, thunderbird, etc. or does this still happen dom0, it would be important for me to be able to open windows through sysgui precisely because of the screen reader support, if I understand correctly the intention is to move all graphical management to sysgui, including the use of virtual machines
No. sys-gui will be display server. dom0 will be a client to it. Thatâs the plan.
Ideally for orca would be to act as serviceVM, but for that, KVM need to be moved out of dom0.
Are you saying that hacking dom0 and sys-gui for it to act as dom0 is more secure than just installing orca in dom0?
I do not know how orca interacts with windows, but with sys-gui, I was using Dom0 only from text console accessed by ctrl-alt-f2.
This gave sys-gui access only to its owned VMs (Appvm, template, disp). If I understood correctly, it did not have any access to the VMs managed by Dom0, even if they were used as NetVM by some appvm.
sys-gui takes the place of Dom0, but only for some management tasks of its own VMs.
If there is a risk from orca, and if orca must be in the same VM of the desktop, then this seems to improve security because orca can only escape into sys-gui managed VMs. Dom0 is still taking care of policy, and all other management of Qubes-OS.
It was not obvious how to arrange service qubes. If they stay in Dom0, then it was necessary to log out of sys-gui, log in to Dom0, only to use the USB widget. Or else only use the text console⌠More secure but inconvenient and painful!
I stopped playing with it because I did not find a way to have two or more simultaneous running desktops. This was my imagined solution:
- one for Dom0 which manages sys-usb, sys-net, and others, including backups.
- another for work qubes, in their own sys-gui, where I could allow colleagues to play without risk.
- Ability to ctrl-alt-Fx for switching.
Maybe there are better waysâŚ
I personally thought that sysgui would display the virtual machine windows, so it would take care of the graphics stack, dom0 would not install anything extra, no orca or anything else because it would increase the attack surface. Each virtual machine would run its own version of orca unless orca could read the virtual machine windows running in sysgui, this needs to be tested. Unfortunately, it is not possible to use dom0âs virtual consoles without installing some kind of speech support dom0 speech-dispatcher etc., so all management and displaying the user interface should be done from sysgui. I am NOT a security expert and I am also looking for the safest option to minimize the attack surface, dom0 is intended to be kept clean. What is the future development of qubesos, I have understood that dom0âs role would only remain as a hypervisor and some kind of management console, i.e. everything else would be moved to work in different virtual machines, graphics, drivers etc.
edit
Actually, dom0 doesnât need to install any accessibility support if I just want to get its virtual console working. Orca already runs in sysgui so the only unresolved question is whether I can get the virtual machine windows to run via sysgui as well, management is done with qubesmanager and via the console by logging in dom0
This was fixed recently but only for Qubes OS 4.3 I think, HVM qubes did not display in non dom0 display.
Great, so this is a known issue, the virtual machine windows can be made visible in sysgui, itâs just a pure bug.