On-demand disposable virtual work system

An on-demand disposable virtual work system that includes: a virtual machine monitor to host virtual machines, a virtual machine pool manager, a host operating system, a host program permissions list, and a request handler module. The virtual machine pool manager manages virtual machine resources. The host operating system interfaces with a user and virtual machines created with an image of a reference operating system. The host program permissions list may be a black list and/or a white list used to indicate allowable programs. The request handler module allows execution of the program if the program is allowable. If the program is not allowable, the host request handler module: denies program execution and urges a virtual machine specified by the virtual machine pool manager to execute the program. The virtual machine is terminated when the program closes.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1is a block diagram of the architecture of an aspect of an embodiment of the present invention.

FIG. 2is a block diagram of the architecture of an aspect of an embodiment of the present invention.

FIG. 3is a block diagram of an aspect of an embodiment of the present invention.

FIG. 4is a block/flow diagram of an aspect of an embodiment of the present invention.

FIG. 5is a diagram showing on-demand virtual machine cloning as per an aspect of an embodiment of the present invention.

FIG. 6is a diagram showing the redirection of online sessions as per an aspect of an embodiment of the present invention.

FIG. 7is a diagram showing message passing as per an aspect of an embodiment of the present invention.

FIG. 8is a diagram of a request handler module as per an aspect of an embodiment of the present invention.

FIG. 9is a diagram of an example file system as per an aspect of an embodiment of the present invention.

FIG. 10is a diagram showing persistent storage access as per an aspect of an embodiment of the present invention.

FIG. 11is a diagram of a virtual machine pool manager as per an aspect of an embodiment of the present invention.

FIG. 12is a flow diagram of the creation of a virtual machine image as per an aspect of an embodiment of the present invention.

FIG. 13Ais a flow diagram of the download of a software patch as per an aspect of an embodiment of the present invention.

FIG. 13Bis a flow diagram of the updating of a virtual machine image with a software patches per an aspect of an embodiment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS

Embodiments of the present invention are designed to effectively eliminate most Internet-enabled compromises of computer system security. The system and approach present a radical departure from current information security tools and practices and current computing practices. Where today's information security tools and practices focus either on building better software or filtering mechanisms such as firewalls to prevent remote exploitation or building tools to detect compromises, the invention described here provides a safe environment for running Internet-connected software and obviates the need for perfect software. The system provides an environment in which intrusions or compromises present a limited threat to the host system or other software and user data.

The embodiments work by launching a virtual machine for each Internet-enabled or untrusted application that is started. The virtual machine provides a pristine guest operating system (OS) for the Internet-enabled or untrusted application that is launched. This operating system may be an operating system unmodified from the original version delivered by the manufacturer or other version suitably configured for the task of running intended applications. The virtual machine and its guest operating system may be temporally limited to exist only for the duration of the session of the application. When the user exits the application, the virtual machine can be destroyed. For the duration of the session, the virtual machine provides an isolated environment from the host machine from which it is launched. The virtual machine provides a level of isolation from the host machine that is the equivalent to running a physically separate machine from the host machine. The virtual machine is essentially a sacrificial machine that lives only for the duration of the application session. Any attacks that occur on the machine via an Internet connection can compromise only the virtual machine that is started up for that session. When the session is terminated, so is the virtual machine and the compromise. With each new session, a pristine new virtual machine is started up, meaning that any malicious software that was downloaded or planted during a prior session is no longer present. The underlying host operating system does not need to maintain an Internet connection. As a result, Internet-based attacks have a very limited ability to compromise the host operating system.

Embodiments of the invention can also implement persistent storage mechanisms for the cases that data either needs to survive the destruction of a temporary virtual machine or needs to be communicated to an entity external to the temporary virtual machine. Access to persistent storage may be made using an authentication procedure to prove to the system that the access is approved by a user and not a malicious program. Alternatively, access to persistent storage can be made by creating a shared directory to the host operating system, but restricting guest operating system access only to the shared directory on the host operating system. For high assurance, the authentication mechanism may be as simple as a mouse click in response to a dialog box, or as complex as a detailed Turing test.

Using the presently described technology, users may no longer have to worry about securing their systems with additional tools (such as firewalls, personal firewalls, spyware detectors, rootkit detectors, and intrusion detection systems), or even patching their systems with the latest daily or weekly patch from the software manufacturers to patch the latest bug in their software system. However, it should be noted that this system is not incompatible with these tools and can use these tools to provide health status information on the virtual machines created for an application session. This represents a radical departure from current arms race between computer system attackers and defenders. In addition, it presents a new computing paradigm for desktop operating systems. Currently, Internet-enabled applications run side-by-side with all other desktop and system software with the privileges of the user. As a result, when a compromise occurs through the Internet, the entire system can be compromised by a single vulnerability in an Internet-enabled software such as a Web browser or an email client. By simply browsing to a Web page, a user can compromise their system. By downloading music or music players, a user can compromise their system, sometimes irreversibly.

