Re: [qubes-users] How secure is a VM if a user tries to tampers it?

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


--

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.

Re: [qubes-users] How secure is a VM if a user tries to tampers it?

[brendan . hoar]

On Friday, February 8, 2019 at 7:07:53 PM UTC-5, Chris Laprise wrote:
> On 2/8/19 5:12 AM, Francesco Frassinelli wrote:
> >  > 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.
> 
> 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?

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

-- 
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/482bb706-c114-46cc-82bc-41531a1a1549%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How secure is a VM if a user tries to tampers it?

[qubes-fan]

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

> brendan.h...@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 
> 
>
> 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.laur...@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+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/e8fd48c6-5752-f435-38d3-845c5ffb3...@bitmessage.ch
>  
> >
>  .
> For more options, visit > https://groups.google.com/d/optout 
> > .
>

-- 
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/LYRMnIB--7-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How secure is a VM if a user tries to tampers it?

[unman]

On Fri, Feb 08, 2019 at 07:07:45PM -0500, Chris Laprise wrote:
> On 2/8/19 5:12 AM, Francesco Frassinelli wrote: > > Feb 8, 2019, 10:42 AM by 
> qubes-...@tutanota.com
> > :
> >  > Feb 8, 2019, 9:05 AM by frap...@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.
> 
> 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?
> 

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 

Re: [qubes-users] How secure is a VM if a user tries to tampers it?

[jsnow]

brendan.h...@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/

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

--
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/e8fd48c6-5752-f435-38d3-845c5ffb3a8e%40bitmessage.ch.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How secure is a VM if a user tries to tampers it?

[Chris Laprise]

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

 > Feb 8, 2019, 9:05 AM by frap...@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.


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

--
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/3d285f7b-a24a-eed0-d85f-0b6ea7bbb4b3%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How secure is a VM if a user tries to tampers it?

[brendan . hoar]

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

-- 
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/eba2c380-8185-4365-8284-6bfe16f98530%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How secure is a VM if a user tries to tampers it?

[Zrubi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2/8/19 3:55 PM, brendan.h...@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-

-- 
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/d116cc58-1a01-4a7f-18e4-4f350045da6d%40zrubi.hu.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How secure is a VM if a user tries to tampers it?

[brendan . hoar]

[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

-- 
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/be2dba37-debe-44c0-b5bc-f49d26ad8df7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How secure is a VM if a user tries to tampers it?

[Francesco Frassinelli]

 Feb 8, 2019, 10:42 AM by qubes-...@tutanota.com:
> Feb 8, 2019, 9:05 AM by frap...@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

-- 
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/CAAXPHZU7QWiBDQtOPv%3Dg0ANFcnP1QAQZ8cnxgZ5e3%3Du0VfCmZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How secure is a VM if a user tries to tampers it?

[qubes-fan]

Feb 8, 2019, 9:05 AM by frap...@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. 


> -- 
> 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/c78d47aa-e276-46b8-88b0-108a8e55d...@googlegroups.com
>  
> >
>  .
> For more options, visit > https://groups.google.com/d/optout 
> > .
>

-- 
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/LYBU9U2--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How secure is a VM if a user tries to tampers it?

[Zrubi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2/8/19 10:05 AM, frap...@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-

-- 
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/f79704db-d6b7-7275-6070-c4b351092624%40zrubi.hu.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How secure is a VM if a user tries to tampers it?

[Zrubi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2/8/19 10:05 AM, frap...@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-

-- 
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/debd5c1e-a3aa-f6fb-d3d3-9ee001ce7572%40zrubi.hu.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] How secure is a VM if a user tries to tampers it?

[fraph24]

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

-- 
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/c78d47aa-e276-46b8-88b0-108a8e55d3f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.