How secure is a VM if a user tries to tampers it?

[fra...@gmail.com]

Hi!

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.

I would like to propose QubesOS as an alternative, with a Windows VM managed by them inside it, connected to the internal network via VPN (we already have this VPN in place for accessing the internal network while working outside of the building). In addition to this, users could run the operating systems and the applications they want in different VMs, thanks to QubesOS features.

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.).

My question is: how secure is a VM if a user tries to tampers it? Is SGX a technology that can be used to provide that level of security? If so, is it used by QubesOS at the moment?

Any suggestion, comment or link would be greatly appreciated.

Frafra

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2/8/19 10:05 AM, fra...@gmail.com wrote:
> My question is: how secure is a VM if a user tries to tampers it?
> Is SGX a technology that can be used to provide that level of
> security? If so, is it used by QubesOS at the moment?

Currently there is no such feature I'm aware of.

The one who control the hypervisor (dom0) is in "god mode" for all the
guest VMs.


- --
Zrubi
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAlxdS6kACgkQVjGlenYH
FQ1R3g//dBVnG68+O8OZZMEfRdskweSi0J7lQ3Pe1CQz3PFtUyA8L7GFXn9JRMEt
fbloa5duNf6rPbX5FNuxVG4F+uUV0UfhJrPqAL241nY73D7gqfmXEx3Yk0azKLru
MAPCHTrwIPQ3MCWor9d2h2vYyquw5N+3UwtkZIQRHloiobtwbGnAKL7RmCA3kmNq
pEALEVO9JwieVL4PLymrwh+RWiYOYrfVKsyF6d3/MyMf0sSjxGq3MTJ5kg/l4cpY
29o5uOhKKSCX4Um+Fa/DrKC0lxRTqpnSgy1EvIP45n2lxCkQht7NXc9U5+oHnweL
MzMBmQinZs10eK5i8vrkkKsXlX/GmeRiS0D+HZ6ZfCGqKqEW18jhAAiaEVdP2V2a
kxerhWQ3e8wbcqtzuGUH89lfSEc/NMl7A7WWvCrrgaEuYMO72XX7hyojna686MFL
rEshpmkAlLfo3+mSaWMhQkgv0tUyoQ7akdNVMa497moxd5To7tjwyr5iT2ytemaz
AErfjgkMsHx8TqukrtNKPtW3CO+Y2u16aZbnqRom5qWsTXJetsdBZ8jruNPsO3Fm
sqih3xiSTaJ1ocRXuc+hKgJ3O0i0mtYBPgbWhhpLK4uibfN/LGQjFKUS1h2o5XvQ
XYMDdLXGjG9KBe3SILWjJDTzu/mdB8/+NdYSEZNctsVKD9+G58s=
=Crf7
-----END PGP SIGNATURE-----

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2/8/19 10:05 AM, fra...@gmail.com wrote:

> 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.).

Even if they loose the company rules, unfortunately Windows (10)
support in Qubes is not reached that point: No TPM, no audio, no xen
drivers, no file transfer, no USB attach, no copy paste.

The network is painfully slow, probably because of the ancient virtual
hardware provided by the HVM(?)

(The window7 was much more usable in production, thanks to the
qubes-windows-tools package)