Using embodiments of the present invention, Internet-enabled applications can each run on their own instance of a guest operating system with a new user's privilege isolated from the host operating system and from other applications and data. As a result, any compromises that may occur during the time window of the session is contained within the guest operating system out of reach of the host operating system and persistent data. Any software that is downloaded during that session can be run without worry of compromising the host operating system or data. This includes spyware, rootkits, and other types of malicious software. Any sort malicious mobile code that runs in the Web browser should only last only for the duration of the session. Even viruses embedded in documents should not have access to other documents, nor should they persist past the duration of the session. At the conclusion of the session, the guest operating system is killed as the virtual machine exits. All changes to the software system are only temporary as the next time an application is launched a pristine version of the guest OS is created.

Architecture

The approach to building the on-demand disposable virtual work system uses core technology building blocks in a novel computing paradigm involving dispatching temporary operating systems for each untrusted application. That is, instead of launching the application natively from the host operating system, untrusted applications may be started by first launching a guest operating system in a virtual machine that then starts the untrusted application. Untrusted applications, by default, can be any application that requires Internet access or any application that is not on an organization's approved list of trusted programs. The invention, through this method, handles the creation and management of virtual machines and the automatic re-direction of applications to start in the virtual machine created for them.

FIG. 1shows the architecture of an embodiment of the present invention. The off-the-shelf components are commodity microprocessors, operating systems, software applications and virtual machine technology. The design can use commodity personal computer110containing microprocessors including those based on the Intel/AMD x86 family of microprocessors and the PowerPC microprocessor. The architecture uses the notion of a host operating system144and guest operating systems (164,174and1940) that are launched with each protected applications (162,172and192). The architecture may support a variety of commodity operating systems including Windows, Linux, and Mac OS, in both the host operating system and the guest operating system. In some cases you may run a Linux operating system as a guest operating system on top of a Windows host operating system, and vice versa. The choice of operating systems to use is determined by the applications to be launched based on the operating system for which they were built. That is, Windows guest operating systems are launched when a Windows protected application is started and Linux operating systems are launched with a Linux protected application is started. Finally, the architecture may use commodity virtual machine technology such as the Xen virtual machine monitor (VMM) and VMware virtual machine monitor. Xen is a virtual machine monitor for IA-32, x86-64, IA-64 and PowerPC architectures. It is software that runs on a computer system110and allows one to run several guest operating systems on top of the host on the same computer hardware at the same time. Copies of Xen may obtained from www.xensource.com.

The embodiment of the architecture shown inFIG. 1uses the standard virtual machine architecture with the Virtual Machine Monitor (VMM)130running on the hardware110, and operating systems (144,154,164,174, and194) running on top of the VMM130. A host operating system (OS)144is defined as the default machine the user normally uses and is the machine whose desktop is presented to the user. Guest OSs (164,174and194) are created by request when a protected application (162,172and192) is launched, or created in advance to enable higher performance when launching protected applications (162,172and192) into pre-instantiated guest OSs (164,174and194). A Management VM150may be bootstrapped along with the Host OS144and a reference guest OS145that is used for clones of the guest OS reference image145. The Management VM150is used for command, control, and lifecycle maintenance of the guest OSs (164,174and194) based on the instructions from the host OS144. The number of guest OSs instantiated may be dependent on the number of protected applications launches and the performance limits of the underlying hardware. The VMM (130) and VM (150) should support live capture of the full system state in a file for subsequent replay. This file is called a “snapshot” of system state.

The host operating system144may be configured for higher security so that it is unable to make Internet connections itself. This can be enforced by a loadable kernel module, a personal firewall, disabling the network protocol stack of the host, or other means to restrict the IP address space to which network connections can be made or accepted. The loadable kernel module should guarantee that no application on the host machine140can communicate to the Internet. The guest operating systems (164,174and194) may be free to make direct Internet connections; however, they should be restricted from freely accessing the host operating system144by the virtual machine monitor130that runs in its own hardware protection domain which provides hardware-equivalent strong isolation between the virtual machine and its host operating system. The guest operating systems (164,174and194), which are pristine builds of the OS, should also be “root secure”, which means that even if one of the guest operating systems (164,174and194) is compromised to a root user level or the kernel itself is compromised, the host operating system144itself should not be compromised by the compromised guest operating system. Once a guest operating system is destroyed (upon closure of the protected application that started the guest OS), the compromise is now removed from the system.

