On 2/9/19 9:59 AM, unman wrote:
It seems to me that Qubes simply doesn't fit the bill, and *does* make
the situation significantly worse.
OP said that:
"The system administrators working in my company do not want to let
user access to the internal network with OS that are not under their
control and they only support Windows at the moment."
In order to give the Windows qube access to the internal network, on a
standard install, the Windows qube would be proxying via sys-net, an OS
"not under their control" so that is a non starter.
One way to work around this would be to directly attach network device
to Windows qube. But what's the point then? Unless one had another NIC
to attach to sys-net which could NOT connect to the VPN(I mean
absolutely could not) then one would not be able to use those other
qubes online.
I'd have to assume they are using a VPN if they are that controlling
about security. Then run the VPN in the same Windows VM which is under
control of the admins. Additional NICs aren't needed.
The other reason that Qubes would not be suitable is this: OP said -
"The system administrators would not have to support QubesOS, just
the Windows VM, but this solution could only be accepted if I am able to
show that there is a reasonable guarantee that tampering the Windows VM
from QubesOS is as hard as tampering the same Windows system installed
on a regular machine (with secure boot, hardware encryption, etc.)."
So this is about locking-down machines to Microsoft-approved hardware
and software. That's what the above means when combined with "no special
steps" requirement.
Simple answer: MS & cronies must supply all the security if they must
control all of it ....and why post this question?
OTOH, if I were the admin of such a work environment, I'd question the
validity of my infrastructure when savvy employees are asking for better
security. I'd also put the issue of employee (dis)trust on my agenda for
some kind of resolution.
On Qubes' end, maybe there is some way the OS can enable a "trust but
verify" workplace model without trampling community objectives.
I read this as saying that the protection from tampering should extend
to OP as well as other users.
I wouldn't disagree with that. But how complete is the mistrust we have
to assume here?
Can OP give that reasonable guarantee? Of
course not. The way that Qubes is structured means that any user would
be able to "tamper with the Windows VM" or subvert any controls placed
on that VM by the company administrators.
A hardened locked down Windows install provides significant protection
against users, who simply do not have "a lot of power". Qubes puts
control in the hands of the user, and that, it seems to me, is exactly
what the system administrators dont want to provide.
Yes, its partly about perpetuating powerlessness... I might say that's
not a good fit for Qubes but really its not a good fit for PCs in
general. To the extent that MS is enabling this kind of control, its
also trying to convert its former PC mantle to mainframes (cue cloud BS).
I'm not saying that it's a complete no go. I have no doubt that it may
be possible to argue about the protection that Qubes provides etc etc, but
I think that any windows administrator would reject it out of hand if
they understood what power it puts in the hands of the user. So frankly,
you'd be trying to mislead them in order to be able to use Qubes.
This "any windows administrator would reject" assertion is pretty
black-and-white. If its true, we're dealing with a tech kakistocracy
that makes decisions in lockstep. How does our community respond to that?
I would like to see Qubes work on validating dom0, which benefits all
use cases, then think about ways of meeting this Windows admin culture
_half_ way.
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
--
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/7b3283ea-d1be-c29f-5995-68a77badc7d4%40posteo.net.
For more options, visit https://groups.google.com/d/optout.