- --
Zrubi
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAlxdTpIACgkQVjGlenYH
FQ0m0w/9HAtRErGFo70ornV13PGXqVoHiHSIq5f/S3ST7quyOA6hJlcNyQbPZwps
PAuKOv/Bsyh5JldbUQ4umTTOAABiLfLFcOnbjBBEMUb8ri1rUJ/SVJAmBLVTGs+A
0CTWf2mmv9x4pb5GQogf+uj7yEnlCRYXCy0aZUERvZT1h/2eSnNAyqj+1BLexvaM
folPV5/+LM8tSpwVUSYFUChWyOahu//HscGbh9m3rUjhh/7O5FK97irOk4dxZx+7
ipmQtWwss2mojAVCGx1E+mYJFqVEjH7BnMMVX2H76/9BgBI7LHjPhn41YfMm5dmQ
Vo6DGhEUBkXbgWvFlfdzxFBjXHFmgf0x9/sMBSN/eYDkoOTXmfHLAYHOU7vXsDXK
+DbJmoFbon/zflnLfASbr/YTVeTzSoYn0uGeRMzEtYYjKyVAJAvVHTJPwvEoko5z
PcjoI1o1lw6GRIcC04UPx0iF2jzvGk2ETXr7fty1YTIFLYl5/M4/KjeUni2I1Xko
P3c2iiNIl19FMWsA7vtKLsEDYR3yfzW9lyzEjunaFWaZp6X66MLnuh/p+oPRHd3o
+zmny45Bi2MqNH/FdWm+1GdVgACcvOGijYaJ6gQvqK44CALh54A55HygDgswbGzd
YNOEeeOSjW9BK6KUwZFa/ZMrqJnb+fdpeZkpALfIfkXF1d9Xrkg=
=0yXp
-----END PGP SIGNATURE-----

[qube...@tutanota.com]

Feb 8, 2019, 9:05 AM by fra...@gmail.com:

It shouldn't be an issue as employees were already given a certain level of trust in the organozation, based on their position and competencies. Employee with malicious intent can easily break into the current setup too, like copy and paste, deal with the critical information with malicious intent. Adding Qubes to the trusted setup doesn't make the situation significantly worse. It should, on the other hand, significantly increase the security of the endpoint, if set up properly.

The issue you mention is more about trust in employees, the trust model, than about selected OS in usage.


> --
> 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...@googlegroups.com <mailto:qubes-users...@googlegroups.com>> .
> To post to this group, send email to > qubes...@googlegroups.com <mailto:qubes...@googlegroups.com>> .
> To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-users/c78d47aa-e276-46b8...@googlegroups.com <https://groups.google.com/d/msgid/qubes-users/c78d47aa-e276-46b8-88b0-108a8e55d3f5%40googlegroups.com>> .
> For more options, visit > https://groups.google.com/d/optout <https://groups.google.com/d/optout>> .
>

[Francesco Frassinelli]

Feb 8, 2019, 10:42 AM by qube...@tutanota.com:

> Feb 8, 2019, 9:05 AM by fra...@gmail.com:
>
> > Hi!
> >
> > 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.
> >
> > I would like to propose QubesOS as an alternative, with a Windows VM managed by them inside it, connected to the internal network via VPN (we already have this VPN in place for accessing the internal network while working outside of the building). In addition to this, users could run the operating systems and the applications they want in different VMs, thanks to QubesOS features.
> >
> > 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.).
> >
> >
> > My question is: how secure is a VM if a user tries to tampers it? Is SGX a technology that can be used to provide that level of security? If so, is it used by QubesOS at the moment?
> >
> >
> > Any suggestion, comment or link would be greatly appreciated.
> >
> >
> > Frafra
> >
>
> It shouldn't be an issue as employees were already given a certain level of trust in the organozation, based on their position and competencies. Employee with malicious intent can easily break into the current setup too, like copy and paste, deal with the critical information with malicious intent. Adding Qubes to the trusted setup doesn't make the situation significantly worse. It should, on the other hand, significantly increase the security of the endpoint, if set up properly.
>
> The issue you mention is more about trust in employees, the trust model, than about selected OS in usage.

The problem is that there are cryptolockers, phishing email, and so on, and some users are more vulnerable than others (a developer has a different background compared to an accountant), but it has been decided that is better not to differentiate between users ("your colleague can install whatever you want and you cannot") and keep a stricter security policy allowing only pre-approved OS on the internal network.

Thank you all for your replies,

Frafra

[brenda...@gmail.com]

[To the Qubes team - have there been efforts to support enterprise clients?]

Frafra -