As mentioned earlier, a reference guest OS145may be booted along with the host OS144. A snapshot of the reference guest OS145may be taken, then used to derive subsequent VM images by cloning it, i.e., creating a replica image of the reference guest OS. When a new untrusted application is to be started, a dispatch instruction is sent from the Host OS to the Virtual Pool Management Machine150, which then creates a VM for the application using the reference guest OS image, if the VM has not already been created. By cloning and pre-booting reference images, the response time for instantiating the application should be on par or even faster than the usual response time for starting a new application for users.

Concept of Operation

Embodiments of the present invention should be largely transparent to the user in look, feel, and operation. That is, the user need not be aware of the virtualization operation and its commensurate protections, except for authenticated reads and writes to and from persistent storage from protected applications. The system should boot as normal with the native operating system as well as loading the VMM. The guest OSs should be relatively invisible to the user, i.e., they run in the background. The user operates the computer as he or she normally would, with the exception that no Internet connections to the host operating system may be allowed. When the user launches a “protected” application, that is one defined in the IC configuration file as “protected”, then instead of launching the application, the application may be dispatched to one of the guest OSs running in the background. Protected applications are nominally those defined with Internet access, but may include other applications as configured by the user to run in Guest OSs including standard desktop computing applications. Applications not configured as protected, should run natively in the host operating system (144).

When a protected application is launched, whether directly from the desktop by the user, by double-clicking on a file with an application association, or by any other application or other means, the process can be dispatched to the guest operating system, and the corresponding application launched in the guest OS. The fact that the application is running in a guest operating system should be largely transparent to the user, except for a possible windowing designation that indicates the application that in is running in the protected mode environment, i.e., the guest operating system. The guest OS may be created with application launch or may already be instantiated and destroyed when the application session is complete or when the user terminates the virtual machine.

As described earlier,FIG. 1shows an embodiment of the present invention where virtual machines monitor130runs direct on computer hardware110. In this embodiment, every machine (140,150,160,170and190) is essentially a guest machine to the computer hardware. In this setup, the unprotected host applications142run on the host machine140natively and the host operating system144runs these applications142. In contrast, the guest virtual machines160,170and190run protected applications (162,172, and192respectively) that may talk to a network under guest operating systems (164,174and194respectively).

The guest operating systems164,174, and194are each cloned from one of the guest operating system image(s)145. The images145should be pristine snapshots of a running operating system. To increase speed, the snapshots may also include running applications. For example, an image145of an operating system for an email virtual machine can include a copy of an email application running under the operating system.

The virtual pool management machine150runs a series of virtual machine management utilities152under a management operating system154. These utilities152include functions that: create, destroy, put to sleep and wake up virtual machines. The utilities also maintain a list that matches applications to virtual machines. In other embodiments, these same functions may be performed by pool management utilities running on a host machine. For example, inFIG. 2these functions are performed by virtual machine pool manager246.

FIG. 2shows an embodiment of the present invention demonstrating some possible variations from the embodiment ofFIG. 1. As shown in this figure, the virtual pool management machine150inFIG. 1has been replaced by virtual machine pool manager246running on the host machine240. Virtual pool management machine150and virtual machine pool manager246may perform essentially the same functions. However, inFIG. 2, these functions reside solely on host machine140.

As inFIG. 1, this embodiment also includes: a virtual machine monitor130running directly on computer hardware110; a host operating system144; and a series of guest virtual machines160,170and190. The host machine140should not be connected to any networks.

Additionally, the embodiment ofFIG. 2includes the addition of persistent storage258. The idea behind using a persistent file storage258is to enable the temporary virtual machines to save any documents or data that may be needed later. The persistent file storage258may also be used as a mechanism for safely passing information between the temporary virtual machines. In this embodiment, the persistent storage drive258is accessed through a persistent storage machine250. In this embodiment, the persistent storage machine is a virtual machine file server running a persistent storage operating machine. Commercial file server software may be used in virtual machine250. File server software for Microsoft Windows machines may be obtained from Netpro, Inc. of Phoenix Ariz. and file server software to run under Linux may be obtained from Redhat Inc. of Raleigh N.C. This is only an example of how persistent storage may be implemented. For example, one could utilize a stand alone persistent file server or the host operating system's file system. Additionally, persistent file storage may be located anywhere in the organization on the network.

