TODO: come up with the title

https://forum.qubes-os.org/t/how-to-use-the-qubes-admin-policies-api-despite-the-lack-of-documentation-wip/29863

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.

Please note that this procedure has not gone through any qubes-os security review

Step 1: set up the basic sys-gui:

You can set up a sys-gui qube by doing:

qvm-prefs default-mgmt-dvm template fedora-38
(Note: fedora-40-xfce is another option, but sometimes gives a "no such module" salt.{something}.six} error### (also, dont use debian)

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

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). Great. Now quick, log out and log back into dom0 before the screen lock triggers!

(Should we give pointers to documentation on using sys-gui here?)

Should we give something here at this point to give people some sys-gui stuff to explore before moving on to a restricted user? Give me your thoughts.

From basic sys-gui to a restricted user

Give yourself a way to unlock the screen when logged into sys-gui:

Before anything else, lets create a way for you to unlock the screen when you are running 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 /usr/local/bin/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"
then do: 
chmod a+x /usr/local/fix-guivm-password.sh

Then, make a backup of /usr/bin/qubes-guivm-session , and replace it with:

#!/usr/bin/bash -e

USER=`whoami`
if [ $USER = 'user' ]; then
    VM='sys-gui';
else
    VM="sys-gui-$USER";
fi

echo "Throwing away parameter $1 and running $VM as our sys-gui domain instead"

print_usage() {
cat >&2 <<USAGE
Usage: $0 vmname
Starts given VM and runs its associated GUI daemon. Used as X session for the
GUI domain.
USAGE
}