When NxTop was released I did some beta work with them and was sad when Citrix acquired them, renamed the product XenClient XT, stopped considering non-enterprise use cases and then, finally, killed the product. [See slide #8: https://www.slideshare.net/xen_com_mgr/xen-project-15-years-down-the-line ]

Anyway. The open source OpenXT (open source based on the above) is/was designed for the use case discussed in this thread and is the underlying platform of DoD's SecureView environment.

The enterprise-level admin console can:
- Control access to and disable/wipe clients
- Push out Xen/dom0 updates
- Push out VM and/or template updates
- Delete and/or redeploy enterprise owned VMs
- Delete and/or redeploy local user's personal VM (e.g. after malware incident)

Local-machine limited admin console (dom0):
- Refresh or redeploy user's personal VM.

Not sure about VPN functionality external to the VMs themselves (e.g. does it support configurable proxying per VM?). If not, probably best to to segregate VMs by VM-hosted VPNs and the local LAN would always be considered hostile.

In any case, might be worth looking into OpenXT for this. It's a quiet project, not sure how actively maintained, but there is some movement in github.

Brendan

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2/8/19 3:55 PM, brenda...@gmail.com wrote:

> Anyway. The open source OpenXT (open source based on the above)
> is/was designed for the use case discussed in this thread and is
> the underlying platform of DoD's SecureView environment.
>
> The enterprise-level admin console can: - Control access to and
> disable/wipe clients - Push out Xen/dom0 updates - Push out VM
> and/or template updates - Delete and/or redeploy enterprise owned
> VMs - Delete and/or redeploy local user's personal VM (e.g. after
> malware incident)
>
> Local-machine limited admin console (dom0): - Refresh or redeploy
> user's personal VM.

That means total control over the workstaion.
vs.
The initial goal:

"The system administrators would not have to support QubesOS, just the
Windows VM"

This kind of total (enterprise) control was planned for qubes 4.x -
however I don't hear about real life usage.

- --
Zrubi
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAlxdnxUACgkQVjGlenYH
FQ1VgBAAve0JczYJCKLgBvI2VI+BNBneioWbHW5I1uAEnXh5iCU7Xlf1q/by9k2e
F+8lbRV2ZcUrvp0AhNxgcQ/lk0x697m9iOLBB3AnR7NQnjFTDdMAKECAxu9SYKlR
vJIjNuCNquu5SxWvfF3yY6Hd0Cmu8A1CyR8m8Jjhqh3lM+Rnl8Lk4aKlyEJcBu7i
FxvEH4Im938Gr1AKb0eQIBoVCqv+akLOQL0aPjN9+uu6YY3JHIJzkrdy6cFeXavp
dGkVN/gQnzMErC7WlMpVJ4UEYb+NBlbNgiO2FuqsBl3x2Px2YixTmCRUFLet9ktB
WUf4khitV6EJylX2qnBSUYyRnOn+5ZnqAazzdokNzNEmvqGLh53daB7SGIAvqVjj
aem1R2N3R0F+FXifKPkdFhIUuTOw2VTUKEtdMTmT3qZYIUiWN1IpcctsQYPeRCy+
saRL311V+CsPmewV/qNi9KGBPMs5Nif3lXFGHa6ao15xx/zgNeZLDU8/+RW7X3fE
35xKTsYNO7B0o/NUaw0euSNa4cdDFQGcG4pNyAsDR4bU4s03xThasXmTPCC0N9TH
419kReRnv9lexd4nSWI4KMuE8JTlXzc9Zrq9sdvyXRApOaF9WrUiVt8RNSEdyu9Y
hE2yo1BAiZw3ZVLheKvuezsLw53NC7iE0P65GGw9LKoXu9vQ334=
=sAJA
-----END PGP SIGNATURE-----

[brenda...@gmail.com]

On Friday, February 8, 2019 at 10:24:17 AM UTC-5, Laszlo Zrubecz wrote:

> On 2/8/19 3:55 PM, brendan wrote:
> > Anyway. The open source OpenXT (open source based on the above)
> > is/was designed for the use case discussed in this thread and is
> > the underlying platform of DoD's SecureView environment.
>

