From: mark.russ...@net-c.com
To: qubes-users@googlegroups.com
Subject: Qubes with limited user authority
Date: 27/04/2020 20:50:03 Europe/Paris
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
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
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/ea-mime-5eb33ab5-268b-6835a61a%40www-2.mailo.com.
