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.).

SRC=http://www.freepatentsonline.com/y2006/0136910.html