FIG. 3shows another embodiment of the present invention where the virtual machine monitor130is running on the host operating system144rather than directly on the computer hardware110. In this embodiment, the host operating system desktop software322is used to interface the user with the system as normal, and a series of guest virtual machines250,160,170,380and190. The desktop322is running on the host operating system144. The host operating system is running on the computer hardware110and the virtual machine monitor130is running on the host operating system144. The guest virtual machines250,160,170,380and190run in virtual machine environment controlled by virtual machine monitor130.

Each of the virtual machines has their own guest OS (254,164,174,384and194respectively) which was cloned from one of the reference OS image(s)145. Although reference image(s)145are shown residing with the host operating system144, one skilled in the art will recognize that these image(s)145could be located elsewhere. For example, they could be stored directly in the computer hardware110memory or in an external disk drive or other type of persistent storage device accessible by the host operating system144.

As shown, several of these guest machines are dedicated to specific applications. Machine250is dedicated to file storage, machine160is dedicated to web applications162, virtual machine170is dedicated to email applications172, virtual machine380is dedicated to Microsoft office applications382, and virtual machine190is dedicated as a “catch-all” machine to run applications192not dedicated to other machines. The designation of protected applications to guest machines is configurable by users.

Recall that the host desktop322does not need to be connected to a network. So, if a user tries to run an application on the host desktop322that requires network applications, it may not be able to access the network.

The way the system works, a user interacts with the host desktop322. The applications on the virtual machines run in the background. When a user goes to run a host allowable application (usually a non-network application), that application is brought to the forefront of the display and run on the host operating machine144. When the user goes to run a protected application (usually a networked application), then that application should be intercepted and redirected to a virtual machine dedicated for the application. The application may then be brought to the forefront of the desktop322as it is run on the guest virtual machine. If there is no virtual machine dedicated for the application, then the applications may be redirected to the catch-all virtual machine190. In some embodiments, the redirection of unspecified applications to a catch-all virtual machine190can be optional, directed by a set of rules, or not allowed at all. In some embodiments, the option to auto-restore the guest virtual machines on a count-down timer is provided. After a user-specified countdown timer times out, the Internet Cleanroom software will automatically restore the guest machine back to its pristine state to ensure periodic cleansing of the machines to their initial pristine state. These options can provide differing levels of security.

FIG. 4is a diagram shows an example of how an application requests can be directed to an assigned machine. Several new elements that are part of the system are shown in this diagram. These new elements include optional white lists (442,462,472and492) and request handlers (448,468,478, and498).

The white lists (442,462,472and492) list applications and services that are allowed to execute on the machine in which they reside. For example, white list442, which resides on the host desktop, does not list any internet applications, but does list local services and non-netted applications. White list462which resides on virtual machine160lists several internet browser applications as well as local services and non-netted applications. White list472which resides on virtual machine170lists several internet email applications as well as local services and non-netted applications. White list972which resides on virtual machine190is a catch-all machine, and as such does not exclude any internet applications. These limitations defined in the white lists are examples. A system could be set up to list any desired applications to run on a virtual machine. Described here is just a suggested configuration.

The request handlers (448,468,478, and498) perform several functions (not necessarily in the following order). First, they intercept system calls. Second, they determine if calls should be forwarded. Third, where the calls should be forwarded. And fourth, the request handlers forward the calls. To determine where the calls should be forwarded, the request handlers (448,468,478, and498) may examine white lists on their machine (442,462,472and492respectively), and the virtual machine pool manager246.

In this example, a user, interacting with the host desktop332generates a request443to start up an instance of Internet Explorer at401. This request is intercepted by request handler448at402. The request handler448inspects white list442at403and learns that Internet Explorer is not allowed to run on the host144. The request handler448then queries the virtual machine pool handler246for a virtual machine to forward the request to at405. In this example, the virtual machine pool handler246determines that the request443should be forwarded to virtual machine160. If virtual machine160was not running or awake, the virtual machine pool handler246may send commands to the virtual machine monitor to create or wake up the machine160. Once the virtual machine pool manager246believes virtual machine160is running, it responds back to request handler448to forward the IE request443to virtual machine160.

At406, request handler448forwards the IE request443to the guest operating system164on virtual machine160. The guest operating system164then forwards the IE request443to request handler468at407. Request handler468which will forward the request443to request handler468. Request handler468inspects white list462at408and learns that Internet Explorer is allowed to run on the virtual machine160. Based on this knowledge, request handler468allows the guest OS to start an instance of IE (463) at409.

FIG. 5shows the creation of on-demand virtual machines (552,554,556, . . . ) to handle all of the various applications that need to be run. The system starts out with at least one master virtual machine image510. These images should be pristine snapshots of running operating systems. In some cases, the snapshot can include a running application.

