Simon Crosby, the founder of the Xen hypervisor announced today about his latest venture called Bromium at a conference. Is it a co-incidence that the name rhymes with the Chromium project from Google? Well, the commonalities are sandboxing and security. While the Chromium project has tried to implement a browser and an O.S based on a browser interface, Bromium will try to implement a layer under the O.S which can run a browser or for that matter any other application.
Virtualization has evolved from being a buzzword to a widely accepted and implemented technology in recent times. VMWare was one of the pioneers of software virtualization. Then, Intel came out with its hardware virtualization concept which resulted in hardware based hypervisors. The purpose of hypervisors is to try and create multiple virtual machines running independent O.Ses on the same physical machine. But, a microvisor differs from this in that it can virtualize applications. Since, sandboxing is at the heart of this implementation, it would mean each of the virtualized applications would be mutually exclusive. Concept-wise, this is very futuristic. If its implemented and accepted by the industry, we might be at the beginning of a new era in application and software security. But, it remains to be seen whether the hype of microvisor lives up to its word.
Bromium's products are built using the Bromium Microvisor. It is a tool that can create lightweight virtual machines, called micro-vms. As many as 150 micro-vms can be created on a typical desktop system with 4GB of memory, it is claimed. The entire tool is about 10,000 lines of code.
To understand the implementation of a micro-vm better, here's a snippet from the whitepaper.
When a micro-VM is created its access to these system resources is restricted according to a set of simple, task and trust-level related resource policies. Whenever the protected task attempts to access any restricted system resource the virtualization hardware forces a CPU VM_EXIT, suspending execution of the task and giving control of the CPU to the Microvisor to arbitrate access using the resource policies for the task.When a micro-VM executes, its (VT-managed) memory map contains a representation of Windows and the necessary DLLs required for execution, plus the task state. Access to OS services is restricted by the resource policies, and any changes that the task makes to OS memory or the golden file system is “Copy-on-Write” (CoW). Thus, if the task is compromised by malware that modifies the Windows kernel or white-listed DLLs, it will only succeed in modifying a local copy, and not the IT provisioned, golden Windows.Each micro-VM is presented a with a narrowed view of the file system that contains only the files it needs – an implementation of the principle of “least privilege” - with CoW semantics. If malware modifies a file, the Microvisor will ensure that it only modifies a copy of the file. Any files modified or saved by a micro-VM are stored efficiently as block-deltas against the original file, which remains unchanged until the micro-VM exits (the user closes a window, or the task terminates). At this point the Microvisor discards the task’s memory image and uses a persistence policy for the task to save relevant task files (if any), and to decide whether to persist any new files. Any persisted files are securely tagged with the trust level of the micro-VM, and all access to untrusted files must be made from within another micro-VM.
No comments:
Post a Comment