BACKGROUND
Computer viruses are a common problem for computer users. One typical mode of attack is to send an electronic mail message (e-mail) containing a file attachment to an unsuspecting user's computer. The file attachment contains malicious attack code, and the e-mail may contain some inducement for the user to launch the file attachment. When the user clicks on the file attachment, the attack code embedded in the file is executed. The attack code accesses an address book and sends the file attachment in an e-mail to addresses found in the address book. The attack code may then try to modify files on the user's computer or obtain other files and mail them back to the attackers.
Propagation of such an attack is rapid. Once one unsuspecting user launches the file attachment, the virus quickly spreads to other unsuspecting users, who then perpetuate the problem. Such viruses have been known to overwhelm computer networks and cause millions of dollars of damage to network operators, companies, and users.
Techniques exist to purge viruses from affected computers. Such techniques, however, are often are used only after the virus has been detected and many computers have been infected. New methods are desired that will slow down the propagation of computer viruses and other malicious code, thus allowing the virus detectors to detect and delete the viruses before the damage becomes widespread.
Along with improving the ability to detect and slow such attacks, it is also desirable to prevent or limit damage to users' systems and access to users' data. The ideal world in which users would never run suspicious files will never exist, so a practical solution must recognize this and attempt to prevent or limit these programs from damaging the user's system and accessing the user's data.
DETAILED DESCRIPTION
Embodiments of the present invention provide a method, apparatus and system for improving security in a virtual machine ("VM") environment. More specifically, various embodiments of the present invention enhance the security on a virtualized device by enhancing the file management scheme on the host. Embodiments of the present invention leverage various aspects of virtualization to enhance security on the VM host. Virtualization technology enables a single host computer (hereafter "VM host") running a virtual machine monitor ("VMM") to present multiple abstractions and/or views of the host, such that the underlying hardware of the host appears as one or more independently operating virtual machines ("VMs"). Each VM may function as a self-contained platform, running its own operating system ("OS") and/or a software application(s). Each VM is thus isolated from the others, ensuring that execution of one VM on the host does not interfere with the execution of the other VMs. The VMM manages allocation of resources on the host and performs context switching as necessary to cycle between various virtual machines according to a round-robin or other predetermined scheme.
FIG. 1 illustrates an example of a typical virtual machine host platform ("Host 100") within which embodiments of the invention may be implemented. As previously described, a virtual-machine monitor ("VMM 130") typically runs on the host platform and presents an abstraction(s) and/or view(s) of the platform (also referred to as "virtual machines" or "VMs") to other software. Although only two VM partitions are illustrated ("VM 110" and "VM 120", hereafter referred to collectively as "VMs"), these VMs are merely illustrative and additional virtual machines may be added to the host. VMM 130 may be implemented in software (e.g., as a standalone program and/or a component of a host operating system, illustrated as "Host OS 140"), hardware, firmware and/or any combination thereof. It is well known to those of ordinary skill in the art that although Host OS 140 is illustrated in FIG. 1, this component is optional (e.g., a "hypervisor").
VM 110 and VM 120 may function as self-contained platforms respectively, running their own "guest operating systems" (i.e., operating systems hosted by VMM 130, illustrated as "Guest OS 111" and "Guest OS 121" and hereafter referred to collectively as "Guest OS") and other software (illustrated as "Guest Software 112" and "Guest Software 122" and hereafter referred to collectively as "Guest Software"). Each Guest OS and/or Guest Software operates as if it were running on a dedicated computer. That is, each Guest OS and/or Guest Software may expect to control various events and have access to hardware resources on Host 100. Additionally, each Guest OS typically includes its own "virtual" file system (e.g., Guest OS 111 may include a file system that only sees files accessible by VM 110). Within each VM, the Guest OS and/or Guest Software may behave as if they were, in effect, running on Host 100's physical hardware ("Host Hardware 150"). In reality however, VMM 130 has ultimate control over the events and hardware resources and allocates resources to the Virtual Machines according to its own policies.
Given the complexity and processing requirements of virtualization, this technology has typically been available only on workstations, servers and/or mainframes for use by sophisticated users. As processor technology advances, however, virtualization is being made available in the desktop environment for use by average users. In this environment, the most likely users are unlikely to be computer professionals (e.g., information technology specialists in corporate environments) but rather less sophisticated users (e.g., home personal computer ("PC") users and/or non-technical, less sophisticated corporate users). The applications that run within the desktop environment and the types of uses for the applications may also differ from corporate applications. For example, one use of virtualization in a home (and the associated advantage of running one or more independent VM's on a host) may be for each family member to be allocated a VM partition with their own customized environment, e.g., a gaming VM partition, a Personal Video Recorder ("PVR") appliance VM, an enterprise Information Technology ("IT") supplied VM for telecommuting, etc. In this environment, the average home PC user may be overwhelmed by the task of understanding and/or managing the VM partitions (e.g., moving files, setting up access permissions, etc.).
Embodiments of the present invention provide for improved security on Host 100 by enhancing file management on the host. An embodiment of the invention also provides improved usability by enabling the user to view the host as a cohesive desktop device (i.e., a non-virtualized host). Thus, for example, in one embodiment, a unified desktop interface and a unified or shared file system may be implemented on Host 100. An example unified desktop interface is illustrated in FIG. 2. Users may interact with Guest Software on a VM host via a unified graphical user interface (the user interface hereafter referred to as "Unified Desktop Interface 200"). In various embodiments, the view presented to the user may resemble a typical desktop, but unknown to the user, the desktop may in fact represent applications executing in various VMs on the host.
As illustrated in FIG. 2, the user may be presented with Unified Desktop Interface 200, which is a logical representation of the views of all or a subset of the various VMs on Host 100 such that the user can see and/or launch applications in one or more VMs from this view. Thus, for example, if the user has access to all the VMs on Host 100, then the various applications in each partition may be visible and accessible to the user in Unified Desktop Interface 200. Alternatively, the user may only have permission to access a subset of VMs on the host, in which case the applications visible and accessible to the user may include only those contained in the authorized VMs. As illustrated, Mail Program 210, Audio Visual Program 220 and various other applications (shown collectively as "Other Applications 230") are presented to the user in a simplified and/or unified view of Host 100.
Unified Desktop Interface 200 illustrated in FIG. 2 is merely an example of an interface that the user may see, in which there is minimal indication that the host is virtualized. In an alternate embodiment, Unified Desktop Interface 200 may include a view of all the VMs as well as all the applications running in each VM. Various other unified interfaces may be implemented without departing from the spirit of embodiments of the present invention. Most importantly, by presenting a unified view to the user, embodiments of the present invention significantly improve the usability of a VM host because the user's experience may resemble that of a typical desktop PC user, namely one in which the user simply selects an application (i.e., Guest Software) on Host 100 to execute, without needing to specifically interact with the virtual partitions on the PC and/or needing to know how to manage the Guest Software files within these partitions. Thus, for example, if the user selects Mail Program 210, as expected, the user may then be presented with the graphical output from Mail Program 210 within Unified Desktop Interface 200 without having to explicitly interact with VM 110.
In one embodiment, in order to maintain the security properties of the system, Unified Desktop Interface 200 may include an indication of which VM each application's interface belongs to. This embodiment minimizes the security implications of malicious software that may mimic an interface of a trusted piece of software (e.g. a corporate database manager) and the user may be tricked into interacting with the malicious software and giving it sensitive information (e.g. passwords, account numbers, etc.). These types of indications may be provided in a variety of ways without departing from the spirit of embodiments of the present invention. Details of these indications are outside the scope of embodiments of the present invention and further details of such indications are omitted herein in order not to unnecessarily obscure embodiments of the present invention. Embodiments of the present invention may, however, enforce policies consistent with ensuring the usability of Unified Desktop Interface 200 (e.g., ensuring that the interface is as close to the standard user experience as possible). Thus, for example, in various embodiments, if all VMs on Host 100 trusted VMs, Unified Desktop Interface 20 may not include any indication of where applications reside. Alternatively, in other embodiments, such indications may always appear if there are applications on Host 100 running in untrusted VMs.
Although invisible to the user, various elements on Host 100 enable the user to view and/or interact with all the VMs on Host 100 via Unified Desktop Interface 200. More specifically, in various embodiments of the present invention, a "service console" (described in further detail below) enables and/or supports the unified interface by redirecting the input and/or output from the user and the VMs For the purposes of this specification, input and/or output shall include any form of input and/or output that Host 100 may recognize. Thus, although "input" hereafter implies that it is a keystroke or a mouse click from the user, it may in fact include any other input scheme that Host 100 is capable of receiving. Similarly, although "output" is described hereafter as primarily being visual output, embodiments of the present invention are not so limited. Output may therefore include other types of output such as audio output.
In one embodiment, a dedicated partition on Host 100 may be designated the service console with access to all the VMs on Host 100. FIG. 3 illustrates conceptually an embodiment of how the service console ("Service Console 300") functions to present Unified Desktop Interface 200 to the user. Although Service Console 300 is illustrated as a separate component from the VMM ("VMM 330"), embodiments of the invention are not so limited. Instead, in one embodiment, VMM 330 may include all the functionality of Service Console 300 while in an alternate embodiment, Service Console 300may be a component that works in conjunction with VMM 330 (e.g., in an embodiment, Service Console 300 may comprise an enhanced VM partition). In various embodiments, input and/or output from the user and/or the VMs (e.g., VM 110 and VM 120) may be received by VMM 330 and passed on to Service Console 300 for processing. It will be readily apparent to those of ordinary skill in the art that Service Console 300 may be implemented in software, hardware, firmware and/or any combination thereof. Additionally, VMM 330 may include various enhancements over existing VMMs, either to include the functionality of Service Console 300 and/or to interact with Service Console 300. It will therefore also be readily apparent to those of ordinary skill in the art that VMM 330 may be implemented in software (e.g., as a standalone program and/or a component of a host operating system), hardware, firmware and/or any combination thereof.
In one embodiment, to enable Service Console 300 and/or Unified Desktop Interface 200 (which represents the output in Service Console 300), Host100 may include a shared file system (illustrated conceptually as "Shared File System 350", contained within Host OS 140). In one embodiment, Shared File System 350 may comprise an extended file system, e.g., existing file systems within Host OS 140 (as illustrated in FIG. 3) may be extended to recognize additional attributes. Regardless of how it is implemented, Shared File System 350 allows files to be shared across VMs, thus enabling Service Console 300 to present the user with Unified Desktop Interface 200 that includes views of the file system.
Operating systems typically include an application (hereafter referred to as a "file manager") that provides users with a graphical or textual view and an interface to the file system (e.g. Windows Explorer™ in a Microsoft Windows™ operating system). Current virtualization software typically creates a separate file system for each VM on the VM host. As a result, the file manager that runs in each VM is only able to see the file system of that VM. A user may therefore be forced to interact with several file managers to access all of the files the user is working with. According to embodiments of the present invention, by providing a shared file system on Host 100 (e.g., Shared File System 350), the user may interact with a single file manager that interfaces with the Shared File System 350 and yet maintains the security properties of the system.
To enable file sharing, Shared File System 350 may include a scheme for annotating all files on Host 100 with an identifier. The identifier may include various types of information such file ownership, permissions, etc. Thus, for example, when a VM attempts to open a file, the annotation in the file system may be examined to determine whether the VM has the appropriate permissions to access the file. Since the annotation determines the permissions for the file, and Service Console 300 handles the underlying tasks of locating the file, launching the file in the appropriate VM and displaying the output within Unified Desktop Interface 200 (i.e., within the context of Service Console 300), the user need not be aware of any of these actions.
Although the above-described scheme increases the usability of a VM host, the ability for users to "share" files across VMs raises various security concerns. As previously described, computer attacks are becoming an increasingly common problem. These types of attacks can result in significant damage to the computer system. Embodiments of the present invention may, however, address the security concerns by providing an additional barrier that slows down and/or prevents the spread of potential damage. For example, in one embodiment, if Guest Software 112 (in VM 110) desires to access a file that is owned by and/or resides in VM 120, it may do so if the annotation in the file system indicates that Guest Software 112 is authorized to access the file in VM 120. Thus, contrary to traditional virtualization schemes whereby files are completely restricted to the VM in which they originate, according to an embodiment of the present invention, Guest Software in various VMs may access files across VMs. Although the action may be handled seamlessly by Service Console 300, this scenario presents a security risk for VM 110 because in the event the file is infected with malicious code, the code may not only infect VM 120, but also VM 110. One way to prevent this type of "cross-VM" infection may be to restrict files to individual VMs (e.g., if the Guest Software has access to VM 110 but not VM 120, the Guest Software may not access any files from VM 120 because VM 110 does not know that the files in VM 120 exist). Unfortunately, this type of restriction may undermine the advantages provided by virtualization, and again, may cause an unsophisticated user to shy away from utilizing a virtual environment.
In one embodiment of the present invention, to enhance the security of the VM host, the annotations in Shared File System 350 may be utilized to enforce various policies. In various embodiments, the annotations may define policies for all activities in each VM, including the types of applications that can be installed in various VMs, what files can be used by those applications, what VMs may access each file (regardless of which VM owns the file), etc. The policies may encompass files that exist on Host 100, files that are created on Host 100, as well as files received on Host 100 from remote sources. In one embodiment, the policies specified by the annotations may be enforced by Service Console 300. Thus, for example, the annotations in the file system for certain VMs may include an extremely strict security policy which does not allow the user to import any files into the VM that were not signed by a trusted party. Additionally, a VM may also have a policy that would not allow a user to export any file to another VM. In other embodiments, various VMs may include a more relaxed policy that allows a user to import data files, but not install new applications. Yet another VM may have an open policy that allows a user to do anything in the VM. Similar to the policy for moving and/or copying files, a policy may also be implemented to monitor movement of information to a "clipboard". It will be readily apparent to those of ordinary skill in the art that the above policies defined by the annotations in the file system and merely exemplary and embodiments of the present invention are not so limited. Instead, embodiments of the present invention may be expanded to include various other types of policies designed to enhance the security of the various partitions on Host100.
Embodiments of the present invention may additionally enable files and data between to be moved between VMs. Because the attributes of a file may restrict the actions that can be performed on that file, a user may wish to change the actions that are allowed for a particular file. The concept of file attributes are well known to those of ordinary skill in the art and further description thereof is omitted herein. Thus, for example, in one embodiment, the annotations in a corporate VM (e.g., VM 120) may define a policy that prohibits the user from running any executable received in email in VM 120. The user may, however, receive an email from his/her IT department that contains a very important executable that is needed to fix one of the corporate applications running in VM 120. According to an embodiment of the present invention, the user may be allowed to do this, unless the IT policies on his/her system completely forbid it. In one embodiment, the user may run a tool in VM 120 that would permit the user to "share" a file by altering the attributes of files to permit them to be accessed by VM 120. To enhance the security of the system, in one embodiment, VM 120 may only "pull" the "shared" file, to prevent untrusted software from "pushing" its files to trusted VMs. The concept of "pulling" and "pushing" are well known in the art and further description thereof is omitted herein.
According to an embodiment of the invention, the annotations may define policies that operate on data other than files. Thus, for example, in one embodiment, the annotations may define a policy that restricts which IP addresses a VM may access. This feature may be used, for example, to create a higher-level policy that allows one VM to only access intranet sites and another to only access internet sites. Another example of how the annotations may define policies that operate on data other than files includes a policy that restricts which devices are accessible, and how, by each VM. Thus, for example, a policy may be defined that only authorized USB devices may be be used by a selected VM. The above described scenarios are merely exemplary and the attributes may be in various other embodiments to define policies that enhance the security and/or usability of VMs on Host 100.
FIG. 4 is a flowchart illustrating an embodiment of the present invention. Although the following operations may be described as a sequential process, many of the operations may in fact be performed in parallel and/or concurrently. In addition, the order of the operations may be re-arranged without departing from the spirit of embodiments of the invention. In 401, Host 100 may receive a correspondence including a file destined for Guest Software in a VM on the host. In 402, VMM 330 may direct the correspondence to the appropriate VM on the host, while in 403, the file in the correspondence may be intercepted by Service Console 300. In 404, Service Console 300 may examine the annotations in the file, and based on the annotations, Service Console 300 may determine an appropriate action in 405 (e.g., deliver the file to the VM, send the file to a different VM, etc.).