At520, copies of the virtual machine images510can be cloned onto the appropriate virtual machines532,534, and536. Once the machines are cloned, the operating system may be booted and an appropriate application launched to make the virtual machine an application specific virtual machine. For example: cloned virtual machine532can be booted with an OS and a browser launched at542to generate a browser application specific virtual machine552; cloned virtual machine534can be booted with an OS and an email application launched at544to generate an email application specific virtual machine554; and cloned virtual machine536can be booted with an OS and one or more office applications launched at546to generate an office application specific virtual machine556.

For the sake of temporal efficiency, several virtual machines may be started on a system and then put to sleep by the virtual machine manager130until they are needed. This may be a more efficient method of running a system due to the fact that waking up a virtual machine may take less time than creating one. Finally, the virtual machines552,554, and556may be disposed of at560. This disposal may occur at different times such as after the applications are closed, by user request, or after a predetermined time limit. Disposal may be done by numerous methods including reverting the virtual machine back to its initial state or destroying it completely. In some cases, a user may wish to examine the virtual machine for possible contamination after running it. In this case the virtual machine image may be moved to a secure site for examination.

“One program at a time” means dedicating a virtual machine to an application or type of application. So for example, if we wish to dedicate a virtual machine to mail applications, then this machine will be assigned to run as many mail applications as a user may desire. This may be a single instance of a mail application, or multiple instances of the mail application. Using this scheme, all mail interactions with an external network will be through a virtual machine dedicated to processing mail applications.

FIG. 6shows how a request handler can redirect an application execution request. When you initiate an application request, either on the host or on a guest Virtual machine642,644, or646, that application request can be intercepted. Interception may be performed using numerous utilities. An example of a program that can be used to intercept requests on Microsoft windows machine is Microsoft Detours. The intercepted messages610may be redirected to the dispatcher620. The dispatcher620may use a program permissions list (either host program permissions list or guest program permissions list as appropriate). The program permissions list may be a white list650, a black list652, or some combination thereof. In the case of the white list650, the dispatcher620may compare the redirected execution request610with the white list650. If it's determined that the application associated with the execution request610is not on the white list650, the intercepted messages610is redirected to the appropriate virtual machine (642,644, or646) using a remote invocation call630. This is done by the dispatcher620call for the application to run on a remote machine by talking to a dispatcher on that remote machine. In the case of the black list652, the dispatcher620may compare the redirected execution request610with the black list652. If it's determined that the application associated with the execution request610is on the black list652, the intercepted messages610is redirected to the appropriate virtual machine (642,644, or646) using a remote invocation call630. This is done by the dispatcher620call for the application to run on a remote machine by talking to a dispatcher on that remote machine.

If a white list650is in use and it is determined that the application associated with the execution request610is on the white list650, the intercepted messages610are directed to the local machine's operating system for execution. If a black list652is in use and it is determined that the application associated with the execution request610is not on the black list652, the intercepted messages610are directed to the local machine's operating system for execution.

FIG. 7shows more detail on the communication pathways between the host machine140and the guest virtual machines (160,170and190). Although the communication channels may utilize many different techniques, this embodiment is showing the use of pipe servers and socket servers. The request handler448on the host is a client that is used to send requests to the virtual pool manager246and to the guest request handlers468,478, and498. When a request to run a local application743on the host is generated, the request743is directed through a logical pipe745to the host request handler448. The host request handler448inspects the host white list442to determine if the application specified by the request743is allowed to run locally or of it needs to run remotely. In general, applications that are not capable of accessing a network will be allowed to run locally while applications that are network access capable will be required to run remotely. This can be accomplished by keeping network access capable applications off the host white list442.

In the case that the request743is requesting an application that is not on the host white list442, the host request handler448will communicate with the pool manager246through an internal pipe742to determine which guest virtual machine (160,170or190) the local application722needs to run on. The pool manager246then sends a message to the host request handler448, which will in turn send a request743to the appropriate request handler (468,478or498) through a socket communications channel (751,752or753). In the case that the request743is requesting an application that is on the host white list442, the host request handler448will attempt to create the process749by forwarding the request743to the local operating system.

A similar process occurs when a request (763,773or793) is made on one of the virtual machines (160,170or190). The request (763,773or793) is intercepted by the local request handler (468,478or498) through an internal pipe (765,775or795). The local request handler (468,478or498) will inspect the local white list (462,472or492) to determine if the application specified by the request (763,773or793) is allowed to run locally or of it needs to run remotely. Applications that are on the white list (462,472or492) will be allowed to run locally while applications that not on the white list (462,472or492) will be required to run remotely.