> That means total control over the workstaion.
> vs.
> The initial goal:
> "The system administrators would not have to support QubesOS, just the
> Windows VM"

Yeah, I don't think you really can do that without sys admin control of the workstation itself...well, not without Intel SGX that works, I suppose.

But your point is taken, my proposal does not meet the criteria...though I don't believe anything available can meet that criteria. :)

> This kind of total (enterprise) control was planned for qubes 4.x -
> however I don't hear about real life usage.

Yeah, I recall reading about that.

Thanks,
Brendan

[Chris Laprise]

On 2/8/19 5:12 AM, Francesco Frassinelli wrote:
> Feb 8, 2019, 10:42 AM by qube...@tutanota.com

> <mailto:qube...@tutanota.com>:
> > Feb 8, 2019, 9:05 AM by fra...@gmail.com <mailto:fra...@gmail.com>:

Thinking about the threat model, qubes-fan's advice makes a lot of sense.

With a regular Windows laptop the company admins are already trusting
you with physical access. That is a lot of power. So the question is why
wouldn't this trust extend to a Windows VM on Qubes, which has superior
protection from any remote attacks?

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[js...@bitmessage.ch]

brenda...@gmail.com:

I think this is what you're talking about?

https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/

The idea was to separate admin and user roles to allow for remote
management in an enterprise environment. That post says that's probably
a 5.0 thing.

--
Jackie

[unman]

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.

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.)."

I read this as saying that the protection from tampering should extend
to OP as well as other users. 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.

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.

[qube...@tutanota.com]

Feb 9, 2019, 3:41 AM by js...@bitmessage.ch:

> brenda...@gmail.com <mailto:brenda...@gmail.com>> :

>
>> On Friday, February 8, 2019 at 10:24:17 AM UTC-5, Laszlo Zrubecz wrote:
>>
>>> This kind of total (enterprise) control was planned for qubes 4.x -
>>> however I don't hear about real life usage.
>>>
>>
>> Yeah, I recall reading about that.
>>
>
> I think this is what you're talking about?
>

> https://www.qubes-os.org/news/2017/06/27/qubes-admin-api <https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/>

>
> The idea was to separate admin and user roles to allow for remote management in an enterprise environment. That post says that's probably a 5.0 thing.
>
> --
> Jackie
>

I think if I remember properly, thierry...@gmail.com <mailto:thierry...@gmail.com> spoke about a project he works here some time ago. It was connected with the remote administration of the QubesOS and he was asking if that was somehow interesting for the community here. Try to check with him. (and post it here, so we know too, lol)

> --
> 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...@googlegroups.com <mailto:qubes-users...@googlegroups.com>> .
> To post to this group, send email to > qubes...@googlegroups.com <mailto:qubes...@googlegroups.com>> .

> To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-users/e8fd48c6-5752-f435...@bitmessage.ch <https://groups.google.com/d/msgid/qubes-users/e8fd48c6-5752-f435-38d3-845c5ffb3a8e%40bitmessage.ch>> .

[brenda...@gmail.com]

Because the company doesn't control dom0.

Typically Management/admins:

a) trusting you with physical access
b) expecting you to limit your behavior, contractually limiting your use of the device and contents (e.g. "do not install non-approved software", "do not connect non-approved devices", "do not sell customer data to third parties",
c) sometimes also monitoring certain logs and/or events that trigger on breaches of some of these demands (as well as on malware), logs that the user are generally locked out of modifying and sometimes even accessing.
d) enforcing at-rest data security policy (e.g. centrally-administered full disk encryption), for corporate or regulatory reasons (E.g. HIPAA).

** Much of the above only reliably works for the company if they control dom0. **

If the *user* controls dom0, the user may become an adversary from their perspective. dom0 can pause/inspect the windows VM, extract/inject data/code, etc., even if the VM has centrally managed encryption within the VM.

That's why OpenXT/XenClient XT/NxTop seems like a better fit for enterprise use, at least from the perspective of the computer/data owner (not the perspective of user freedom, of course).

Brendan

[Chris Laprise]

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.