WO2007127349A2

WO2007127349A2 - Secure user environment software

Info

Publication number: WO2007127349A2
Application number: PCT/US2007/010199
Authority: WO
Inventors: Marcos B. Pernia; Scott R. Copeland; Tony Mason
Original assignee: Exobox Technologies Corp.
Priority date: 2006-04-26
Filing date: 2007-04-26
Publication date: 2007-11-08
Also published as: AU2007243254A1; WO2007127349A3; CA2650374A1

Abstract

In general, the invention relates to a system that includes a native environment executing on the system. The system further includes a user environment executing on the system, wherein the user environment is isolated from the native environment.

Description

SECURE USER ENVIRONMENT SOFTWARE

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application Serial

No. 60/795,41 1 filed on April 26, 2006, entitled "Secure User Environment Software," in the names of Marcos B. Pernia, Scott R. Copeland, and Tony Mason. The aforementioned provisional application is hereby incorporated by reference.

BACKGROUND

[0002J As the online community grows with the development of high bandwidth, high speed, and high availability connectivity to the public internet, we are seeing an ever increasing proliferation of malicious content and identity/data theft and destruction, perpetrated right in our own home and office computers. Malignant and poisonous web content administered through data mining tools, Add-Ware content, activeX, Java script, misleading download queries, Trojan content, and virus infected data is responsible for extraordinary, quantifiable, monetary losses to the enterprise every year. There is no measure, however, for the loss of privacy, intimate data, and criminal violations these intrusions prey upon our families. Passive, after "the fact\ behindhand screening for Trojan and virus content, such as that provided by modern virus scanning software, has proven itself an inadequate bastion of defense to the cyber theft and data corruption mechanisms rampant in the global cyberspace.

100031 The computer security industry has made attempts to address these failings by implementing solutions such as execution protection products that only allow the execution of White-listed applications on any given computer; but such products require constant centralized administration and customization to fit within a diverse enterprise community, and are unreasonable solutions for home users due to their management needs and lack of transparency. Though restricting execution can greatly improve the protection of local computer data, a more flexible solution is to virtualize execution in an isolated environment. This methodology has been proven by software implemented virtual machines such as those presented by VMWare. However, such solutions are not practical, nor were they designed for, implementation as computer security software. Such solutions require the full installation of a secondary operating system within each virtual environment. Implementing such environments requires a higher level of computer understanding than the average user and presents management/administration and storage complications to implementations across an enterprise environment. Even solutions as common to modern computer environments as advanced statefull firewall protection, host security, and access control management is beyond the average computer owner, let alone the peers and loved ones sharing their computer space. Microsoft's Windows^® architecture does not provide inherent user or group isolation robust enough to protect low privileged users from the actions of malicious code should it find its way onto their computer, nor the proliferation of damage or theft throughout all the computer's user and administrator space. Current third party solutions have proven themselves inadequate to protect a computer from the transgressions of its operators or malicious attack. This begs the question, is it possible to split a Windows computer into secure virtual environments with as much isolation as possible between each one, looking like individual computers without the cumbersome implementation of classic virtual machine environments? To isolate disk space, virtualize execution, make user data inaccessible and unreadable to other users; yet share some/most/all common tasks (monitoring, backup, ups, hardware configuration, libraries, etc.) and still allow the individual evolution of each virtual environment? Can this be done transparently and unobtrusively? SUMMARY

[0005| In general, in one aspect, the invention relates to a system that includes a native environment executing on the system and a user environment executing on the system, wherein the user environment is isolated from the native environment.

[0006] In general, in one aspect, the invention relates to a method for executing an application in a user environment. The method includes issuing a call by an application in the user environment, intercepting the call, determining an action to perform in response to intercepting the call, performing the action, and providing the application with a response to the call, wherein the call is intercepted by a component in a native environment, wherein the user environment and the native environment are executing on a single system, and wherein the user environment is isolated from the native environment.

[0007J Other aspects of the invention will be apparent from the following description and the appended claims.

BRIEF DESCRIPTION OF DRAWINGS

IOOO8| Figure 1 shows a system in accordance with one embodiment of the invention.

[0009| Figure 2 shows a data management module in accordance with one embodiment of the invention.

(0010] Figures 3-7 show flowcharts in accordance with one or more embodiments of the invention.

[00111 Figure 8 shows a computer system in accordance with one embodiment of the invention. DETAILED DESCRIPTION

[0012] Specific embodiments of the invention will now be described in detail with reference to the accompanying figures. Like elements in the various figures are denoted by like reference numerals for consistency.

|0013J In the following detailed description of embodiments of the invention, numerous specific details are set forth in order to provide a more thorough understanding of the invention. However, it will be apparent to one of ordinary skill in the art that the invention may be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description.

[0014] In general, embodiments of the invention relate to a method and system for protecting a system's hardware, software, and data from unauthorized access, modification, and/or malicious use including, but not limited to, destruction.

[0015] Figure 1 shows a system in accordance with one embodiment of the invention. In one embodiment of the invention, the system is a Windows based system. In one embodiment of the invention, Windows based refers to an operating system developed by the Microsoft Corporation. In addition, the term "windows based" may also be understood to encompass other operating systems currently available and that will become available, which include any components similar to the Microsoft Windows^® operating systems that are currently supported by the Microsoft Corporation. This would include Windows XP and Windows Server 2003 as well as future versions of Microsoft Windows^® such as, but not limited to, Microsoft Windows Vista . All of the aforementioned trademarks are trademarks of the Microsoft Coiporation.

[0016| Continuing with the discussion of Figure 1 , the system includes at least the following components: a user mode authorization module (100), one or more applications (102 A, 102N), a control layer ( 104), an administration application ( 106), an operating system (OS) (e.g., a Windows based operating system) interface (J 08), a device management module (110), device(s) (1 12), data management module (1 14), file systems ( 1 16), a configuration management module (1 18), a registry ( 120), a policy management module (122), an auditing module (124), a validation module (126), a protocol management module ( 130), a network management module (128), a transport device interface (TDI) (132), a network driver interface specification module ( 134), and one or more network interface cards (NICs) (136). Each of the aforementioned components is discussed below.

[0017] In one embodiment of the invention, the user mode authorization module (100) is configured to authenticate a user to the system. In one embodiment of the invention, the user mode authorization module (100) may use the Graphical Identification and Authentication (GINA) library to perform authentication of the user. In another embodiment of the invention, the user mode authorization module (100) may use a Credential Provider architecture to authenticate the user. Those skilled in the art will appreciate that other libraries and/or architectures may be implemented by the user mode authorization module (100) to authenticate the user.

|0018| Though not shown in Figure 1, the system may include a kernel resident application, which includes the same (or similar) functionality as the user mode authorization module (100). The aforementioned kernel resident service is typically used when user mode services are not available, for example, during system initialization and shutdown.

[0019J In one embodiment of the invention, the user mode authorization module ( 100) is configured to authenticate a user using any authentication mechanism. For example, the user mode authorization module ( 100) may be configured to authenticate a user using an external security device validation (e.g., a smart card (or other security token), a checksum based authentication, and/or a Public Key Infrastructure (PKI) based authentication mechanism). [0020| Continuing with the discussion of Figure 1 , the system may include one or more applications (102A, 102N) executing in the user level. Examples of applications include, but are not limited to, an internet browser and a document creation program. In one embodiment of the invention, the system includes a control layer (104) configured to intercept calls (e.g., request for data, write request, etc.) issued by and targeted to the applications ( 102 A, 102N). In one embodiment of the invention, the control layer (104), upon interception of the above calls, determines the user session in which the application is executing and, based on this determination, obtains and applies the appropriate policy. In one embodiment of the invention, policy includes one or more rules, where the rules establish the correct behavior of the system in a specific situation.

[0021] For example, the control layer (104) may only permit an application to perform a specific function (e.g., the authorized corporate e-mail program is the only one allowed to send Simple Mail Transfer Protocol (SMTP) e-mail because it includes an add-in encryption module to ensure the data sent via e-mail is encrypted using the PKI infrastructure).

[0022] In one embodiment of the invention, the administration application

(106) provides a single point of management for the creation and management of policies enforced by the system. In one embodiment of the invention, the system may include a variety of default "policy templates." In such cases, the administration application (106) may provide administrators an interface to select a default policy template and modified the selected default template to create a customized policy. Alternatively, administrators may create a policy from scratch.

|0023| In one embodiment of the invention, the administration application

(106) includes functionality to enable an administrator to sign the policies and send the signed policies to specific computer systems (i.e., computers other than the one on which the administration application (106) is executing). [0024| In one embodiment if a system requires signed policies, then the system will only allow loading of a new policy if the new policy can be validated. In this fashion, it is possible to work in higher security environments where it is imperative that users not be able to modify_. the policy, absent agreement and/or authorization from the administrator. In one embodiment of the invention, signing a policy corresponds to encrypting the policy (e.g., applying an encryption algorithm such as Triple Data Encryption Standard (3DES), applying a hash function such as Message Digest (MD) 5, etc.) in such a way that the signed policy (or more specifically the digital signature associated with the policy) may be validated using standard mechanisms, such as Public-Key Infrastructure (PKI) or other secure public key storage mechanisms (such as a hardware key storage device).

[0025] In one embodiment of the invention, the administration application

(106) may include functionality to allow an administrator to analyze events logged by the system. In addition, the administration application (106) may be configured to provide alerts when certain events occur and/or when a certain threshold for the occurrence of a specified event is met or exceeded.

[0026J In one embodiment of the invention, the system includes an OS interface ( 108). The OS interface ( 108) provides an interface between the user level processes (e.g., applications (102A₃ 102N), administration application (106), user mode authentication module (100), control layer (104)) and the processes executing in the kernel level (e.g., a device management module ( 1 10), data management module (1 14), file system(s) (1 16), a configuration management module (1 18), a registry (120), a policy management module ( 122), an auditing module ( 124), a validation module (126), a protocol management module ( 128), a network management module (130), a transport device interface (TDI) (132), and a network driver interface specification module (134)). |0027] Continuing with the discussion of Figure 1 , the device management module (1 10) is configured to provide an interface between the devices ( 1 12) operatively connected to system and other hardware and software in the system. More specifically, the device management module (1 10) includes functionality to implement and enforce access and use policies associated with the devices (1 12).

[0028| In one embodiment of the invention, devices (1 12) correspond to any storage medium including, but not limited to, Universal Serial Bus (USB) flash drive, USB external hard drives, internal hard drives, compact disk (CD) (read only and read/write), Digital Versatile Disk (DVD) (read only, read/write), magnetic tape (and the associated magnetic tape reader), optical medium (and the associated optical reader) or another other storage medium and associated device for accessing and using said storage medium.

|0029| In one embodiment of the invention, the data management module

( 1 14) is configured to provide an interface between the file system(s) (1 16) in the system and the OS interface (108). More specifically, the data management module (114) is configured to control the interaction between other components in the system and the file system(s) (1 16). The data management module ( 1 14) is discussed below in Figures 2 and 5.

|0030j In one embodiment of the invention, examples of files systems (1 16) include, but are not limited to, CDFS, NTFS and ZFS. CDFS is a virtual Linux file system that provides access to individual data and audio tracks on compact discs. NTFS (New Technology File System) is the standard file system of Windows based systems. ZFS is a file system originally developed for Solaris^® and currently available on other operating system platforms.

[0031] In one embodiment of the invention, the configuration management module ( 1 18) is configured to provide an interface between the OS Interface ( 108) and the registry (120). In one embodiment of the invention, the registry ( 120) corresponds to a central hierarchical database used in Windows based systems configured to store information necessary to configure the system for one or more users, applications and hardware devices. Further, the registry (120) may include information that the Windows based system continually references during operation, such as profiles for each user, the applications installed on the system and the types of documents that each user can create, property sheet settings for folders and application icons, what hardware exists on the system, and the ports that are being used.

|0032] In one embodiment of the invention, the configuration management module (118) includes functionality to manage individual user access to the registry (120). Further, the configuration management module ( 1 18) includes functionality to determine, using the appropriate policy: (i) how the user can interact with the registry (120); (ii) which of the user changes (assuming the user is allowed to modify the registry (120)) are persisted to the native system registry; (iii) how to maintain the user's isolated registry (not shown); (iv) what portions of the native system registry (i.e., registry (120)) and what portions of the user's specific changes to the registry should be displayed to the user.

|00331 'ⁿ one embodiment of the invention, the configuration management module ( 1 18) is configured to manage the above functionality and one or more components in the data management module ( 1 14) is used to perform the above functionality.

|0034| In one embodiment of the invention a policy management module

( 122) is configured to manage the policies used in the system. More specifically, policy management module (122) is configured to maintain an association between the policies and the users of the system, such that the appropriate policy is applied for a given user. In one embodiment of the invention, a given policy may be associated with a single user, a group of users, all users within a geographical location, all users within a specified proximity to a network, all users using a device associated with a specific digital signature, etc.

|00351 In one embodiment of the invention, the policy management module

(122) manages at least the following levels of policies: (i) domain level policies and (ii) stand-alone system policies.

[0036] In one embodiment of the invention, domain level policies are uniformly applied at a domain level (e.g., a network domain level). In essence, such policies become the "least common denominator" for all systems in the domain and may be validated over the network. In one embodiment of the invention, stand-alone system policies are unique polices to a specific system or set of systems. Such policies are typically manually loaded onto a system and are locally validated.

|0037| In one embodiment of the invention, the aforementioned policies may be communicated from the administration application to one or more remote systems using either a push architecture or a pull architecture.

[0038| In one embodiment of the invention an auditing module (124) includes functionality to track behavior within the system. In one embodiment of the invention, tracking behavior within the system may include one or more of the following types of logging: (i) a local log - maintained on the system on which the event occurred, (ii) a remote log- maintained on system remote to the system on which the event occurred, and (iii) a persistent, write-once stored log of events- storing log events on write-once media using, for example, a hardware device that provides a sequence of record numbers that can be used to detect when there are missing records.

[0039| The aforementioned information stored in the log(s) may be used to: (i) perform forensic analysis in cases of system or information compromise to determine how it happened, the responsible parties, and identify potential ways of mitigating this issue in the future; (ii) monitor for unusual behavior or activity (e.g., someone exploring ways to compromise the system); and (iii) monitor for rules that are unduly burdensome (e.g., they generate excessive "unusual behavior" reports that suggest users must try to circumvent the policy).

[00401 I" one embodiment of the invention, the validation module (126) is configured to validate a policy prior to loading the policy into the system. Further, the validation module (126) may also be configured to validate a policy prior to every application of the policy. For example, when a user logs onto the system, validation module ( 126) may validate the policy prior to applying the policy to the user. Further, the same process is applied the next time the user logs on. In one embodiment of the invention, validation of the policy may include, but is not limited to, determining whether the policy includes the appropriate digital signature and determining whether the policy has expired.

(0041 1 In one embodiment of the invention, network interface cards (NICs)

(136) are hardware components operatively connected to the system, which provide an interface between a network {e.g., a local area network, a wide area network, a wireless network, a peer-to-peer network, etc.) and the system. Data received by the NICs (136) (either from the system or from the network (not shown)) is subsequently processed using the following components. Note that data transmitted by the system is processed by the following components prior to being sent to the NICs ( 136).

100421 In one embodiment of the invention, a transport device interface (TDI)

(132) is a common interface for drivers (such as the Windows 2000 redirector and server) used to communicate with the various network transport protocols. This allows services to remain independent of transport protocols.

|00431 In one embodiment of the invention, the network driver interface specification (NDIS) module (134) includes one or more application programming interfaces (APIs) to enable the system to interface with the NlCs ( 136). [0044] In one embodiment of the invention a network management module

(128) is configured to interface with (or be incorporated within) the NDIS module (134). More specifically, the network management module (128) exports a virtual interface to provide multiple virtual NICs connected to the same physical NIC(s) (136). The virtual NICs each include a hardware address (and other parameters required by layers in the network stack (not shown). The virtual NlCs allow data associated with each user environment to be isolated from the data associated with the native environment. In one embodiment of the invention, the separation of data associated with user environments and/or the native environments is performed using a protocol filter/firewall.

[0045J In one embodiment of the invention, a protocol management module

(130), is configured to interface with (or be incorporated within) the TDI (132). More specifically, the protocol management module (130) is configured to enforce the data separation (i.e., separation of data associated with user environments and/or the native environment) at the layer in the network stack that implement Internet Protocol (IP) and Transmission Control Protocol (TCP).

[0046| Figure 2 shows a data management module in accordance with one embodiment of the invention. In one embodiment of the invention, the data management module (1 14) includes a file system filter driver (FSFD) (200) and a logical storage driver (202). Each of the aforementioned components is discussed below.

|00471 In one embodiment of the invention, the FSFD (200) is configured to intercept file system level access events (e.g., execution, data access, write operation, etc.) and modify the default behavior of the system. Examples of modifying the default behavior may include, but are not limited to, redirection to an alternative storage location (e.g., to convert a logical storage location into a different physical location) and redirection to an alternative driver (e.g., to allow specialized functions such as extraction of authorization information, or encryption of critical information), and/or monitoring operations for auditing purposes (e.g., with comparisons against an auditing policy that identifies operations that should be considered highly suspect).

|0048] In one embodiment of the invention, the logical storage driver (202) is configured to implement a logical storage unit, which may be managed as a single container (e.g., a "flat file") or presented to the user as a mountable storage device (e.g., a volume). In one embodiment of the invention, by encapsulating the user's environment (including user specific registry information) into a single logical container, the user is able to carry their environment on a portable storage device (e.g., a USB pen drive, etc.).

[0049] In one embodiment of the invention, if a user's environment is compromised (e.g., by the execution of malicious code) when the user exits the compromised environment, some or all of the user's changes are discarded, based on the appropriate policy, and the native system is not compromised.

10050} Figures 3-7 show flowcharts in accordance with one or more embodiments of the invention. In one or more embodiments, one or more of the steps shown in Figures 3-7 may be omitted, repeated, and/or performed in a different order than that shown in Figures 3-7. Accordingly, the specific arrangement of steps shown in Figures 3-7 should not be construed as limiting the scope of the invention.

|0051] Figure 3 shows a flowchart in accordance with one embodiment of the invention. More specifically, Figure 3 shows a method for authenticating a user in accordance with one embodiment of the invention. Optionally, a secure attention sequence is received (ST300). In one embodiment of the invention, the secure attention sequence is CTRL-ALT-DEL. Alternatively, the flowchart may start at ST302.

|0052| At ST302, authentication information is received. In one embodiment of the invention, the authentication information may correspond to a username/password, a key on a smart card, biometric data associated with the user, etc.

[0053] At ST304, the authentication information is authenticated using the appropriate mechanism. Those skilled in the art will appreciate that the mechanism used to authenticate the authentication information is based on the type of authentication information. At ST306, a determination is made about whether the authentication is successful. If the authentication is not successful the method ends. Alternatively, if the authentication is not successful, the system may allow a user to access to a limited portion of the system to, for example, obtain new authentication information in the event the user forgot her password.

[0054J If the authentication was successful, at ST308, the policy associated with the user is obtained. In one embodiment of the invention, the policy management module is used to perform ST308. At ST310, the policy obtained in ST308 is optionally validated using, for example, the validation module. At optional ST312, a determination is made about whether the validation was successful.

[0055J If the validation was not successful, then the method ends.

Alternatively, if the validation is not successful, at ST316, the system may create a session in accordance with a restricted policy. If the validation is successful or if no validation is required, at ST314, a user session is created in accordance with the policy obtained in ST308.

|0056| Figure 4 shows a flowchart in accordance with one embodiment of the invention. More specifically, Figure 4 shows a method for processing a file system level access event. At ST400, a file system level access event is issued to the file system (or one of the file systems, if multiple file systems are implemented on the system). At ST402, the file system level access event is intercepted by the file system filter driver (FSFD).

10057 J At ST404, the policy associated with the user who issued the file system level access event is obtained. At ST406, a determination is made, using the policy obtained in ST404, about whether redirection of the file system level access event is required.

[0058] If redirection is required, at ST408, a determination is made, using the policy obtained in ST404, about whether redirection to an alternate storage location is required. If redirection to an alternate storage location is required, then at ST412 the file system level access event is sent to the logical storage driver. At ST414, the logical storage driver determines the logical storage unit (e.g., a flat file stored on a removable medium) associated with the user. At ST416, a determination is made about whether an alternate driver (e.g., a driver configured to perform a specialized function such as extraction of authorization information and/or or encryption of critical information) should be applied to the file system level access event.

[0059] If redirection to an alternate driver is required, at ST418, the alternative driver performs appropriate actions on the data associated with the file system level access event. Once ST418 is completed or, alternatively, once ST416 is completed (assuming no redirection), at ST420 the file system level access event (potentially modified by ST418) is sent to the logical storage unit. At ST422, the logical storage unit performs the appropriate action based on the received file system level access event.

[0060] If redirection to an alternate location is not required, then at ST410 a determination is made about whether redirection to an alternate driver is required. If redirection to an alternate driver is required, at ST424, the alternative driver performs appropriate actions on the data associated with the file system level access event. Once ST424 is completed or, alternatively, once ST410 is completed (assuming no redirection), at ST426 the file system level access event (potentially modified by ST424) is sent to the file system. At ST428, the file system performs the appropriate action(s) based on the received file system level access event.

|0061] If no redirection is required based on the determination performed in

ST406, at ST426 the file system level access event is sent to the file system. At ST428, the file system performs the appropriate action based on the received file system level access event.

[0062] Figure 5 shows a shows a flowchart in accordance with one embodiment of the invention. More specifically, Figure 5 shows a method for processing a request to change a registry entry. At ST500, a request to change a registry entry is received by the configuration management module. At ST502, the policy associated with the user who sent the request received in ST500 is obtained.

[0063] At ST504, the location within the registry in which the change is requested is determined. In one embodiment of the invention, the location may correspond to one the following locations: (i) system registry (i.e., the native registry), (ii) user registry; and (iii) in-memory only registry.

|0064] At ST506, a determination is made about which portion of the policy obtained in ST502 to apply to the request based on the location obtained in ST504. At ST508, the appropriate portion of the policy (as determined in ST506) is used to dictate how to service the request. For example, the request may be denied, allowed, or partially denied/partially allowed.

[0065] Figure 6 shows a shows a flowchart in accordance with one embodiment of the invention. More specifically, Figure 6 shows a method for displaying a registry to a user in accordance with one embodiment of the invention

[0066] At ST600, a request to view the registry is received at the configuration management module. At ST602, the policy associated with the user who sent the request received in ST600 is obtained. AT ST604, the user-specific registry data is obtained. In one embodiment of the invention, the user- specific registry data may be obtained from the logical storage unit associated with the user.

|0067] At ST606, using the policy obtained in ST604, a determination is made about which portions of the global registry data (i.e., the native registry data) and which portions of the user-specific registry data should be displayed to the user. At ST608, the appropriate portions of the global registry data and the user-specific registry data are displayed to the user. In one embodiment of the invention, only the user-specific registry data is displayed to the user. In one embodiment of the invention, only the global registry data is displayed to the user. In one embodiment of the invention, a combination, dictated by the policy associated with the user, of global registry data and user-specific registry data is displayed to the user.

[0068J Figure 7 shows a shows a flowchart in accordance with one embodiment of the invention. More specifically, Figure 7 shows a method for receiving data in a system implementing one or more embodiments of the invention. At ST700, data is received from a network by a NIC.

[0069J At ST702, the target of the data is determined. In one embodiment of the invention, the target of the data is determined using information in, for example, the header of the packet. In one embodiment of the invention, the target of the data corresponds to either a user environment or the native system environment.

[0070| At ST704, the data is processed in the network stack using the appropriate policy, where the appropriate policy is determined based on the target of the data. Further, in ST704, the data is processed such that it is isolated for data not associated with the target (i.e., the target of the data as determined in ST702).

[0071J In one embodiment of the invention, the policy to apply in ST704 may be determined as follows: (i) determine target of data; (ii) determine environment in which target is located; (iii) determine user associated with the target; and (iv) determine policy associated with the user. Those skilled in the art will appreciate that if the target is in the native environment, then the "user" in this context corresponds to the "native" user.

[00721 Embodiments of the invention may be implemented on virtually any type of computer regardless of the platform being used. For example, as shown in Figure 8, a computer system (800) includes a processor (802), associated memory (804), a storage device (806), and numerous other elements and functionalities typical of today's computers (not shown). The computer (800) may also include input means, such as a keyboard (808) and a mouse (810), and output means, such as a monitor (812). The computer system (800) may be connected to a network (814) {e.g., a local area network (LAN), a wide area network (WAN) such as the Internet, or any other similar type of network) via a network interface connection (not shown). Those skilled in the art will appreciate that these input and output means may take other forms.

|0073] Further, those skilled in the art will appreciate that one or more elements of the aforementioned computer system (800) may be located at a remote location and connected to the other elements over a network. Further, embodiments of the invention may be implemented on a distributed system having a plurality of nodes, where each portion of the invention may be located on a different node within the distributed system. In one embodiment of the invention, the node corresponds to a computer system. Alternatively, the node may correspond to a processor with associated physical memory. The node may alternatively correspond to a processor with shared memory and/or resources. Further, software instructions to perform embodiments of the invention may be stored on a computer readable medium such as a compact disc (CD), a diskette, a tape, a file, or any other computer readable storage device.

|0074J While the invention has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of this disclosure, will appreciate that other embodiments can be devised which do not depart from the scope of the invention as disclosed herein. Accordingly, the scope of the invention should be limited only by the attached claims.

Claims

CLAIMSWhat is claimed is:

1. A system comprising: a native environment executing on the system; and a user environment executing on the system, wherein the user environment is isolated from the native environment.

2. The system of claim 1, wherein the user environment is isolated from the native environment such that changes made in the user environment are not persistent in the native environment.

3. The system of claim 1 , wherein the native environment comprises an original installed image of an operating system.

4. The system of claim 1 , wherein the user environment is associated with a first virtual interface and the native environment is associated with a second virtual interface, where each of the first virtual interface and the second virtual interface are associated with unique hardware address and wherein the first and second virtual interfaces are bound to a network adapter.

5. The system of claim 4, wherein the first virtual interface isolates data for the user environment from data for the native environment.

6. The system of claim 1 , wherein functionality of the user environment is governed by a policy.

7. The system of claim 6, wherein the policy is obtained from a central system operatively connected to the system using at least one selected from group consisting of a pull architecture and a push architecture.

8. The system of claim 7, wherein the policy is associated with a user.

. The system of claim 8, wherein the policy is obtained when the user logs on to the system.

10. The system of claim 6, wherein the policy comprises an access policy for a removable storage device operatively connected to the system.

1 1. The system of claim 10, wherein the access policy is used when a process originating from the user environment attempts to access the removable storage device.

12. The system of claim 1 , wherein the user environment comprises a user registry and the native environment comprises a native registry, wherein changes made to the user registry are not persistent in the native registry.

13. The system of claim 12, wherein the native registry comprises a persistent registry and an in-memory registry.

14. The system of claim 13, wherein the user registry is associated with a first policy, the persistent registry is associated with a second policy, and the in-memory registry is associated with a third policy.

15. The system of claim 1, wherein a call to a file system originating from the user environment are intercepted by a file system filter driver.

16. The system of claim 15, wherein a policy associated with the user environment defines an action the file system filter driver performs when the call is intercepted.

17. The system of claim 16, wherein the action comprises redirection of the call.

18. The system of claim 1, wherein the system is Windows-based.

19. A method for executing an application in a user environment comprising: issuing a call by an application in the user environment; intercepting the call; determining an action to perform in response to intercepting the call; performing the action; and providing the application with a response to the call, wherein the call is intercepted by a component in a native environment, wherein the user environment and the native environment are executing on a single system, wherein the user environment is isolated from the native environment.

20. The method of claim 19, further comprising: logging in to the user environment, wherein logging in to the user environment comprises obtaining a policy associated with a user logging in to the user environment.

21. The method of claim 20, wherein the policy comprises an access policy for a removable storage device operatively connected to the system.

22. The method of claim 21 , wherein the call corresponds to an Input/Output (I/O) call to a removable storage device and is intercepted by a logical device manager.

23. The method of claim 22, wherein the access policy defines the action the logical device driver performs when the I/O call is intercepted.

24. The method of claim 20, further comprising: validating the policy prior to using the policy in the user environment.

25. The method of claim 24, wherein the validating the policy comprises validating a digital signature associated with the policy.

26. The method of claim 19, wherein the system is Windows-based.

27. The method of claim 19, wherein the call corresponds to a file system call originating from the user environment and is intercepted by a file system filter driver.

28. The method of claim 27, wherein a policy associated with the user environment defines the action the file system filter driver performs when the call is intercepted.

29. The method of claim 28, wherein the action comprises redirection of the call.

30. The method of claim 19, wherein the user environment comprises a user registry and the native environment comprises a native registry, wherein changes made to the user registry are not persistent in the native registry.

31. The method of claim 19, wherein the call corresponds to a network call originating from the user environment and wherein the network call is intercepted and routed to a first virtual interface associated with the user environment.

32. The method of claim 31, wherein the user environment is associated with the first virtual interface and the native environment is associated with a second virtual interface, where each of the first virtual interface and the second virtual interface are associated with unique hardware address and wherein the first and second virtual interfaces are bound to a network adapter.