In the case that the request (763,773or793) is requesting an application that is not on the host white list (462,472or492), the request handler (468,478or498) will attempt to communicate with the host request handler448through a socket communications channel (751,752or753). The host request handler448will communicate the request (763,773or793) to the pool manger246through an internal pipe742to determine which guest virtual machine (160,170or190) the application needs to run on. The pool manager246then sends a message to the host request handler448, which will in turn send a request743to the appropriate request handler (468,478or498) through a socket communications channel (751,752or753). In the case that the request (763,773or793) is requesting an application that is on the host white list (462,472or492), the local request handler (468,478or498) should attempt to create the process (769,779or799) by forwarding the request (763,773or793) to the local operating system.

The pool manager246should be configured to know which machines run which applications. So, if for example, a user makes a request763to run an email client from a virtual machine160dedicated to running web browsers, the email program will not be on the white list462of the web browser machine. So the guest request handler468will talk to the pool manager246through the host request handler448to determine which machine (170or190) should run the email program. In some embodiments the host request handler448can forward a request to start the email program directly to the guest request handler478on the appropriate guest virtual machine170. In another embodiment, the pool manager246can return to the guest request handler468through the host request handler448which machine (170or190) should run the email program and the guest virtual machine468will forward the request directly to the appropriate web browser dedicated machine478.

In the case that a request (743,763or773) is made on the host140or one of the application specific virtual machines (160and170) that is for an application that is not on one of their white lists (442,462or472), the pool manager246can direct the request using the mechanisms just described to a catch-all machine which could be190.

FIG. 8is a diagram showing how the request handler works. The request handler448on the host captures system calls that come from applications. The redirection module in the request handler determines if it's a file access call or a process creation call. If it's a process creation system call, then it consults a white list to determine if it's allowed to run locally. If it is allowed to run locally, then the system call is allowed to flow through and the process is created on the host. If it is not on the white list then the dispatcher will redirect the call to a remote machine determined by the pool manager246. In the case of a file access, if the file access is to a local drive on a local machine, then the file access is allowed to execute as is. If it is to a mount point on the secure virtual file system (SVFS), then the dispatcher will first seek approval from the user via keyboard input, then given approval to access the SVFS, the dispatcher will redirect the file access system call to the SVFS machine, which is determined by the pool manager246.

FIG. 9is a diagram showing an example file system for a host or guest machine. The machines can have a local drive910with a normal complement of directories912,914,916, and918that should exist only for the length of the virtual machine's life. The machine may also have a mount point for a persistent cache920containing data such as files922, cookies924, application data926and desktop data928. These files provide temporary and dynamic data for several applications such as web browsing to provide seamless experiences between different application sessions. However, since the data in this is not particularly valuable, no user authentication or approval is required in this embodiment for the guest virtual machines to access this persistent cache. In this embodiment, the persistent cache is mounted from a directory on a file server on the SVFS to all guest machines to provide seamless application usage across sessions. In other embodiments, the persistent cache can reside on another file server. In addition, user approval or authentication can be required in other embodiments for a guest VM to access this cache.

To save data past the refresh or destruction of a virtual machine, the virtual machine may desire to mount a secure virtual file server (SVFS)930. This device may be used to store document data932such as Excel data938, Power Point data936, and Word data934. However, to ensure that a legitimate user is only accessing this drive, it may be desirable to make this a limited access file server using standard user password authentication techniques available with most file servers.

In many cases, the limited access file server930can require a user to authenticate themselves at least during their first access, maybe more often. On a virtual machine, anytime the user attempts to read from or write to (access) the persistent file server930, that access itself is redirected. So, if a user is on a guest machine tries to access the persistent file server930, that access request can be redirected to the host machine. The host can take a look at the access and the access is interrupted. A pop up dialog box can ask the user for confirmation that they do indeed want to access the persistent file server930. One possible way to do this is with a mouse click acknowledgment. Another way to make this acknowledgement is by a keyboard stroke, requiring a password or PIN authentication, or through the use of a Turing test solvable only by a human. The acknowledgement verifies that the user does want to access data. This should prevent malicious code or users from writing files to persistent storage without the console user's permission. Likewise in order to retrieve files from the persistent storage device to the guest OS, it may also be advantageous to have the user authenticate the file transaction. In one embodiment, the approval once granted applies to all file accesses to that file directory from that application for that session. In another embodiment, each individual access to that file may require user approval.

