Client virtualization, part 2: How client VMs have evolved into current offerings
Vendors and open-source projects alike are using the benefits of client virtualization, while fixing some of the flaws.
My previous post covered client hypervisor concepts, and illustrated some of the potential historical flaws with the story of Citrix XenClient. Now, let’s get back to client virtualization in 2019.
Occasionally, XenClient is mentioned on Twitter and it seems that as time progresses, the sentiments get fonder and more enthusiastic. The problems are acknowledged, but there seem to be more people wishing for a XenClient-like solution today. So, what’s out there?
Many former XenClient team members landed at Bromium, which takes a slightly different approach to client virtualization, whilst retaining many of the architectural benefits. Meanwhile, some very well-funded newcomers have appeared, such as Hysolate. A few niche projects have emerged from the security community, notably Qubes OS. And most importantly, Microsoft has finally acknowledged the value of client virtualization.
This time round, folks aren’t talking about client virtualization for management (we have modern management for that now) but the security focus is still strong.
Microsoft makes some moves
In my opinion, it’s only in the last year or two that Microsoft has really gotten their heads around VDI. Ten years ago, Windows was really a bare-metal OS; it had no built in Hyper-V and none of the trusted root OEM hardware integrations that modern Windows has, such as Intel TXT.
Now, Microsoft actually acknowledges that you can’t secure Windows. For example, a Privileged Access Workstation is a thing, and in their advice on how to run a secure network, they say:
“An administrative virtual machine (Admin VM) is a dedicated operating system for administrative tasks hosted on a standard user desktop. While this approach is similar to PAW in providing a dedicated OS for administrative tasks, it has a fatal flaw in that the administrative VM is dependent on the standard user desktop for its security.”
Basically, Microsoft has acknowledged that with an OS kernel of 40 million+ lines of code, there are inherent security issues. In practice, this means a secure network requires having a separate physical laptop/terminal for your sys admin.
In addition, Microsoft announced Windows Sandbox in late 2018. The idea is that when a someone wants to install an application that they aren’t 100% sure about, they can fire up a sandbox (basically a client VM) and check if it’s OK before using it anywhere else.
But there are still some caveats
I was surprised at how EUC folks got excited about Windows Sandbox. It’s a very basic implementation of what client virtualization is about, and it is something IT pros can already do in about five minutes, usually by copying the app to somewhere not on the main network and firing up a VM using something like VirtualBox. The Windows Sandbox functionality just automates it a bit. It also suffers from the same practical issues as other client virtualization solutions: If you’re relying on end users to actually make the choice to use it, well, good luck!
“Explaining the concept of two types of browser windows—secure and regular—to end users is just about impossible. That is why WDAG [Windows Defender Application Guard, another similar feature] will fail just as XenClient did.”
I agree with this view, and it’s worth noting all the new client virtualization security solutions are finding a way to avoid this choice.
There’s also another issue: an awful lot of malicious applications are deliberately designed to not run—or to run in “be good” mode—if they get any hint they are running virtualized. They do this to make it harder for security folks and antivirus vendors to reverse engineer, fingerprint, and block these nasties. So, a clean result in a sandbox doesn’t necessarily mean a suspect app will be safe on physical systems at a later date.
Not to be completely down on Microsoft, though. Other elements of virtualization-based security have been effectively implemented in ways that don’t require end user interaction. These include Device Guard and Credential Guard, and are important to protect against specific genres of attack. (However, their integration and use cases do have limitations and caveats.)
We’ve already spent a lot of time covering Bromium’s approach to client virtualization, including the Bromium Secure Platform and Bromium’s new Protected Application. These successfully avoid the “which world do I use” choice for end users, and with their new products, they’ve moved beyond secure client VMs to include a zero-trust model where it is assumed everything is potentially hostile.
One of the most interesting points Bromium CEO and co-founder Ian Pratt mentioned was the importance of auditing. They have many customers who simply haven’t had any breaches and this can make customers complacent. Tracking where their products have blocked nasties and the nature of the attacks is a key functionality for evolving the product, and also gives customers a picture of what’s going on.
Pleasingly, Ian also had some good answers on printing infrastructure. Print servers are a notorious weak point, and securing endpoints is futile if your printing infrastructure is insecure. Like many of the remote browsing products we’ve looked at, Bromium has done some work to render documents in segregated OSes, and then pass them on to print servers in formats that can’t compromise the printing infrastructure.
Hysolate is the product on the market today that probably most resembles the original XenClient. Team8, the makers of Hysolate, are a well-backed “think tank and company creation platform” in the Israeli security space. This is particularly interesting as these folks have taken a deliberate decision to enter this market. Team8 definitely is not a VDI company, but rather a security one.
I liked Hysolate; from an architectural point of view it’s similar to XenClient, with multiple VMs available to segregate and secure different classes of data and applications. Whereas XenClient had a trusted and an untrusted VM, Hysolate can have multiple. It's also designed to be fully compatible with any off-the-shelf PC of the last five years, with no HCL needed.
The main difference, though, is in the presentation to the end user; the interface is a single pane of glass to all the VMs, so the end user never makes an explicit decision to work in a corporate/trusted environment themselves.
This means it should be a smooth experience for the user, but can lead to a few different behaviors should admins wish. If the user tries to cut/paste from a window in the corporate VM into another (e.g., to leak sensitive data), and that’s not allowed by the admin-configured policy, they can’t. If they try to visit Facebook in a browser window in a secured VM that doesn’t allow it, another browser window in the internet VM is spun up automatically so that users aren't blocked. If malware on the internet VM takes a screenshot, it won't capture any application windows of the corporate VM.
Another data point around client virtualization is the rather extreme security community established around Qubes OS. This project follows the original XenClient XT architecture, using a modified and enhanced Xen (type-1) hypervisor, and is focused on the Linux market.
Qubes OS evolved from some very well-respected security gurus (folks who’ve broken Intel hardware security in the past) and even endorsed by Edward Snowden. Many of the users are involved in privacy campaigns or the extremes of Bitcoin trading, etc., and as such are very paranoid about security, their ISPs ability to spy on them, or targeted hacking.
I’d put it in the extremely niche basket, though, with the project experiencing many of the same blockers as XenClient. Hardware and peripheral compatibility are significant challenges, and a lack of support, old Xen components, and no certified OS means this is very much a self-support thing. With a crowd-sourced HCL packed with loads of glitches and likely compatibility issues, this is one that most commercial enterprise would probably avoid.
Qubes OS users seem to have niche use cases where the lack of support for standard hardware components, such as GPUs, doesn’t bother them—the community is more tolerant and technical than mainstream enterprise. Their forums are packed with numerous tips on how to dissect, modify, and recompile your OS for customized security.
Overall, this does reiterate that trusted root and the client virtualization methodology is really the “right way” to do security. This feels like a project for techies by techies; however, the results are compelling and attractive.
OpenXT, the open-source version XenClient XT, was embraced via the SecureView platform, which is favored by U.S. military and intelligence communities. One executive I spoke to estimated that this ecosystem had invested tens of millions of dollars in OpenXT.
SecureView was developed in 2010 via collaboration between the security community and U.S. Air Force Research Lab, and is government off-the-shelf software. Given the dates, I think we can guess where the pressure for XenClient XT to be open sourced may have come from!
Who is competitive in the market?
What struck me most about all the execs I talked to was their universal respect for others in this field, as well as their focus on engineering their own genuinely sound technology. I didn’t get the usual EUC product talk hyping up their own solution or criticizing others.
Bromium and Hysolate both have very attractive products which suit different end user workflows and approaches. Whilst we could do a bake off, I think that would rather miss the point (and I hope their sales and product teams or customers don’t make the mistake of debating those two solutions as competitors). The bigger question should be to get the wider EUC/VDI/Cloud community to consider a solution of this genre.
Citrix’s timing and history with XenClient meant they didn’t continue with client virtualization, and VMware never really went in on a security-focused type-1 hypervisor (there were noises but that was it). But, now Microsoft has made it pretty clear with Hyper-V, Windows Sandbox, and Privileged Access Workstation that OS segregation is the way to go; and the mainstream VDI vendors don’t have a great deal to talk about.
End-client security can be weak in many ways, and clearly there’s a vast majority that haven’t yet looked at client virtualization and are a green field market for these products.
For the Citrix/VMware/EUC communities, there are third parties doing bits of extra security at Ring -1 (e.g., Bitdefender’s introspection products), and of course they all have their server virtualization offerings (VMware ESXi, the “Citrix Hypervisor,” etc.), but none of the main vendors have anything that’s really a client VM offering.
Dan McCall, who was CEO of Virtual Computer, worked on XenClient at Citrix, and is now elsewhere in the industry, gave me an insightful, reflective, and rather objective view on the future:
“I will say that there exists clear evidence of market interest for client-hypervisors both then and now and that the biggest issues from the past [were] around technology and the fidelity of the user-experience (which Apple has so eloquently drilled into our collective psyche).
Microsoft and Client Hyper-V is something of a game changer. If it had existed in 2008, we might have seen a very different market develop.
Finally, I would say that beyond server virtualization which is the ‘norm,’ client virtualization is a ‘niche.’ In the case of Citrix and XenApp/XenDesktop a very large important niche solving dozens of use cases. In the case of client hypervisors the niche would appear to be around security more than desktop management. It will be interesting to see how this market re-develops. Maybe we were just 10 years too early with Virtual Computer!!!”
This agreed with everything I heard: client virtualization today is about security, and taking care of everything without forcing the user to decide what to trust.