if [ $# -lt 1 ] ; then
    print_usage
    exit 1
fi

# Start VM, gui-daemon and audio
qvm-start --skip-if-running "$VM"
qvm-start-daemon --watch "$VM" &

/usr/local/bin/fix-guivm-password.sh $VM

# Run the inner session (Xephyr) and wait until it exits
exec qvm-run -p --no-gui --service "$VM" qubes.GuiVMSession

(WARNING: /usr/bin/qubes-guivm-session will get overwritten when you upgrade dom0. You can instead call it /usr/bin/qubes-guivm-session.my-version and then change /usr/share/xsessions/sys-gui.desktop to call qubes-guivm-session.my-version instead of qubes-guivm-session)

Now you should be able to logout of dom0, change the upper right corner option on the login screen to "sys-gui" then login again.

This time when the screen locks due to the idle timer, it should be the same password as "user" in dom0 to get back in (hopefully)

add a second sys-gui:

Create a file called "add-new-sys-gui-user.sh" that contains:

sudo qubes-dom0-update mkpasswd

NEWUSER=$1
NEWSYSGUI=sys-gui-$NEWUSER

sudo adduser $NEWUSER --groups qubes,tty

echo enter the password for the new $NEWUSER user
NEW_PASSWORD_HASH=`mkpasswd`
ESCAPED_PASSWORD_HASH="${NEW_PASSWORD_HASH//\//\\\/}"

###todo: if a password for that sys-gui-user vm  is already in there it will create 2.  add a check for that
sudo /bin/sh -c "echo '$NEWSYSGUI:$NEW_PASSWORD_HASH' >> /etc/qubes-sys-gui-user-passwords"
sudo sed -i "s/^$NEWUSER:[^:]*:/$NEWUSER:$ESCAPED_PASSWORD_HASH:/" /etc/shadow
echo password added

sudo /bin/sh -c "sed 's/user/$NEWUSER/' /etc/sudoers.d/qubes-input-trigger > /etc/sudoers.d/qubes-input-trigger-$NEWUSER"

##create the new sys-gui qube
sudo qvm-clone sys-gui $NEWSYSGUI

sudo /bin/sh -c "sed 's/sys-gui/$NEWSYSGUI/g' /etc/qubes/policy.d/50-gui-sys-gui.policy > /etc/qubes/policy.d/50-gui-$NEWSYSGUI.policy"

echo "now create the qubes that this user should have access to and do 'qvm-prefs guivm {new qube} $NEWSYSGUI' for each one"

then do: 

chmod a+x add-new-sys-gui-user.sh;

Then doing:

./add-new-sys-gui-user.sh bob

will ask for a password for bob, then add a new dom0 user login called "bob", create a sys-gui-bob, and set up some basic policies for it. Once that is done, then just like before, pick a color and do something like:

qvm-create bob-work --label orange 
qvm-prefs bob-work guivm sys-gui-bob
qvm-create bob-personal --label orange 
qvm-prefs bob-personal guivm sys-gui-bob
in order to give bob some VM's. Then log out of dom0, select "bob" as the login person, select "sys-gui" from the upper right session list, then type bobs password and you should see a new sys-gui the blue "qubes domains" cube icon in the system tray should acknowledge the existence of the qubes you set sys-gui-bob as the guivm for.

You can confirm you are in bobs sys-gui-bob by right clicking on the desktop, selecting terminal and seeing the hostname of sys-gui-bob.

Ha, tricked you! That's multi-user! You can actually go back to dom0 and do: 

./add-new-sys-gui-user.sh pete
qvm-create pete-work --label orange 
qvm-prefs pete-work guivm sys-gui-bob
qvm-create pete-personal --label orange 
qvm-prefs pete-personal guivm sys-gui-bob

and now you'll have a pete account on dom0 with his own sys-gui. Well more precicely, I'm going to leave things one step short of multi-user. * Currently, all dom0 users can log into a xfce session in dom0. To remedy this, we would need to change the switcher code in /usr/bin/qubes-guivm-session from: 

USER=`whoami`
if [ $USER = 'user' ]; then
    VM='sys-gui';
else
    VM="sys-gui-$USER";
fi
to something like: 
USER=`whoami`
if [ $USER = 'user' ]; then
    startxfce4
    exit;
else
    VM="sys-gui-$USER";
fi
and then delete /usrshare/xsessions/xfce.desktop . All that will take about 5 min. Why don't I make them part of the instructions? Because in the next section we are going to try to actually do something with sys-gui-bob, and the sys-gui generation salt script has been tested with the username "user". This means when things dont work for you in sys-gui-bob, I want you be able to go try doing it in sys-gui when logged in as "user" and see if it works there in the more tested environment.

Actually configuring sys-gui-bob (opening the policies)

The majority of sys-gui's configuration is through qubes policies.

If you run sys-gui-bob and try to load the settings for the work-bob qube, you probably wont be able to (example: try clicking on the "qubes domains" blue cube in the upper right tray, then hovering over "work-bob" and see if the settings shows up. it probably wont).

Why can't we load the settings? Policies! The qubes policy system on dom0 is denying tongs of sys-gui-bob qrexec requests, but we can't see the notifications, cause the "policy denied request" notifications are on dom0!

How do you use policies? Well luckily I just wrote that down in a seperate guide:

https://forum.qubes-os.org/t/how-to-use-the-qubes-admin-policies-api-despite-the-lack-of-documentation-wip/29863

Our solution will be at this part: https://forum.qubes-os.org/t/how-to-use-the-qubes-admin-policies-api-despite-the-lack-of-documentation-wip/29863#p-137862-sys-gui-vnc-with-no-networking-16 (where we log into dom0, then install sys-gui-vnc, then remote into sys-gui-vnc while logged into dom0, and try to create the same problem we are having in sys-gui-bob in sys-gui-vnc, but this time we get the notifications, cause we are logged into dom0 xfce, not a sys-gui!) But you should probably read through the stuff before that to make sure you are in sync with the whole policies thing.

qvm-prefs {some vm} guivm sys-gui-vnc to give it access to a qube

Now you'll start actually getting the policy errors! like maybe this one: admin.vm.feature.List from sys-gui-vnc to debian-12

This is because debian-12 is the template of the qube that i did the "qvm-prefs {some vm} guivm sys-gui-vnc" command with, and sys-gui-vnc doesn't have access to debian-12

Notes:

Note that you can run things in sys-gui-bob with access to 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).

also check the policy files to make sure no unwanted admin permissions have been given to this qube. You can do this with: 

grep -ir sys-gui-bob /etc/qubes/policy.d/ | less
(Note there are more sys-gui policies in /etc/qubes/policy.d/50-gui-sys-gui.policy/include that should to be assessed too)

##### OPTIONAL echo 'optionally, you can give the vm "readonly admin" rights. sudo /bin/sh -c "grep 'sys-gui[^-]' /etc/qubes/policy.d/include/admin-local-rwx | sed 's/sys-gui([^-])/$NEWSYSGUI\1/g' >> /etc/qubes/policy.d/include/admin-local-ro" sudo /bin/sh -c "grep 'sys-gui[^-]' /etc/qubes/policy.d/include/admin-global-rwx | sed 's/sys-gui([^-])/$NEWSYSGUI\1/g' >> /etc/qubes/policy.d/include/admin-global-ro"