TODO: come up with the title
Qubes can have a steep learning curve. This means that when you are setting up a system for someone else to use, that explaining qubes in full to them can be difficult.
Here we try to create restricted sys-guis, where they only need to see the parts that pertain to them. Basically a administrative gui login (dom0), and a restricted user sys-gui login.
The restricted user gui login serves the following:
- Cut down the user interface to just the necessary interface to tasks that they need to do
- example: Scrolling through a list of 63 AppVMs to find the correct one is a bit cumbersome for me, and could be confusing to new users.
While the 'find' option is there, that would require explaining, and for them to know the name of the appvm they want and/or the command they want.
(I.E. they cannot use process of eliminiation of the available options to figure out which one they want)
- example: They may not need to see that sys-firewall type qubes connect to sys-net. Instead some users may be better off just knowing about a sys-internet (renamed from sys-firewall for them), and sys-vpn-to-work, and may be better off not even knowing about sys-net on day one.
example: removing the possibility to accidently use sys-net instead of sys-firewall
Put certain administrative abilities behind a seperate gui login/password to force a discussion on the security of doing whatever changes they were hoping to acccomplish before implementing it.
Please note that this procedure has not gone through any qubes-os security review
You can set up a sys-gui qube by doing:
qvm-prefs default-mgmt-dvm template fedora-38
sudo qubesctl top.enable qvm.sys-gui
sudo qubesctl top.enable qvm.sys-gui pillar=True
sudo qubesctl --all state.highstate
if everything worked, you can then:
sudo qubesctl top.disable qvm.sys-gui
sudo /bin/sh -c "sudo grep '^user:' /etc/shadow | sed 's/^user:\([^:]*\):.*/sys-gui:\1/' > /etc/qubes-sys-gui-user-passwords"
sudo chmod 600 /etc/qubes-sys-gui-user-passwords
now create a file in dom0 called /home/user/fix-guivm-password.sh, that contains:
NEW_PASSWORD_HASH=`sudo grep "^$1:" /etc/qubes-sys-gui-user-passwords | sed 's/^[^:]*://'`
ESCAPED_PASSWORD_HASH="${NEW_PASSWORD_HASH//\//\\\/}"
qvm-run --pass-io --no-gui --user=root $1 "sed -i 's/^user:[^:]*:/user:$ESCAPED_PASSWORD_HASH:/' /etc/shadow"
chmod a+x /home/user/fix-guivm-password.sh
Then add this line to /usr/bin/qubes-guivm-session:
/home/user/fix-guivm-password.sh $1
exec qvm-run -p --no-gui --service "$1" qubes.GuiVMSession
Then finally create a qube called work-sys-gui and then do:
qvm-prefs work-sys-gui guivm sys-gui
Then you can logout, then change the upper right corner option on the login screen to "sys-gui" then login again.
You should now be logged into sys-gui. (sys-gui now seems to have a blue hamster as the desktop background). If you look at the qubes available, it's just the work-sys-gui qube.
Now, you can load the settings for the work-sys-gui qube, and you can run things in work-sys-gui with your default network. You can also change the network from sys-firewall (or whatever your default network was) to "none", and network access will no longer be available. perfect.
However, you are not allowed to change network access back from "none" to sys-firewall (or whatever your default network was). This looks like a policy issue! But we have 2 problems now. #1. Every time we want to change the policies, we need to log out and log back in as dom0. And #2 dom0 gets the notifications of what policy was denied when we tried to enable sys-firewall. This takes forever and is not condusive to trial and error.
We will fix those parts now by installing a "useless sys-gui-vnc" that does not have network access (and cant be reached remotely).