FIG. 10is a diagram showing how the file access can work. When applications1030working on a virtual machine1020attempt to access a file system, the file system access system calls are intercepted by a request handler1048. If the file access is local or to the persistent cache920, the system call is allowed to execute as is and it stores or retrieves from local file storage1060through the local OS1044or to the persistent cache920. If the file access is to a the SVFS mount point, prior to letting that request go, the request handler1048calls an authentication module1050which may require a user to navigate a dialog box to approve the file system request in order to prove to the system that they are not actually malicious code. This navigation should allow a user to acknowledge and approve the remote file access at which point the request back on the virtual machine is allowed to create its client connection through a client access component1040to the persistent storage server1010. The persistent storage may be pointed to by the virtual machine pool manager246. Then the connection is made and the application1030is allowed to read from or write to the persistent storage1010. As an extra measure of safety, it may also be advantageous for the persistent file storage1010to utilize a firewall mechanism1012(or equivalent type mechanism) to filter out unwanted requests.

FIG. 11show the pool manager246. The virtual machine pool manager246runs on the host and is responsible for resource management of the guest virtual machines. It maintains a black list1120which lists which designated applications1122run on which designated machines1124. For example the list can have an entry that designates that web browsers run on a web browser specific virtual machine and another entry that designates that office spreadsheet programs run on an office spreadsheet specific virtual machine.

When an application is attempted to be run, the host request handler448sends a request1151to run that application to the virtual machine pool manager controller1110which will look at the request1151and determine if that machine is currently running. It can do that by grabbing the status1155of the virtual machine from the virtual machine monitor130. If it is not, then it will create that machine by sending VM commands1156to the virtual machine monitor module130. If it is running, then it provides authorization1152to the host request handler448to execute the process creation on the specified machine. A control panel1130may also enable manual control over the virtual machine resources. The control panel application should be able to provide system commands1153to the pool manager controller1110as well as receive system status1154from the pool manager controller1110.

The control panel1130gives the ability to create and destroy virtual machines and refresh virtual machines back to their original state. It can refresh virtual machines by reverting the virtual machine to a previously saved snapshot of the guest operating system in a pristine state. Refresh of the virtual machine is when a user for one reason or another decides he wants to reset the state of the virtual machine back to its initial pristine state. For example, good reasons to refresh a machine include: a virus having been detected on the virtual machine, or the virtual machine has just been open for too long (thus increasing the possibility of a contamination).

In some cases, if it is a web browser, you could save the address and return to the location. However, in many cases, the purpose of a refresh is to get the machine back to a safe condition. So for example, if a user were browsing at a celebrity site that might contain possibly damaging content, the user probably would not want to return to the site because of its possible negative effects on the system, but would rather start fresh with a new pristine machine.

Other functions of the pool manager controller1110include: add virtual machines of particular types such as a windows virtual machine, a Linux virtual machine or a variation of those. We could create a windows virtual machine with office running or create a windows virtual machine with an email application running. This can give a user control when they create a new virtual machine to designate what kind of a virtual machine to create including an isolated virtual machine that has no access to the internet or no access to persistent storage or some combination thereof.

When the machine starts up, it can consult a configuration file. The configuration file can instruct the pool manger controller how many virtual machines to create. How many are going to run live, how many are going to be put asleep in the virtual machine pool. And their configuration file can provide user interface locations to allow a user to designate some of these parameters to their liking or for the best performance of the machine.

The user can also through the control panel1130designate parameters for the black list1120. So they can say which machines1124they want to run which applications1122and that can be used to update the black list1120. A user might designate that they always want to have a Microsoft Office machine and further designate what applications they run on that machine that is created at startup.

The status1156of the virtual machine can also convey the security status of the virtual machines. For example, audit logs created by commercial security tools (like antivirus or root kit detectors) can be captured. When a violation of a virtual machine is detected, then that status can be used to update the control panel1130to inform the user that they have a machine where a compromise has been detected. The control panel1130can then be used to refresh or kill that virtual machine. Likewise, one could also keep track of the amount of time that a guest OS in a virtual machine has been open. If it has been open for too long, the status can be changed from green to yellow, or yellow to red. This can give a user an indication that it is time to refresh a virtual machine. Of course, one skilled in the art will recognize that these types of response actions could also be automatic.

FIG. 12is a flow chart shows actions that may be taken to create a new operating system reference image145. First, one should create a virtual machine (1250). Preferably, this virtual machine is not connected to a network or appliance that could corrupt the virtual machine or any software loaded on it. An operating system and any desired applications may be loaded and configured on the virtual machine (1250). A white list should be created that lists all of the loaded software and any other software that may be allowable to run on the currently set up arrangement (1260). A snapshot image145can be made of the configured system (1270). The snapshot may be classified at (1280). The classification should allow a user or system to identify the image145. This may be particularly useful when a series of images145are created for use on different virtual machines. The classification may be made part of the image145(such as in an identifying header), or kept separate from the image145. Finally, the snapshot image may be moved to persistent storage at1290for use by the virtual machine pool manager246when it creates new virtual machines.

