Qubes with limited user authority

[mark.r...@net-c.com]

Hi there

I'm relatively new to the Qubes unique environment and I'm trying to get my head around possible use of Qubes in small/medium enterprise environments, where the system is maintained by an admin and the user freedom is limited by the company policies. I understand that the current Qubes design does not account for any threat coming for dom0's user, I also understand that Qubes is not a multi-user system, I'm not trying to go around this pillar, but I'm trying to identify any usable compromise between a single admin and a single user to live in Qubes happily. The least I would like to protect the system from unintentional abuse from the user, mostly coming from the fact that humans are energy minimizing creatures, and would like to connect internet to vault to avoid few extra operations (for instance).

I'm still absorbing the architecture and its consequences, but I'd like to get the opinion of the developers or how certain things may or may not be accomplished, whether in the current shape of Qubes or in the near future, also whether as an official solution or a workaround to please the stubborn user :)

So I'll try to put it in bullet points:

1- How to prevent the user from coping files between certain domains: my take was Qubes qrexec policies for FileCopy. tested and works as expected (confirmation?)

2- how to prevent the user from attaching devices to certain domains: I'm stuck here as adding rules to admin.vm.device.{block/pci}.attach doesn't seem to prevent me from attaching any device from dom0's command line or from the Qubes devices widget, let alone that the default policy of device.attach is "deny" as the policy files don't have any rule by default. I read in https://www.qubes-os.org/doc/qrexec/#qubes-rpc-administration that "Service calls from dom0 are currently always allowed", I wondered if this explains this behaviour, but I disqualified the hypothesis as I didn't find qvm-device installed in any vm template, hence how could service calls from other than dom0 originate?
so In short, why am I unable to prevent attaching devices to VMs by using admin.vm.device policy files? and what are the developers suggestions to solve this matter?

3- Same as #2 above, but for USB devices, I would like to prevent the user form attaching usb devices to certain vms, but I couldn't find the corresponding qrexec policy files. Qubes.USB is a "deny all" policy already and I can attach any usb to any vm, also I couldn't locate admin.vm.devices.usb for the matter, let alone I failed to use them (as in 2).

4- prevent the user form changing the network gateway of certain vms: I guess it should be done via admin.vm.property.Set, though I haven't tried it. Also, the mentioned policy file is also "deny all" by default and I can still change properties freely. This would probably share same cause with point 2?

5- how to prevent user form changing the policies themselves :) After making good effort in implementing the policy it would be a waste if the user uses the powers of vim to enjoy some freedom. I admit that puts the user in the "not so innocent" abuser and more actively in the threat model, but there are a very small percentage of users who enjoys doing so if they cannot be caught, and securing those policy files from them would reduce the percentage to an acceptable level, where the user had to do extra workarounds "a.k.a hacking" to change policies.
My current understanding is that nothing could be done other than reclaiming the sudo password from the user. I'm aware that the developers are against this route altogether, but wondering what their suggestions to solve this matter.

6- I can relate many of the issues above to the developers current efforts in a separate GUI-domain and reduction of dom0's powers. While I think that effort is definitely a step towards having a seprerable user/admin authorities, I still lack the clear connection between them, as by just moving some powers from dom0 to the GUI-domain will just move the current (points 1-5 issues) from dom0 user to gui-domain user, which again boils down to the login user and their relation to dom0 or to gui-domain. I'm aware that there are many other drivers behind the gui-domain and the authority separation might be just one of them, but I appreciate if the developers could clarify this link between the gui-domain and having clear user/admin authorities such as points 1-5 could be addressed.

7- What is the developers suggestion for customized system deployment on multiple machines? my guess what "customize and backup once, restore many" kind of approach, any comments?

IMHO, Qubes security architecture is built around generalities not specific technicalities, which is a great merit for an architecture, but sometimes poor users (like my self) struggle to connect their little technicalities to the general scheme. I believe that Qubes have considerable potential commercially and professionally if those forward/backward links between the general scheme and daily issues are further  
 clarified and bonded.

Kindest regards,

Mark

[Manuel Amador (Rudd-O)]

On 27/04/2020 20.50, mark.r...@net-c.com wrote:

I'm trying to get my head around possible use of Qubes in small/medium enterprise environments, where the system is maintained by an admin and the user freedom is limited by the company policies. I understand that the current Qubes design does not account for any threat coming for dom0's user,

By design, a user already has root in the machine where Qubes is installed.

If you want to grant users, say, locked remote access to certain AppVMs, you will have to do so remotely by installing something like Qubes network server, and making some of those AppVMs available through encrypted VNC.  Then, by default, they will not be able to copy things between qubes on the same machine.

-- 
    Rudd-O
    http://rudd-o.com/

[mark.r...@net-c.com]

On 27/04/2020 20.50, mark....@net-c.com wrote:

I'm trying to get my head around possible use of Qubes in small/medium enterprise environments, where the system is maintained by an admin and the user freedom is limited by the company policies. I understand that the current Qubes design does not account for any threat coming for dom0's user,

By design, a user already has root in the machine where Qubes is installed.

If you want to grant users, say, locked remote access to certain AppVMs, you will have to do so remotely by installing something like Qubes network server, and making some of those AppVMs available through encrypted VNC.  Then, by default, they will not be able to copy things between qubes on the same machine.

-- 
    Rudd-O
    http://rudd-o.com/

Thank you Rudd-o for the input, good idea indeed! however, it doesn't suite the case in hands.
I'm wondering if the direction the developers are taking in 4.1 and subsequent releases adopts the authorities isolation with the networked model similar to what Rudd-o suggested, or would the GUI-domain helps in providing a less powerful login user, than Root.
As Qubes was designed for a single user/root access, I was wondering what possibly the "best" ugly solution to the problems presented

Mark