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 > > <mailto:qubes-...@tutanota.com>: > > > Feb 8, 2019, 9:05 AM by frap...@gmail.com <mailto: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 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. -- 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/20190209145955.hl655tphorxyj7wb%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