In addition to creating a reference image145, it may be desirable to also be able to allow a user to update or patch the image.FIG. 13Ais a flow diagram showing how to safely download new software (or software patch) to embodiments of the virtual work system for further use. To start this process out, one should attempt to acquire a clean copy of the new software or patch. In the case that the software is distributed on a trusted media such as a CD, that media may be used directly. However, some software and patches need to be downloaded from a network. To do this, one may create a clean virtual machine that can connect to a network for the purpose of downloading software or patches at (1310). The software or patch may then be safely downloaded at1320. If desired, one could perform an integrity check on the software or patch by checking its MD5 hash or its digital signature released with the software ore patch by the software vendor. A user may copy the software or patch to persistent storage at1340for further use by a host or guest machine.

FIG. 13Bis a flow diagram showing how to create a new operating system reference image145using the downloaded software or software patch. A second virtual machine may be created at1350. The new software or patch may be loaded into that virtual machine at1350. Although it may be desirable to ensure that the loaded software is in pristine condition, the software or patch can be loaded from any source including the persistent storage or other computer readable storage medium (e.g. a CD, DVD, flash drive, etc.). The white list that is associated with the new image can be updated to reflect the new changes to the image at1360. A snapshot of the virtual machine may also be taken at1370of the system with the new configuration. Like before, it may also be desirable to reclassify this new image at1380. Finally, the snapshot may be copied to persistent storage at1390for further use by a host or guest machine.

Comparison to State of the Art

VMMs today are used to run multiple operating systems side by side on the same hardware to provide support for different operating systems (Windows and Linux) or to provide guarantees of separation between different classification levels in multi-level secure (MLS) military applications. In the multi-level secure system configuration, each operating system is configured to provide a separate computing platform with the net effect of combining multiple computers on a single hardware platform. It is functionally equivalent to having multiple computers on your desk—each operates independently, but all share the same hardware.

The approach described here uses virtual machine technology as a means for launching applications each in their own guest operating system to provide strong guarantees of isolation for that application. Rather than running different operating systems independently, the presently described approach is to run each application in its own virtual machine, thus providing strong guarantees of security while providing transparence to the user experience that a different machine is running. Another key difference is that under the MLS scheme, the machines are persistent. Once compromised by malicious code or attack, the MLS machine can potentially remain compromised. The window of exposure to attack is also equivalent to current desktop systems. That is as long as the machine remains connected to the network, it remains exposed to attack. In the embodiments described here, the machines are transient. The machines can last only for the duration of the application session. After the application session is complete, the machine may be killed and the window of exposure terminated. Furthermore, a “clean” machine may be started on each new application session, which means any changes made to the machine during a prior session, e.g., by malicious code or attack, are no longer present in the current instantiation.

Another relevant point of comparison is to software “wrapper” or mediation technology. Software wrappers are used today to “wrap” or encapsulate an application with a prophylactic layer of software redirection calls that mediate access to system resources. The wrappers can enforce a policy that is written for each application. The idea behind software wrappers is that you can constrain an application's behavior from malicious use of the system by mediating its access to the system. It requires a software mediation infrastructure that runs on top of the host OS.

The approach of the embodiments described here is fundamentally different in how it approaches this problem. Rather than “wrapping” an application, the embodiments create a whole new machine in which it runs the protected application. Failures in the policy definition and implementation in the wrapping layer of the wrapper technology can lead to a compromised system. The IC system involves no wrapping and is in fact root secure. Meaning that failures in the application's security that result in the complete compromise of the system running the application will not compromise the host system. Also, one of the most vexing problems in wrapper/mediation approaches is the requirement to define a policy for each application and the fact that many multi-functional applications such as Web browsers cannot be effectively constrained because of the wide range of functionality they must possess to be effective. In the currently described approaches, no policy definition or constraints are necessary. The application has full access to the machine it runs on with no residual consequences.

While various embodiments have been described above, it should be understood that they have been presented by way of example, and not limitation. It will be apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein without departing from the spirit and scope. In fact, after reading the above description, it will be apparent to one skilled in the relevant art(s) how to implement alternative embodiments. Thus, the present embodiments should not be limited by any of the above described exemplary embodiments. In particular, it should be noted that, for example purposes, the above explanation has focused on the example(s) of personal data. However, one skilled in the art will recognize that embodiments of the invention could be used where more than one application is run within a Virtual machine running a guest OS.