Communications of the ACM
Inside risks
Virtual Machines, Virtual Security?
Virtual machines (VMs) are once again a hot trend in system configuration, as demonstrated by the emergence of VMware, Xen, and a renewed interest in hardware assists for virtualization. Some uses are clearly beneficial: virtual machines are great for hosting Web sites and servers because VMs avoid the use of multiple computers to support different applications running on diverse operating systems, while at the same time providing more facile load balancing.
Virtual machines are also touted as a solution to the computer security problem. At first blush, it seems obvious that they should help with security. After all, if you're running your browser on one VM and your mailer on another, a security failure by one shouldn't affect the other. There is some merit to that argument, and in some situations it's a good configuration to use. But let's look a little more closely. To simplify things, let's pretend the two are actually on physically separate machines, and ignore all issues of bugs in the virtual machine monitor, contention for (and denial of service relating to) shared resources, greater complexities resulting from diverse system administration, and so on. All of these are, in fact, real issues, but they're not the fundamental problem.
Most mailers provide a handy feature: they recognize URLs in inbound email, and let the user click on them. The mailer must therefore talk to the browser, and tell it to open a window (although invoking random URLs is very dangerous!). Similarly, some Web pages may invoke the mailer to send mail. A consequence is that the two machines can't be completely separate; some communication must exist between the two. Therein lies the trouble: What is the interface between the two virtual machines? More generally, what is the interface between those components and the rest of the user's environment? After all, people save Web pages and email messages, print them, edit them, and more.
A danger lurks herein. If a buggy or subverted mailer can read and write files without limit, it can commit all of the abuses that today's buggy, subverted mailers perpetrate. It can also commit mailer-only abuses, such as propagating worm-infected email messages.
The desired solution is also clear: the VM's interface to the base system and to other virtual machines must be limited and dependably controlled. Some restrictions must be imposed, some of them possibly complex.
Consider another scenario: suppose the mailer and the Web browser run on a single machine, with separate user IDs from the normal login environment. We could use access control lists on functionality rather than on users to grant the same sorts of permissions and impose the same types of restrictions as in virtual machines. What is the difference? Does the VM overhead buy us anything?
Even with physically separate systems, additional restrictions such as firewalls are generally required. Using virtual machines as a separation primitive can provide some further assurance, which is generally a good thing. That said, access control has been generally reliable in operating systems: very few security holes have involved failures of the permission-checking mechanisms. More problems have resulted from inappropriate allocation of a single privilege level or subversion of privileged or setuid programs.
The incremental benefits of using virtual machines must be carefully considered. If we wish to use isolation of dubious applications as a security primitive, the weak point is the policy specification, not its enforcement. Specifying fine-grained permissions has always been difficult.
Virtual machines can carry a set of disadvantages, too. Even ignoring performance issues, there can be significant administrative overhead. Simple virtual machines require as much configuration work per VM as separate physical machines would. Careful attention to process configurations will be needed to ensure that we do not create worse system administration problems than we have today.
That said, virtual machines do help with one important class of problems: comparatively isolated services. If a service does not require much interaction, little need exists for complex policies. In that case, a VM can be a simpler form of isolation than essentially independent disconnected separate machines.
Footnotes
Note: Particularly relevant in this regard are separation kernels (J.M. Rushby, The Design and Verification of Secure Systems, Proceedings of the Eighth ACM Symposium on Operating System Principles, ACM Operating Systems Review 15, 5 (Dec. 1981), pp. 1221, which indeed could be used as a basis for implementing controlled inter-VM sharing, and recent work on Multiple Independent Levels of Security (MILS). Also, see P. Karger, Limiting the Damage Potential of Discretionary Trojan Horses, Proceedings of the 1987 IEEE Symposium on Security and Privacy, pp. 3237. Peter G. Neumann
©2006 ACM 0001-0782/06/1000 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2006 ACM, Inc.
No entries found