Patent Publication Number: US-2022224726-A1

Title: Distribution and Management of Services in Virtual Environments

Description:
RELATED APPLICATIONS 
     This application is a continuation of, and claims priority to, U.S. patent application Ser. No. 16/277,575, issued as U.S. Pat. No. 11,290,488, entitled “Distribution and Management of Services in Virtual Environments”, filed Feb. 15, 2019, which, in turn, claims priority to U.S. patent application Ser. No. 15/460,599, issued as U.S. Pat. No. 10,333,985, entitled “Distribution and Management of Services in Virtual Environments”, filed Mar. 16, 2017, which, in turn, claims priority to U.S. Provisional Patent Application No. 62/444,209, filed Jan. 9, 2017, and also entitled “Distribution and Management of Services in Virtual Environments”. The aforementioned applications are all incorporated herein in their originally filed form. 
    
    
     BACKGROUND 
     Virtual machine-based virtualization provides the same isolation as physical machines, while offering flexibility and density. Today, many server scenarios are adopting containers both in the enterprise and in the cloud. While enterprise and cloud computing reap the benefits, containers also hold promise for client devices. 
     SUMMARY 
     Distribution and management of services in virtual environments is described herein. In one or more implementations, a service distribution and management model is implemented in which system services and applications are seamlessly distributed across multiple containers which each implement a different runtime environment. 
     In one or more implementations, a system for distributing access to services in a host operating system of a computing device includes a host operating system configured to implement a host runtime environment, and one or more services implemented by the host operating system. The system further includes a service control manager configured to enable communication between a client stub of a service implemented in a client runtime environment and a service provider of the service that is implemented in a service runtime environment that is separate from the first client runtime environment. 
     In one or more implementations, a service control manager configured to distribute and manage services across containers is provided in a host runtime environment. A request to access a service is received at the service control manager from a client stub of a client implemented in a client runtime environment of a first container. The request is validated against a set of security rules and policies, and the client is granted access to the service if the client is permitted to access the service based on the set of security rules and policies. Next, if a service provider of the service is available, connection information is returned to the client. The service provider may be implemented in a service runtime environment of a second container that is separate from the first container. Alternately, if the service provider of the service is not available, a new instance of the service provider is started in a new service runtime environment and connection information is returned to the client. 
     This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different instances in the description and the figures may indicate similar or identical items. Entities represented in the figures may be indicative of one or more entities and thus reference may be made interchangeably to single or plural forms of the entities in the discussion. 
         FIG. 1  illustrates an example system implementing distribution and management of services in virtual environments in accordance with one or more embodiments. 
         FIG. 2  illustrates an example system architecture for distribution and management of services in virtual environments in accordance with one or more embodiments. 
         FIG. 3  illustrates a host runtime environment, implemented by a host operating system, in which a service is separated into a service provider and a client stub. 
         FIG. 4  illustrates a host runtime environment, implemented by a host operating system, in which a centralized service distribution and management model is implemented. 
         FIG. 5  illustrates a host runtime environment, implemented by a host operating system, in which the host service control manager and service providers are offered to the client stub as a highly available service endpoint. 
         FIG. 6  illustrates an example in which a service distribution and management model is applied to a Component Object Model (COM) service. 
         FIG. 7  illustrates an example in which a security model is applied to a Domain Name System (DNS) service. 
         FIG. 8  illustrates an example of a host runtime environment in which a service control manager and service provider are decoupled from the host runtime environment. 
         FIG. 9  is a flowchart illustrating an example process for implementing distribution and management of services in virtual environments in accordance with one or more embodiments. 
         FIG. 10  illustrates an example system that includes an example computing device that is representative of one or more systems and/or devices that may implement the various techniques described herein. 
     
    
    
     DETAILED DESCRIPTION 
     Virtual machine-based virtualization provides the same isolation as physical machines, while offering flexibility and density. Container-based virtualization provides a lighter weight virtualization environment, improved compatibility and lower operational costs. Today, many server scenarios are adopting containers both in the enterprise and in the cloud. While enterprise and cloud computing reap the benefits, containers also hold promise in client. Beyond providing a great software development environment, containers will provide the next generation of features around security and isolation. Containers achieve their lightweight attributes through sharing aspects of the operating system. This may include sharing of files and folders, sharing configurations, sharing devices, and sharing operating system services. In some environments, such as friendly multi-tenant hosting, overlapping processes can be “de-duplicated” thereby enabling even more efficient resource utilization. 
     Distribution and management of services in virtual environments is described herein. In one or more implementations, a service distribution and management model is implemented in which system services and applications are seamlessly distributed across multiple containers which each implement a different runtime environment. Compared to existing container models, this service distribution and management model provides a similar level of service to applications but significantly reduces the overhead of each runtime environment such that guest operating systems of the containers use fewer hardware resources. 
     In order to achieve a lightweight runtime environment and to reduce complexity, the service distribution and management model separates each service into two components: a service provider and a client stub. Both the service provider and the client stub can be implemented in separate containers or they can be implemented in the host runtime environment. Thus, if a particular container needs to access a service, the container hosts a client stub of the service which is configured to communicate with a service provider which may be running in a different container or in the host runtime environment. Notably, by separating services into a client stub and service provider, the service distribution and management model enables a particular service to be shared across different containers and runtime environments. For example, a single service provider can be implemented in a first container and shared by multiple different client stubs that are each implemented in separate containers. 
       FIG. 1  illustrates an example system  100  implementing distribution and management of services in virtual environments in accordance with one or more embodiments. System  100  is implemented at least in part by a host device. Any of a variety of different types of computing devices can be used to implement the system  100 , such as a server computer, a desktop computer, a laptop or netbook computer, a mobile device (e.g., a tablet or phablet device, a cellular or other wireless phone (e.g., a smartphone), a notepad computer, a mobile station), a wearable device (e.g., eyeglasses, head-mounted display, watch, bracelet, virtual reality glasses or headset, augmented reality headset or glasses), an entertainment device (e.g., an entertainment appliance, a set-top box communicatively coupled to a display device, a game console), an Internet of Things (IoT) device (e.g., objects or things with software, firmware, and/or hardware to allow communication with other devices), a television or other display device, an automotive computer, and so forth. Thus, the computing device implementing system  100  may range from a full resource device with substantial memory and processor resources (e.g., personal computers, game consoles) to a low-resource device with limited memory and/or processing resources (e.g., traditional set-top boxes, hand-held game consoles). 
     The system  100  includes a host operating system  102 , a management and monitoring service  104 , and a web proxy  106 . The management and monitoring service  104  is representative of a service that provides one or more administrative policies for the computing device implementing the host operating system  102 , as discussed herein. The web proxy  106  is representative of functionality that controls access to one or more network resources  122 ( 1 ), . . . ,  122 ( m ) accessed remotely from the computing device implementing the host operating system  102 . For example, in one or more embodiments web proxy  106  controls access to one or more resources accessed from network  108  by requiring authentication from host operating system  102 , as discussed in further detail below. Alternatively, in one or more embodiments the computing device implementing host operating system  102  accesses network resources via network  108  independent of a web proxy. Network  108  represents functionality of a data network, such as the Internet, a local area network (LAN), a public telephone network, an intranet, other public and/or proprietary networks, combinations thereof, and so forth. As such, network resources  122 ( 1 ), . . . ,  122 ( m ) accessed via network  108  may include web sites, web applications, emails, documents, and so on. 
     In one or more embodiments, the host operating system  102 , management and monitoring service  104 , and web proxy  106  are implemented as part of the same computing device. Alternatively, at least part of the management and monitoring service  104  and/or web proxy  106  can be implemented on a device that is separate and remote from the device implementing the host operating system  102 . For example, in one or more embodiments the management and monitoring service  104  is implemented as a mobile device management (MDM) service located remotely from a computing device implementing host operating system  102 . Alternatively or additionally, the management and monitoring service  104  may be implemented as a lightweight directory access protocol (LDAP) server located remotely from a computing device implementing host operating system  102 . Similarly, the web proxy  106  may be implemented remotely from the device implementing the host operating system  102 . 
     The management and monitoring service  104  is configured to provide (e.g., push) policy to the host operating system  102 . In one or more embodiments, the management and monitoring service  104  is configured to push policy to the host operating system  102  at regular intervals, such as at system startup, daily, and so on. Alternatively, the management and monitoring service  104  may be configured to push policy to the host operating system  102  whenever there is an update to policy for the host operating system. Although reference is made herein to policy being pushed to the host operating system  102 , management and monitoring service  104  is configured to provide policy to host operating system via any suitable data transmission methods (e.g., streaming, file-based updates, and so forth.). Alternatively, in one or more embodiments host operating system  102  is configured to obtain (e.g., pull) policy from the management and monitoring service  104 . Some implementations may combine push and pull techniques to obtain policy. The management and monitoring service  104  has two roles. First, the management and monitoring service  104  receives an administrative configuration for individual network resources  122 ( 1 ), . . . ,  122 ( m ) that are generally accessible to a user of the host operating system  102 . In one or more embodiments, these network resources are associated with individual levels of trust. For example, an employer may define any network resource that is associated with the employer&#39;s website as having a high level of trust. Accordingly, policy for the host operating system  102  indicates that any network resources associated with the employer&#39;s website are trusted network resources. The second role of the management and monitoring service  104  is to receive feedback from the host operating system  102  regarding monitored activity associated with individual network resources and to compile that monitored information into a report for an administrator. This compiled report may be used by an administrator to update policy pertaining to trusted network resources for the host operating system  102 . 
     The management and monitoring service  104  may be configured to receive policy configuration data from an administrator of the device that implements the host operating system  102 . As discussed herein, policy describes information pertaining to trusted network resources such as trusted websites, trusted network locations, trusted networks, and so on. When the management and monitoring service  104  receives policy from an administrator, the management and monitoring service  104  is configured to send a policy update to a target set of computing devices. The target set of computing devices to which the management and monitoring service  104  sends policy updates is defined by an administrator in accordance with one or more embodiments. For example, in an enterprise environment as discussed above, the management and monitoring service  104  is configured to send policy updates to each computing device associated with the enterprise. Each computing device that receives a policy update is configured to locally store the policy for use when attempting to access network resources. 
     As discussed in further detail below, the computing device that implements host operating system  102  is configured to dynamically monitor activity associated with accessed network resources  122 ( 1 ), . . . ,  122 ( m ). Monitored activity associated with network resources is updated locally at the host operating system  102  and communicated back to the management and monitoring service  104 . In this manner, the management and monitoring service  104  may be continuously updated to provide a user of the host operating system  102  with an accurate list of trusted network resources. 
     The host operating system  102  also includes a hardware-based virtualized security isolation (HVSI) subsystem  110 , a policy manager  112 , one or more applications  114 , a network filter  116 , a container manager  118 , and a security subsystem  120 . The host operating system  102  also manages one or more containers, illustrated as multiple (n) containers  130 ( 1 ), . . . ,  130 ( n ). 
     HVSI subsystem  110  is representative of functionality for calling network isolation query application programming interfaces (APIs) to determine if a requested network resource is trusted. These network isolation query APIs are exposed by, for example, the policy manager  112 . If HVSI subsystem  110  determines that a requested network resource is trusted, HVSI subsystem  110  allows the requested network resource to be accessed by the host operating system  102 . Alternatively, if HVSI subsystem  110  determines that a requested network resource is not trusted, HVSI subsystem  110  causes the host operating system  102  to activate one or more of containers  130 ( 1 ), . . . ,  130 ( n ) and allow the one or more activated containers to access the untrusted network resource. In one or more implementations, an anonymous container  130  is activated for an application regardless of whether or not the application is trusted. Functionality of the HVSI subsystem  110  will be discussed in further detail below. In accordance with one or more embodiments, HVSI subsystem  110  determines whether a requested network resource is trusted by communicating with policy manager  112 . 
     The policy manager  112  is representative of functionality for obtaining and storing one or more policies for the computing device implementing the host operating system  102 . For example, in one or more embodiments a policy manager  112  obtains and stores one or more administrative policies that define one or more trusted network resources for the host operating system  102 . In accordance with one or more implementations, a policy manager  112  obtains and stores administrative policies from the management and monitoring service  104 . Alternatively or additionally, policy manager  112  obtains and stores one or more administrative policies from a remote source, such as from network  108 . Additionally or alternatively, policy manager  112  receives and stores one or more administrative policies from a user of the device implementing host operating system  102 . 
     Applications  114  include one or more applications that are executable by one or more processors of the computing device implementing the host operating system  102 . For example, applications  114  may include a web browser application. Alternatively or additionally, applications  114  may include applications such as e-mail applications, word processing applications, spreadsheet applications, visual presentation applications, “apps” for mobile devices, and the like. 
     The network filter  116  is representative of functionality for connecting the device implementing host operating system  102  to a network, such as network  108 . Network filter  116  includes at least one physical network interface card and at least one host virtual network interface card. Network filter  116  additionally includes a filter driver, which is configured to intercept requested network resources as they are transmitted from the network  108  to the host operating system  102 . These intercepted network resources are then compared by the HVSI subsystem  110  against one or more policies stored in policy manager  112 . In this manner, network filter  116  ensures that the host operating system  102  is prevented from accessing any untrusted network resources. Similarly, network filter  116  ensures that one or more of containers  130 ( 1 ), . . . ,  130 ( n ) are unable to access any trusted network resources. For example, in one or more embodiments network filter  116  is configured to change data associated with individual packets of a trusted network resource to ensure that the trusted network resource is accessed only by the host operating system  102  and is prevented from being accessed by any of the one or more of containers  130 ( 1 ), . . . ,  130 ( n ). 
     The host operating system  102  additionally includes a container manager  118 . The container manager  118  manages the scheduling of containers  130 ( 1 ), . . . ,  130 ( n ) in the system  100  and determines which containers  130 ( 1 ), . . . ,  130 ( n ) are run on the host operating system  102  at what times. Container manager  118  is also responsible for activating one or more containers  130 ( 1 ), . . . ,  130 ( n ) for an individual user of the system  100  and for ensuring that other users of the system  100  cannot access the one or more containers  130 ( 1 ), . . . ,  130 ( n ) created for the individual user. Container manager  118  is also configured to collect logs and traces from any one or more created containers  130 ( 1 ), . . . ,  130 ( n ) for telemetry and security indicators. For example, in one or more embodiments, container manager  118  consults anti-virus applications installed on the host operating system  102  to interpret collected information and provides monitored data to the HVSI subsystem  110 . Depending on the number of physical processors and/or processor cores in the computing device running the host operating system  102 , a single container  130 ( 1 ), . . . ,  130 ( n ) can be run at a time (e.g., in the case of a single processor with a single core) or alternatively multiple containers  130 ( 1 ), . . . ,  130 ( n ) can be run concurrently (e.g., in the case of multiple processors and/or multiple processor cores). Additionally, in one or more embodiments container manager  118  is configured to monitor user configuration changes that are performed within one or more of containers  130 ( 1 ), . . . ,  130 ( n ). For example, container manager  118  is configured to detect changes to user preferences associated with a web site accessed in one of containers  130 ( 1 ), . . . ,  130 ( n ). Host operating system  102  is configured to use these detected changes in the container and apply them to one or more related web sites that are accessed in the host operating system. Additionally, in one or more embodiments, container manager  118  is configured to activate an anonymous container  130  for an application, regardless of whether or not the application is trusted. 
     Security subsystem  120  is representative of functionality for enforcing security policy on the host operating system  102 . Security subsystem  120  is configured to verify a user logging on to a device implementing the host operating system  102 , handle password changes for the logged on user, create access tokens for a logged on user, and so on. 
     Each container  130 ( 1 ), . . . ,  130 ( n ) can be implemented in different manners. One type of container that a container  130  can be implemented as is referred to as a process container. For a process container, the application processes within the container run as if they were operating on their own individual system (e.g., computing device), which is accomplished using namespace isolation. Host operation system  102  implements namespace isolation. Namespace isolation provides processes in a container a composed view consisting of the shared parts of host operating system  102  and the isolated parts of the operating system that are specific to each container such as filesystem, configuration, network, and so forth. 
     Another type of container that a container  130  can be implemented as is referred to as a virtualized container. For a virtualized container, the virtualized container is run in a lightweight virtual machine that, rather than having specific host physical memory assigned to the virtual machine, has virtual address backed memory pages. Thus, the memory pages assigned to the virtual machine can be swapped out to a page file. The use of a lightweight virtual machine provides additional security and isolation between processes running in a container. Thus, whereas process containers use process isolation or silo-based process isolation to achieve their containment, virtualized containers use virtual machine based protection to achieve a higher level of isolation beyond what a normal process boundary can provide. A container may also be run in a virtual machine using physical memory. 
     In one or more embodiments, each container  130 ( 1 ), . . . ,  130 ( n ) includes one or more virtual applications  132 ( 1 ), . . . ,  132 ( n ). Individual ones of the one or more virtual applications  132 ( 1 ), . . . ,  132 ( n ) correspond to instances of individual ones of the applications  114  on host operating system  102 . Virtual applications  132 ( 1 ), . . . ,  132 ( n ) are thus useable to access untrusted network resources in one or more of containers  130 ( 1 ), . . . ,  130 ( n ) in a similar manner to how one of applications  114  would access a trusted network resource on the host operating system  102 . 
     Having considered an example system for implementing distribution and management of services in virtual environments, consider now an example architecture for the system implementing hardware-based virtualized security isolation in accordance with one or more embodiments. 
       FIG. 2  illustrates an example system architecture  200  for distribution and management of services in virtual environments in accordance with one or more embodiments. Although discussed herein as hardware-based virtualized security isolation, it is to be appreciated and understood that the techniques discussed herein may also be referred to as virtualization based isolation (VBI). System architecture  200  is implemented at least in part by a computing device. Any of a variety of different types of computing devices can be used to implement the system architecture  200 , analogous to the discussion above regarding types of that can be used to implement the system  100  of  FIG. 1 . 
     In the illustrated example, the computing device implementing the system architecture  200  includes the host operating system  102  and the container  130 . The host operating system  102  is isolated from any one or more containers  130  to protect the host operating system from attacks or infections that may result from untrusted network resources. 
     The host operating system  102  is illustrated as including HVSI subsystem  110 , policy manager  112 , network filter  116 , container manager  118 , and security subsystem  120 . Additionally, the host operating system  102  includes application  202 , which may be one of applications  114  illustrated in  FIG. 1 . Application  202  includes HVSI library  204 , the functionality of which will be discussed in further detail below. 
     The container  130  includes virtual application  206 , which is representative of an instance of application  202  included in host operating system  102 . The container  130  additionally includes a virtual security subsystem  210 , the functionality of which is discussed in further detail below. Additionally, the container  130  includes a logging system  214 , which is representative of functionality of content manager  118  to manage and monitor network resource activity within one or more containers  130  activated by the device implementing system architecture  200 . 
     The host operating system  102  and the container  130 , although isolated from one another, are communicatively connected via virtual machine bus  216 . Virtual machine bus  216  is a communication channel that allows the host and container portions to communicate with one another. Additionally or alternatively, the host operating system  102  and the container  130  are communicatively connected via other means such as a physical network, a virtual network, simple message block (SMB) protocol, or remote procedure call (RPC) interconnections. 
     Having considered a system architecture for a system implementing hardware-based virtualized security isolation, consider now functionality of individual components illustrated in the host portion and the container portion of system architecture  200 . 
     HVSI Subsystem 
     HVSI subsystem  110  is representative of functionality for implementing hardware-based virtualized security isolation in the computing device implementing system architecture  200 . In order to implement hardware-based virtualized security isolation, HVSI subsystem  110  is configured to communicate with the policy manager  112 , the network filter  116 , the container manager  118 , security subsystem  120 , application  202 , and any one or more containers  130 . In one or more embodiments, HVSI subsystem  110  is automatically launched upon startup of the computing device implementing system architecture  200 . Alternatively, HVSI subsystem  110  is launched at other times, such as by HVSI library  204  of application  202  when the application  202  is launched by the host operating system. 
     When HVSI subsystem  110  is launched, it calls container manager  118  to create a container for a user logged on to the computing device implementing system architecture  200 , if a container for the user does not already exist. The container manager  118  will create a random or pseudo-random unique local account credential to use to connect to the container. This local account credential is known only to the host operating system  102  and is used to connect the host operating system  102  to the container. A transaction of the local account credential between the host operating system  102  and the container is transparent to a user of host operating system  102  and prevents malicious attacks or infections from connecting to the container over the host operating system  102 &#39;s physical network Internet connection. In embodiments where host operating system  102  has multiple users, container manager  118  is configured to create separate containers for individual users. Each separate container has a different random or pseudo-random unique local account credential such that host operating system  102  is restricted from accessing any containers that were not created for a logged-on user. Container manager  118  ensures this container separation by authenticating associated user credentials before permitting accesses to one or more containers. Note that in some embodiments, the user data is settable by policy. For example, the username may be something that is spoofed to look to applications as if it is a real name. In some embodiments, the user information is saved and re-used with new containers to ensure that the user looks consistent to the applications. 
     HVSI subsystem  110  then instructs container manager  118  to suspend the container until HVSI subsystem  110  detects that an application running on the computing device implementing system architecture  200  is attempting to access one or more untrusted network resources. HVSI subsystem  110  is configured to monitor communications between the host operating system and one or more remote resource locations based on information provided to HVSI subsystem  110  by network filter  116 . 
     When host operating system  102  attempts to access a network resource, HVSI subsystem  110  communicates with the policy manager  112  to determine if the requested network resource is a trusted network resource. If HVSI subsystem  110  determines that the requested network resource is a trusted network resource, HVSI subsystem  110  permits the trusted network resource to be accessed by an application in host operating system  102 , such as application  202 . Information associated with a network resource that HVSI subsystem  110  may use to determine if the network resource is trusted includes, file type, application type, results of an anti-virus scan of the network resource, a virus signature, email source information, document metadata, URLs, IP addresses, TCP ports, DNS name, hardware device identifiers, or combinations thereof. For example, if HVSI subsystem  110  ascertains that application  202  is requesting to navigate to a particular web page, HVSI subsystem  110  compares information associated with the particular web page with one or more policies from the policy manager  112  and permits the application  202  to access the particular web page in response to determining that the particular web page is trusted. HVSI subsystem  110  determines that the particular web page is trusted, for example, based on one or more of the particular web page&#39;s fully qualified domain name (FQDN), root site domain name utilizing the domain name server (DNS), internet protocol (IP) address, or similar uniform resource locator (URL) addressing method. In accordance with one or more embodiments, HVSI subsystem  110  is additionally configured to determine if a network resource is trusted by receiving information from a cloud-based service implemented remotely from computing device  102  that maintains a list of malicious network resources. For example, if HVSI subsystem  110  ascertains that application  202  is requesting to navigate to a particular web page, HVSI subsystem  110  consults a cloud-based service via network  108  to compare the particular web page against a list of potentially malicious network resources stored at the cloud-based service. If the cloud-based service indicates that the particular web site is included in the list of potentially malicious network resources, the particular web page is determined to be untrusted. 
     Alternatively, if HVSI subsystem  110  determines that a requested network resource is not a trusted network resource, HVSI subsystem  110  causes container manager  118  to activate container  130  to handle the untrusted network resource. Based on the type of application that is requesting the untrusted network resource in the host system, HVSI subsystem  110  instructs the container manager  118  to launch a virtual version of the application within container  130 . For example, if HVSI subsystem  110  determines that application  202  is requesting access to an untrusted network resource, HVSI subsystem  110  instructs container manager  118  to create the virtual application  206  within container  130 . In this manner, container  130  is configured to interact with one or more untrusted network resources just as the host operating system  102  would interact with one or more trusted network resources. In one or more embodiments, container  130  is activated by and implemented on the device implementing host operating system  102 . Alternatively, container  130  is activated by and implemented on a device that is different from the device implementing host operating system  102 . Alternatively, container  130  is implemented by a device that is different from the device implementing operating system  102  but is activated by the device implementing host operating system  102 . 
     In order for a user of the computing device implementing host operating system  102  to view and otherwise interact with any one or more untrusted network resources that are accessed by a virtual application within container  130 , HVSI subsystem  110  is configured to communicate with container  130  to cause display of an interface for the virtual application  206 . For example, in one or more embodiments HVSI subsystem  110  uses a remote applications integrated locally (RAIL) mode of a remote desktop protocol (RDP) using virtual machine bus  216 . In this manner, host operating system  102  may display an interface of virtual application  206  at a display device of the device implementing host operating system  102 . In one or more embodiments, the interface is configured so that a user of host operating system  102  perceives the interface to be part of the host operating system itself. Alternatively, HVSI subsystem  110  is configured to display an interface corresponding to virtual application  206  with a visual indication that the displayed interface corresponds to one or more untrusted network resources. In other embodiments, the HVSI subsystem  110  uses an X Window System or an alternative remote desktop implementation to display an interface corresponding to virtual application  206 . 
     After container  130  is activated by container manager  118 , network filter  116  filters all network resource calls from host operating system  102  and container  130 . For example, HVSI subsystem  110  instructs network filter  116  to block all calls to untrusted network resources from host operating system  102  and allow only trusted network resource calls from host operating system  102 . Similarly, HVSI subsystem  110  instructs network filter  116  to allow all calls to untrusted network resources from container  130  and block all calls to trusted network resources from container  130 . 
     HVSI subsystem  110  is configured to instruct container manager  118  to monitor all activity associated with untrusted network resources that are accessed by container  130 . When HVSI subsystem  110  receives an indication from container manager  118  that all instances of virtual applications  206  running in container  130  are terminated, HVSI subsystem  110  terminates any connection between host operating system  102  and any containers  130  being accessed by host operating system  102 . HVSI subsystem  110  will then either suspend or terminate the one or more containers  130 . For example, in one or more embodiments when HVSI subsystem  110  ascertains that processing of virtual application  206  has ended, HVSI subsystem  110  terminates a connection with container  130  and suspends the container to wait for further requests for untrusted network resources. Alternatively, if HVSI subsystem  110  determines that a user has logged off the device implementing system architecture  200 , HVSI subsystem  110  terminates any one or more containers  130  that were activated by host operating system  102 . 
     By communicating with components of host operating system  102 , such as policy manager  112 , network filter  116 , container manager  118 , and security subsystem  120 , HVSI subsystem  110  is configured to determine if a requested network resource is trusted, restrict opening of the untrusted network resources to an isolated container, and manage one or more processes running within the isolated container. This allows HVSI subsystem  110  to perform hardware-based virtualized security isolation techniques in order to protect the device implementing host operating system  102  from kernel level attacks or infections that may be caused by untrusted network resources. 
     Having considered an example system architecture of a host operating system that performs hardware-based virtualized security isolation, consider now individual components of a host operating system in accordance with one or more embodiments. 
     Policy Manager 
     Policy manager  112  represents functionality of host operating system  102  for obtaining and storing one or more policies for a computing device implementing the host operating system. For example, policy manager  112  is configured to obtain and store one or more policies from the management and monitoring service  104  illustrated in  FIG. 1 . Each of the one or more policies specifies one or more trusted network resources that host operating system  102  is allowed to access. Additionally, a policy may specify one or more policy objects and one or more corresponding security parameters for the policy object. These policy objects and corresponding security parameters provide constraints defining how the host operating system may interact with one or more untrusted network resources. 
     For example, a policy object may identify whether host operating system  102  is allowed to implement virtual applications in isolated containers, such as container  130 . If the corresponding security parameter for this policy object indicates that host operating system  102  is allowed to implement virtual applications and isolated containers, then the host operating system may open one or more untrusted network resources in virtual application  206  of isolated container  130 . Alternatively or additionally, a policy object indicates certain virtual applications that are allowed to open in an isolated container. The corresponding security parameter for this policy object may identify one or more specific applications that are allowed to be virtually opened in an isolated container. Alternatively or additionally, a policy object indicates what host operating system  102  may copy between isolated container  130  and host operating system  102  itself. The corresponding security parameter specifies one or more file types that may be copied in between isolated container  130  and host operating system  102 . Alternatively or additionally, a policy object indicates print settings for virtual applications opened in isolated container  130 . The corresponding security parameter for this policy object indicates whether virtual application  206  running in isolated container  130  may print and, if so, one or more printers, applications, or file types to which virtual application  206  is allowed to print. Alternatively or additionally, a policy object indicates whether network traffic for virtual application  206  is allowed. The corresponding security parameter for this policy object may specify one or more virtual applications for which network traffic is allowed within an isolated container. Alternatively or additionally, a policy object indicates whether background tasks for virtual application  206  are allowed. The corresponding security parameter specifies one or more virtual applications for which background tasks are allowed within isolated container  130 . Alternatively or additionally, a policy object indicates whether the virtual application  206  running in the container is allowed to leverage one or more hardware resources of the computing device implementing host operating system  102 , such as the computing device&#39;s GPU for graphics acceleration. 
     The following table provides an example set of policy objects and corresponding security parameters, such as those discussed above. In accordance with standard security procedures, this example policy has a default deny rule implied, which is not illustrated. It is to be appreciated and understood however, that the discussed policy objects and corresponding security parameters are exemplary and not exhaustive in scope. 
     
       
         
           
               
               
             
               
                   
               
               
                 Policy Object 
                 Security Parameter 
               
               
                   
               
             
            
               
                 Allow Virtual Application Isolation 
                 Yes 
               
               
                 in Container? 
               
               
                 Virtual Applications for Container 
                 Web browser, Notepad, Word 
               
               
                 Isolation 
                 processing application, email 
               
               
                   
                 application. 
               
               
                 Clipboard Settings 
                 Text and Images Allowed 
               
               
                 Print Settings 
                 Printer 1; Print to PDF; Print to 
               
               
                   
                 XPS 
               
               
                 Network Traffic for Virtual Isolated 
                 Enabled for web browser 
               
               
                 Applications? 
               
               
                 Background Tasks for Virtual Isolated 
                 Enabled for email application 
               
               
                 Applications? 
               
               
                   
               
            
           
         
       
     
     When host operating system  102  starts up, HVSI subsystem  110  contacts policy manager  112  to obtain a list of trusted network resources for the host operating system, along with any policy objects and corresponding security parameters. HVSI subsystem  110  aggregates these trusted network resources, policy objects, and corresponding security parameters and applies this aggregated policy to host operating system  102 . In one or more embodiments, this aggregated policy is queried each time host operating system  102  requests to perform an action or attempts to access a network resource. For example, when host operating system  102  requests to open application  202  that is included in the security parameter corresponding to the policy object “Virtual Applications for Container Isolation”, HVSI subsystem  110  causes host operating system  102  to open a virtual version of that application  206  in isolated container  130 . 
     HVSI subsystem  110  is additionally configured to monitor activity within one or more of isolated container(s)  130  to ensure that the container(s) do not gain access to any trusted network resources. For example, if a virtual version of a web browser is running in isolated container  130 , and HVSI subsystem  110  detects that the virtual web browser is attempting to access a network resource that is indicated by the policy manager  112  as a trusted network resource, HVSI subsystem  110  may prevent the virtual web browser from opening or otherwise accessing this trusted network resource and instead cause the trusted network resource to be opened within a corresponding web browser on host operating system  102 . By restricting access and opening of trusted network resources to host operating system  102  and restricting access and opening of untrusted network resources to one or more isolated containers  130 , HVSI subsystem  110  ensures that trusted network resources are not corrupted by any untrusted network resources. 
     In addition to receiving the list of trusted network resources, policy objects, and corresponding security parameters from the policy manager  112 , host operating system  102  is configured to observe one or more local events that could impact policy for the host operating system. For example, consider a scenario where a virtual web browser is running within isolated container  130 . HVSI subsystem  110  monitors the behavior of each network resource accessed by the virtual web browser within isolated container  130 . When the virtual web application navigates to an untrusted network resource, downloading the untrusted network resource may cause a registry of container  130  to be written to in an unexpected manner. Using container manager  118 , which is discussed in further detail below, HVSI subsystem  110  obtains data from container  130  and calculates an updated local policy for the untrusted network resource. For example, in one or more embodiments HVSI subsystem  110  updates local policy for the untrusted network resource by disabling printing and copying settings associated with the untrusted network resource. HVSI subsystem  110  is then configured to aggregate this obtained data and report the obtained data to a remote service, such as the management and monitoring service  104  illustrated in  FIG. 1 . In accordance with one or more embodiments, the HVSI subsystem  110  consults locally installed applications of host operating system  102 , such as antivirus applications for additional information in updating this local policy. For example, HVSI subsystem  110  uses one or more antivirus applications to scan an untrusted network resource in container  130  and assign a security level to the untrusted network resource. In this manner, HVSI subsystem  110  is configured to continually update policy and further protect the computing device implementing host operating system  102  against untrusted network resources. 
     In one or more embodiments, HVSI subsystem  110  implements an independent host-based policy engine that responds to local activity at host operating system  102  and container  130 . This independent host-based policy engine reduces round trips to the management and monitoring service  104 , enabling the management and monitoring service to manage many clients. In one or more embodiments, policy manager  112  obtains a template or a signature from management and monitoring service  104 . Policy manager  112  provides this template or signature to HVSI subsystem  110 . When container  130  is activated, HVSI subsystem  110  computes the required policy based on a pattern from the policy template or signature that it matches to activity observed in container  130 . For example, if a virtual web application is running in container  130 , and a network resource the virtual web application is trying to access as a URL matches a pattern in the policy template, HVSI subsystem  110  calculates a risk level and updates the policy. This dynamically results in a specific action applied to the virtual application in container  130 , such as an allow action, a block action, or a redirect action. In this embodiment, the policy is dynamic, offloading local assessment and policy from the management and monitoring service  104  to HVSI subsystem  110 . 
     As an alternative example, consider a scenario where a user downloads and installs a new application from an untrusted web site within container  130 . In this example, HVSI subsystem  110  assesses the downloaded application against existing policy, and calculates policy that applies to the downloaded application in isolated container  130 . In one or more embodiments, this calculated policy is based on one or more policy objects and corresponding security parameters of similar applications. For example, if the downloaded application is an e-mail application, HVSI subsystem  110  identifies one or more policy objects and corresponding security parameters pertaining to other e-mail applications and applies similar policy settings for the downloaded e-mail application. HVSI subsystem  110  is configured to monitor activity associated with the downloaded application within container  130  and is configured to recalculate local policy based on this observed activity. Additionally or alternatively, information describing observed activity of any one or more downloaded applications or accessed network resources within container  130  is aggregated and communicated to a remote service, such as the management and monitoring service  104  illustrated in  FIG. 1 . In some embodiments, the host operating system  102  performs local analysis on the information describing observed activity within container  130  and calculates additional security policy. For example, if a downloaded application is exhibiting anomalous behavior, the downloaded application may be terminated and the container reset to its previous operational state prior to downloading the application. As discussed herein, anomalous behavior in the container refers to, for example, an indicator that is interpreted by HVSI subsystem  110  as an attempt to compromise a kernel or operating system of container  130 . 
     In order to enforce policy for host operating system  102 , HVSI subsystem  110  employs one or more network filters, such as network filter  116 . 
     Network Filter 
     Network filter  116  is representative of functionality for intercepting and inspecting ingoing and outgoing network traffic for host operating system  102 . Network filter  116  has enforcement functionality for network traffic including forwarding, blocking and/or modifying network traffic, among other capabilities. For example, network filter  116  is configured to intercept and inspect all network traffic and data communication in between host operating system  102  and any one or more isolated containers  130 . Similarly, network filter  116  is configured to intercept and inspect all network traffic and data communication in between host operating system  102  and any remote resource locations accessed via network, such as network  108  illustrated in  FIG. 1 . In one or more embodiments, in order to interface host operating system  102  with any one or more isolated containers  130 , network filter  116  includes a virtual switch, at least one network interface card for the host operating system, and one or more virtual network interface cards for the one or more isolated containers. 
     Using policy received from policy manager  112 , HVSI subsystem  110  interfaces with network filter  116  to ensure that container  130  is not able to access trusted network resources. Similarly, HVSI subsystem  110  interfaces with network filter  116  to ensure that host operating system  102  is not able to access or otherwise open any one or more untrusted network resources. In one or more embodiments, network filter  116  is configured to change data of individual packets associated with trusted network resources to ensure the trusted data remains on host operating system  102  and does not flow to container  130 . As discussed in further detail below, in a proxy authentication scenario, the network filter  116  injects credential information into network traffic to ensure proxy traversal and prevent credentials from leaking into or otherwise being accessed by the container. In some embodiments, the network filter  116  validates that network traffic is originating or terminating at a network resource that was queried during DNS lookup. To accomplish this, identifiers based on allowed network resources are plumbed inside the container and associated with one or more network resource names. A network stack in the container includes these identifiers in the network traffic. The network filter  116  validates whether an identifier matches a network resource name. If the validation is successful, the traffic is forwarded, if it fails, the traffic is dropped. In some embodiments, the network filter  116  strips the identifier from forwarded network traffic. 
     In accordance with one or more embodiments, network filter  116  is implemented as a virtual switch extension. Alternatively, network filter  116  is implemented as any module that has multiple abilities including to intercept, inspect, forward, modify, and block network traffic. In other embodiments the network filter is built into firewall or other security software of the computing device implementing host operating system  102 . In accordance with one or more embodiments, network filter  116  is installed on host operating system  102  when policy is received at the host operating system. For example, network filter  116  may be installed when the policy manager  112  receives policy from the management and monitoring service  104  illustrated in  FIG. 1 . However, because network filter  116  requires resources (e.g., memory) of the device implementing host operating system  102 , in one or more embodiments network filter  116  is not installed when there is no policy present on the host operating system. In this manner, when there is no policy to divert untrusted network resources to isolated containers, such as container  130 , network filter  116  is not installed to reduce resource overhead. 
     In some embodiments, the network filter  116  enforces which network interface is used to connect to a resource. For example, while host operating system  102  is in an enterprise, security is assumed. In the enterprise, application  202  running on host operating system  102  may simply use any available physical interface (e.g. Ethernet, Wi-Fi, etc.). However, when the host operating system  102  is on a public network (e.g. outside the enterprise at a coffee shop&#39;s public Wi-Fi), the network filter  116  may only allow application  202  and other applications running on host operating system  102  to use a certain network interface, such as a VPN interface, improving network security. In some configurations, network filter  116  allows one or more applications running in container  130  to access the public network without using VPN. In embodiments where one network interface is isolated for host operating system  102  communications and a different network interface is isolated for container  130  communications, network filter  116  is configured to provide an indication to a network stack of container  130  that network communications for the container are isolated to the different network interface. 
     HVSI subsystem  110  calls network filter  116  and causes network filter  116  to attach itself to network ports of the device implementing host operating system  102 . Once network filter  116  is attached to the network ports, it is able to monitor, filter, and/or block network traffic. In one or more embodiments, the network filter  116  includes a local DNS server to further enforce policy for host operating system  102 . For example, in one or more embodiments network filter  116 &#39;s DNS server maps network resources to corresponding IP addresses to verify an origin of individual network resources. In one or more implementations, the network filter  116  includes one or more input/output control systems (IOCTLs) that are configured to allow or block a network traffic for both host operating system  102  and any one or more containers  130 . In other implementations this configuration is performed through an API, a file, or a command shell. 
     Network filter  116  is configured to monitor network traffic (e.g., HTTP traffic) to ensure that host operating system  102  and container  130  are not accessing network resources that are not allowed for the respective host operating system or container. In order to monitor HTTP traffic, network filter  116  performs HTTP header inspection with one or more web proxies facilitating network traffic between host operating system  102  and/or any one or more isolated containers  130 , such as web proxy  106  illustrated in  FIG. 1 . Alternatively, in accordance with one or more embodiments, network filter  116  is configured to implement its own HTTP proxy. 
     To support network communication functions in proxied environments and across network changes, network filter  116  includes a network address translator (NAT). The NAT provides container  130  with a private network and a gateway to reach a network outside host operating system  102 . In accordance with one or more embodiments, the NAT is configured to forward outside network proxy configuration and forward outside network change notifications to host operating system  102 . For example, in one or more embodiments network filter  116  uses a NAT to forward network change notifications to host operating system  102  when a network connection status changes, such as when a Wi-Fi (IEEE 802.11) Network adapter leaves or enters range of a Wi-Fi Network. Additionally, network filter  116 &#39;s NAT is configured to emulate an outside network identity to ensure that container  130  can identify different networks correctly. For example, the NAT can take the media access control (MAC) address of the host&#39;s external network gateway and re-use it as the private network gateway MAC address provided by NAT. This ensures that container  130 &#39;s HTTP software will appropriately align the HTTP cache and ensure proxy discovery is not duplicated when reconnecting to the same network. By emulating an outside network identity, network filter  116 &#39;s NAT significantly improves network reconnect performance and improve user experience for a user of host operating system  102 . Additionally, network filter  116 &#39;s NAT is configured to forward “low-power connected standby” settings to host operating system  102  for one or more virtual applications  206  that are running in one or more isolated containers, such as container  130 . This enables host operating system  102  to keep alive any virtual applications  206  running in one or more active isolated containers  130 . In one or more embodiments, functionality of the NAT is offloaded to a different component of host operating system  102 . For example, provisioning a private network and gateway to reach a network outside host operating system  102 , forwarding network change notifications, emulating an outside network identity, and forwarding low-power connected standby settings can be performed by one or a combination of network filter  116 , HVSI subsystem  110 , or container manager  118 . 
     HVSI subsystem  110  is configured to interact with network filter  116  to perform web proxy authentication in accordance with one or more embodiments. For example, many enterprise systems use one or more web proxies to control Internet access for individual users of the enterprise. These web proxies require authentication before allowing individual users or applications to access network resources, such as web sites, by prompting user credentials such as a username and associated password. Accordingly, network filter  116  is configured to identify a web proxy that is required to facilitate access to a web site, such as web proxy  106  illustrated in  FIG. 1 . However, in scenarios where a virtual application running in an isolated container requires web proxy authentication, security concerns arise. For example, one or more untrusted network resources that are open and running in the isolated container  130  might gain unauthorized access to the user credentials and compromise security of associated user accounts. 
     In order to provide a seamless user experience for virtual applications  206  running in container  130  that require web proxy authentication, HVSI subsystem  110  is configured to provide user credentials to a web proxy from host operating system  102  without providing the user credentials to container  130 . HVSI subsystem  110  is configured to provide user credentials to a web proxy for virtual application  206  running in container  130  by implementing virtual security subsystem  210  within the isolated container. Virtual security subsystem  210  is configured to interface with security subsystem  120  of host operating system  102 . For example, in one or more embodiments HVSI subsystem  110  detects that virtual web application  206  is calling a network resource that requires web proxy authentication. HVSI subsystem  110  is configured to implement virtual security subsystem  210  within the isolated container so that the virtual security subsystem  210  can interface with security subsystem  120  of host operating system  102 . Communication between virtual security subsystem  210  and security subsystem  120  may be performed over the connection established by HVSI subsystem  110 , such as via virtual machine bus  216 . 
     When virtual web application  206  in container  130  attempts to access a network resource via a web proxy, the web proxy returns with a challenge for user credentials. In this scenario, virtual security subsystem  210  is configured to call security subsystem  120  of host operating system  102  to provide authentication to the web proxy. In response to receiving this call, security subsystem  120  is configured to generate a dummy credential blob that indicates ownership of the user credentials without actually containing the user credentials within the credential blob. As discussed herein, a dummy blob may also be referred to as a pseudo-authentication of the user credentials. Security subsystem  120  returns the generated dummy credential blob to virtual security subsystem  210 . Virtual security subsystem  210  then provides the dummy credential blob to virtual web application  206  so that the virtual web application can embed the dummy credential blob in an HTTP response to the web proxy. In this manner, container  130  is configured to prove ownership of user credentials without receiving the actual user credentials from host operating system  102 . In accordance with one or more embodiments, proof of credential ownership within the dummy blob is performed by applying a hash security function to the actual credentials and including the hashed credentials within the dummy blob. This ensures that user credentials are not compromised by any untrusted network resources that may be running in container  130 . 
     Alternatively, if virtual security subsystem  210  forwards a web proxy request for user credentials to security subsystem  120  of host operating system  102 , security subsystem  120  is configured to generate two credential blobs. The first credential blob generated by security subsystem  120  is a dummy credential blob as described above. The second credential blob generated by security subsystem  120  contains the actual user credentials requested by the web proxy. In this scenario, the dummy credential blob is provided to the virtual security subsystem  210  in container  130 , and the blob containing the actual user credentials is provided to network filter  116  in host operating system  102 . As discussed above, virtual web application  206  is configured to receive the dummy credential blob from virtual security subsystem  210  and embed the dummy credential blob in an HTTP response to the web proxy. Because all network traffic from both host operating system  102  and container  130  are filtered through network filter  116 , network filter  116  is configured to intercept the HTTP response from the container and replace the dummy blob with the actual user credential blob before transmitting the HTTP response to the web proxy. In accordance with one or more embodiments, where host operating system  102  is functioning in a nested computing environment, this credential blob replacement may be performed multiple times, at each layer of the nested environment. Alternatively, in one or more embodiments, network filter  116  plumbs allowed network resource identifiers within container  130  to validate that network traffic is originating and terminating at a network resource that was queried during DNS lookup, as discussed above. 
     When HVSI subsystem  110  determines that host operating system  102  is attempting to access an untrusted network resource, using policy manager  112 , network filter  116 , and security subsystem  110  as discussed herein, HVSI subsystem  110  communicates with container manager  118  to manage and monitor one or more containers  130  for accessing the untrusted network resource. 
     Container Manager 
     Container manager  118  is responsible for activating one or more containers  130  that are isolated from host operating system  102  to access untrusted network resources. As discussed herein, activating a container such as container  130  includes creating one or more new containers or resuming running of one or more suspended containers. In accordance with various implementations, container manager  118  is further configured to anonymize generation of the one or more containers  130 . Container manager  118  is additionally configured to activate one or more containers for an individual user logged into host operating system  102  and ensure that any other users of the host operating system are restricted from accessing the activated one or more containers for the individual user. Container manager  118  ensures a mapping of the user logged into host operating system  102  to the container  130 . In some embodiments in which there are multiple users of host operating system  102  and multiple containers, the container manager  118  is configured to see a logged-on user&#39;s identity and directly associate that with one or more corresponding containers. This restriction prevents other users from viewing or otherwise interacting with the containers. 
     Container manager  118  is further configured to collect logs and traces describing activity within container  130 . Container manager  118  is configured to use these logs and traces to monitor container usage for telemetry and security indicators. In accordance with one or more embodiments, container manager  118  consults with local applications installed on host operating system  102 , such as an antivirus application, in order to interpret any security issues associated with monitored activity in container  130 . Container manager  118  is configured to aggregate this monitored information and provide the monitored information to HVSI subsystem  110 . Alternatively or additionally, container manager  118  is configured to provide this monitored information to one or more remote sources, such as management and monitoring service  104  illustrated in  FIG. 1 . 
     When host operating system  102  starts up, HVSI subsystem  110  determines whether policy is present. In one or more embodiments, HVSI subsystem  110  determines whether policy is present by communicating with policy manager  112 , as discussed herein. If HVSI subsystem  110  determines that policy is present on host operating system  102 , container manager  118  is configured to activate container  130  to handle any untrusted network resources that are requested by the host operating system. Container manager  118  is configured to activate container  130  by communicating with host operating system  102  to determine if a container base image exists. If container manager  118  determines that a container base image does not exist, container manager  118  is configured to create a container base image. If container manager  118  determines that a container base image does exist, or after container manager  118  creates a container base image, container manager  118  waits for a user to log onto host operating system  102 . 
     A container base image contains information required to create and activate an isolated container that includes its own operating system, such as container  130 . For example, in one or more embodiments a container base image contains information describing how host operating system  102  is to set registry settings for a container. Information regarding registry settings is required because some virtual applications that are opened inside container  130  behave differently than a version of the application that would be opened on host operating system  102 . Additionally or alternatively, a container base image includes information describing how to create a user account within a virtual application executed in container  130 . Additionally or alternatively, the container base image includes information regarding an amount of allocated resources, such as memory, processors, disks, or networks, which may be required by container  130  when active. 
     When a user logs onto host operating system  102 , container manager  118  determines whether a container corresponding to the container base image exists. If container manager  118  determines that a container does not exist for the container base image, container manager  118  may create a container, such as container  130 . To ensure that a container base image accurately represents the host operating system  102 , container manager  118  is configured to invalidate any existing container base images and create one or more new container base images after an operating system update. In this manner, container manager  118  ensures that a container base image includes any updated host operating system binaries, thereby keeping containers created from the container base image up to date with the host operating system  102 . In the event of a host operating system  102  update, container manager  118  is configured to either force close any open containers or wait until user activity in the container has ceased to delete the container base image and create a new container base image. After creating the container, container manager  118  places the container into a suspended mode. When a container is in a suspended mode, the container consumes fewer resources of the device implementing host operating system  102 , thereby reducing resource overhead. Container manager  118  is configured to maintain one or more isolated containers  130  in a suspended mode until host operating system  102  requests access to one or more untrusted network resources. 
     When HVSI subsystem  110  detects that host operating system  102  is requesting access to one or more untrusted network resources, HVSI subsystem  110  instructs container manager  118  to activate one or more suspended containers in order to handle the one or more untrusted network resources. In one or more embodiments, the one or more containers are hosted on the computing device that is implementing host operating system  102 . Alternatively, at least one of the one or more containers may be hosted on a computing device that is remote from the computing device implementing host operating system  102 . In a scenario where a container is hosted on a different computing device, container manager  118  is configured to communicate with the different computing device to manage and monitor the remote containers. Because the container manager  118  can activate a suspended container faster than it can create a container, maintaining one or more suspended containers allows host operating system  102  to quickly respond to requests for untrusted network resources. 
     In response to determining that host operating system  102  is requesting access to one or more untrusted network resources, container manager  118  is configured to identify an application on the host operating system that is requesting the untrusted network resource. Container manager  118  is configured to launch a virtual version of the application within container  130  to handle the untrusted network resource. After container manager  118  activates a virtual version of the application within container  130 , HVSI subsystem  110  is configured to remote into container  130  to display an interface of the virtual application at a display of the device implementing host operating system  102 . 
     Container manager  118  is configured to communicate with HVSI subsystem  110  to ensure that appropriate hardware virtualization technology exists on host operating system  102 , and in container  130 , if the container is hosted by a remote computing device. For container manager  118  to function properly, the container manager  118  is configured to verify that host operating system  102 &#39;s application programming interfaces (APIs) are available to manage isolated container lifecycles and associated network stacks. 
     Container manager  118  is configured to monitor activity within container  130  using logging system  214 . In this manner, container manager  118  is configured to detect any suspicious behavior of a network or network resource that is accessed within container  130 , whether container  130  is taking up too much disk space, and so on. Based on information obtained from logging system  214 , container manager  118  is able to inform HVSI subsystem  110  how to manage one or more containers  130 . For example, in one or more embodiments container manager  118  ascertains that access to one or more untrusted network resources within container  130  has completed and communicates this information to HVSI subsystem  110 . In response to receiving this information, HVSI subsystem  110  places container  130  into a suspended mode until it is subsequently needed to handle an additional untrusted network resource. 
     Container manager  118  is also configured to monitor and determine when a user of host operating system  102  logs off. In response to determining that a user of host operating system  102  has logged off, container manager  118  provides this information to HVSI subsystem  110 . HVSI subsystem  110  is configured to delete one or more containers  130  in response to the user logging off. As discussed herein, deleting a container also clears any information included within the container. 
     Container manager  118  is also configured to share DNS and Hypertext Transfer Protocol (HTTP) information from the host operating system  102  to improve web browsing performance or other network activity within the one or more of the isolated containers. In one or more embodiments, container manager  118  maintains a cache of DNS queries made from earlier instances where container  130  accessed network resources, as well as HTTP data such as Internet data files or web site cookies that enable future requests in a container to access untrusted web sites to remember one or more of previous user preferences, configurations, or settings. 
     In addition to receiving information regarding monitored activity within container  130  from container manager  118 , HVSI subsystem  110  is also configured to receive information regarding container activity from one or more HVSI libraries  208 . 
     HVSI Library 
     As discussed herein, an HVSI library is a small, lightweight, asynchronous library, which is configured to be linked either statically or dynamically within an application. For example, in the illustrated system architecture  200  of  FIG. 2 , application  202  includes HVSI library  204  and virtual application  206  includes virtual HVSI library  208 . Each HVSI library is configured to run inside its respective application and is responsible for intercepting and forwarding network resource calls from the application to HVSI subsystem  110 . 
     When a user of host operating system  102  attempts to open a network resource via application  202 , HVSI library  204  communicates information regarding the requested network resource to HVSI subsystem  110 . HVSI subsystem  110  compares this information against one or more policies obtained from policy manager  112  to determine whether the requested network resource is a trusted network resource. If HVSI subsystem  110  determines that the requested network resource is a trusted network resource, HVSI subsystem  110  allows application  202  to access the requested network resource. Alternatively, if HVSI subsystem  110  determines that the requested network resource is not a trusted network resource, HVSI subsystem  110  forwards the untrusted network resource to virtual application  206  in container  130 . 
     Virtual HVSI library  208  in container  130  is configured to intercept network resource requests from virtual application  206  and communicate information regarding the requested network resources to HVSI subsystem  110 . HVSI subsystem  110  is similarly configured to compare this information against any policies for host operating system  102  to ensure that no trusted network resources are provided to container  130 . In one or more embodiments, a virtual application will not link to virtual HVSI library  208  to ensure compatibility. In these embodiments, logging system  214  and network filter  116  operate to intercept network resource requests from the virtual application and communicate information regarding the requested network resources to HVSI subsystem  110 . 
     Having considered a system architecture for a system implementing hardware-based virtualized security isolation to protect a computing device from attacks or infections associated with untrusted network resources, consider now example procedures in accordance with one or more embodiments. Note that while this specification provides a system architecture for hardware-based virtualized security isolation, additional systems may also be configured to leverage the techniques discussed herein, such as server and cloud systems. 
     Distribution and Management of Services in Virtual Environments 
     Distribution and management of services in virtual environments is described herein. In one or more implementations, container manager  118  implements a service distribution and management model in which system services and applications are seamlessly distributed across multiple containers which each implement a different runtime environment. Compared to existing container models, this service distribution and management model provides a similar level of service to applications but significantly reduces the overhead of each runtime environment such that guest operating systems of the containers use fewer hardware resources. 
     In order to achieve a lightweight runtime environment and to reduce complexity, the service distribution and management model separates each service into two components: a service provider and a client stub. Both the service provider and the client stub can be implemented in separate containers or they can be implemented in the host runtime environment. Thus, if a particular container needs to access a service, the container hosts a client stub of the service which is configured to communicate with a service provider which may be running in a different container or in the host runtime environment. Notably, by separating services into a client stub and service provider, the service distribution and management model enables a particular service to be shared across different containers and runtime environments. For example, a single service provider can be implemented in a first container and shared by multiple different client stubs that are each implemented in separate containers. 
     As an example, consider  FIG. 3  which illustrates a host runtime environment  300 , implemented by the host operating system  102 , in which a service is separated into a service provider and a client stub. In this example, a service provider  302  of a service is executed in a service runtime environment  304  of a container  305 , and a client stub  306  of the service is executed in a client runtime environment  308  of a container  310  that is separate from the container  305 . While runtime environments will be discussed as being implemented in separate containers herein, it is to be appreciated that the client runtime environments may alternately be implemented in separate virtual machines. 
     As described herein, service provider  302  and client stub  306  are each associated with a service. Such services may include, by way of example and not limitation, active directory services, application layer gateway services, application management services, browser services, distributed link tracking services, distributed transaction coordinator services, DNS clients, event logs, extensible authentication protocols, indexing services, internet connection sharing services, network location awareness services, network store interface services, NTLM security support providers, peer name resolution protocols, plug and play services, printer spooler services, remote procedure calls, routing and remote access services, secondary logon services, security accounts managers, system event notification services, task schedulers, audio services, firewall services, scanner and camera input services, timer services, update services, or messaging services. 
     In order to configure and monitor the arrival and departure of services, the container manager  118  may utilize a “connection based” service distribution and management model or a “centralized” service distribution and management model. In a “connection based” model the communication parameters are configured on per connection basis and the initiator of the communication is responsible for the configuration. An example of this type of configuration is socket communication. In a “centralized” model the communication parameters are configured in a centralized way based on set of rules and policies. An example of this type of configuration is Windows Defender by Microsoft®. 
     As an example of a centralized service distribution and management model, consider  FIG. 4  which illustrates a host runtime environment  400 , implemented by the host operating system  102 , in which a centralized service distribution and management model is implemented. In this example, a centralized service distribution and management model is implemented to control communications between service providers  302  and client stubs  306  by utilizing a host service control manager  402 . The host service control manager  402  is implemented to enable communication between the service provider  302  implemented in the service runtime environment  304  of container  305  and the client stub  306  implemented in the client runtime environment  308  of container  310 . 
     In order to access a service, the client requests access to that service using the client stub  306 . The client request from client stub  306  is received and handled by the host service control manager  402 , which validates the client request against a set of security rules and policies  404 . The host service control manager  402  enforces the security rules and policies  404  in order to determine whether a client or runtime environment is permitted to access a particular service. The security rules and policies  404  may be stored as a part of the host service control manager  402 , separately on the host operating system  102 , or in some other location such as a file server or cloud-accessible storage. 
     If the host service control manager  402  determines that the client or runtime environment is permitted to access the service, then the host service control manager  402  grants access to the client. The host service control manager  402  then checks the availability of the service provider  302 , and if the service provider  302  is available, the host service control manager  402  returns connection information to the client which enables the client and the service provider  302  to communicate over a direct connection  406 . Alternately, if the host service control manager  402  determines that the service provider  302  is not available, then the host service control manager  402  may start a new instance of the service provider  302  in either the host runtime environment  400  or in a new runtime environment using the functionality provided by a host compute service  408 . 
     In one or more implementations, the host service control manager  402  is configured to manage the service providers  302  based on demand. If there is no demand for a particular service provider  302 , then the host service control manager  402  may terminate the particular service provider  302  to save system resources. 
     In some cases, containers can be employed to support many different client runtime environments. In order to efficiently manage multiple different client runtime environments implemented at the same time, the service distribution and management model may enable multiple instances of service providers  302  and/or multiple instance of the host service control manager  402 . In this case, each runtime environment and container may be pre-provisioned to a specific service provider  302  and host service control manager  402 . This may be pre-determined through host service control manager capacity planning and stored in the security rules and policies  404 . 
     The service distribution and management model provides services that are discoverable and highly available to the processes that depend on them.  FIG. 5  illustrates a host runtime environment  500 , implemented by the host operating system  102 , in which the host service control manager  402  and service providers  302  are offered to the client stub  306  as a highly available service endpoint  502 . To ensure that the service endpoint  502  is discoverable, the service endpoint  502  may be implemented as a standard name. However, there are many possible ways in which the service endpoint  502  may be dynamically discovered by clients, such as by query/response, lookup, pre-provisioning, and so forth. In some cases, when the client stub  306  queries the standard name of the service endpoint  502 , the service endpoint  502  identifies an available host service control manager  402  and associates it with the client stub  306 . The available host service control manager  402  then identifies the appropriate service provider  302  and follows the techniques discussed above with regards to  FIG. 4 . Note that in some implementations multiple service endpoints  502  may be provided in a given host runtime environment  500 . 
     The service endpoint  502  monitors utilization of service providers  302  and host service control manager  402  instances. When service providers  302  or host service control manager  402  instances do not meet performance thresholds, the service endpoint  502  contacts the host compute service  408  to add another service provider  302  or host service control manager  402  instance. When contacting the host compute service  408 , the host service control manager  402  may query the security rules and policies  404  to ensure that the new request conforms to the security rules and policies  404 . 
     In one or more implementations, a service provider  302  may be configured with additional attributes such as a special set of services that it hosts, or a group of client stubs  306  that it services. When this is true, the service endpoint  502  can associate these attributes with the service provider  302 , while also monitoring the service provider  302  and contacting the host compute service  408  to request additional instances of the host service control manager  402  or service providers  302 . The additional attributes of the service provider  302  may also be added to the security rules and policies  404 . It is important to note that some distributed deployments of containers may span multiple host runtime environments. This will depend on service requirements such as latency and throughput, and the ability for the infrastructure to meet these requirements. 
       FIG. 6  illustrates an example  600  in which a service distribution and management model is applied to a Component Object Model (COM) service. 
     In this example, the client runtime environment  308  implemented in container  310  includes a client stub  306  which is associated with a component object model (COM)  602  service, a client service control manager (service control manager)  604 , a remote procedure call (RPC)  606 , and a client registry  608 . The service runtime environment  304  implemented in container  305  includes a service provider  302  that is associated with the component object model  602  service, a server service control manager (service control manager)  610 , a remote procedure call (RPC)  612 , and a server registry  614 . 
     In this example, when the client runtime environment  308  is created in container  310 , the client registry  608  is configured such that the client service control manager  604  knows how to access the Host service control manager  402  to ask for access to services. For each COM  602  service, there is configuration information in HKEY_CLASSES_ROOT\CLSID\{CLSID} and HKEY_CLASSES_ROOT\AppID\{CLSID}. The Client Registry  608  is populated with information about the services that it is allowed use, but does not include information regarding services it is not permitted to access. A host Registry  616  is configured such that the host service control manager  402  knows what service providers  302  it is allowed to manage. 
     When a new service provider is registered in the host registry  616 , the host service control manager  402  updates the CLSID Registration Database while also handling the client request for an instance of a COM object. A client requests an interface pointer to a COM object from the COM Library by calling a function such as CoCreateInstance with the CLSID of the COM object. The COM Library queries host service control manager  402  to find the server that corresponds with the requested CLSID. The host service control manager  402  uses the CLSID Registration Database and locates the server and requests the creation of the COM object from the class factory that is provided by the server. If the service is not started service control manager may decide to use the host compute service  408  to start a new service runtime environment that hosts the requested service provider. If successful, the COM Library returns an interface pointer to the client. The client is then able to communicate directly with the service provider  302 . 
     In more detail, consider the following example in which the client stub of the COM service requests access to a service. First, client stub  306  requests access to a service by calling CoCreateInstance ({CLSID}). This request is handled by the Client service control manager  604  which uses the client registry  608  and the RPC  606  to connect to the host service control manager  402  (e.g., over VmBus). Next, the client service control manager  604  passes the service {CLSID} to the host service control manager  402 . Based on the security rules and policies  404 , the host service control manager  402  either accepts or denies the request to access the service. If access is granted, then the host service control manager  402  checks the host registry  616  to find out how to provide the service that corresponds to {CLSID}. If the service is already up and running, then the host service control manager  402  may decide to reuse that instance of the service provider  302 . This way the host service control manager  402  can perform load balancing functions. However, if the host service control manager  402  decides to start a new instance of the service provider  302 , then the host service control manager  402  creates a new service runtime environment in a new container, injects and starts the service provider  302  in the new service runtime environment, and returns connection information to the Client service control manager  604 . Client service control manager  402  then gives the connection information to the Client Stub  604 , and the COM  602  service is instructed how to connect directly to the service provider  302 . Notably, special care must be taken of the lifetime of the new runtime environment because the proposed design introduces inter-container dependencies. However, using the IUnknown interface (AddRef and Release) the service provider  302  knows when its reference count goes down to zero. In this case the service provider  302  can decide to shut itself down to save system resources. Thus, the described techniques enable existing COM clients and COM Service Providers to communicate seamlessly across different runtime environments. 
     Notably, running service providers  302  in separate runtime environments provides increased security through isolation. This design protects not only the host runtime environment from kernel attacks and exploits but it also ensures service availability. For example, an exploit of one service provider will not cause denial of service by another service provider. Additionally, running clients in separate runtime environments provides a great platform for friendly multi-tenant hosting. Running just small stubs and sharing the services leads to lightweight runtime environments, higher densities and opportunities for cost reductions. 
       FIG. 7  illustrates an example  700  in which a security model is applied to a Domain Name System (DNS) service. In example  700 , a client Application  702  in the client runtime environment  308  needs to resolve a URL. After authenticating with the Host Service control manager  402 , the client application  702  sends a DNS resolution request to a DNS Stub  704 . The DNS Stub  704  forwards the DNS resolution request to a DNS Provider  706 . In this case, the DNS provider is implemented at a separate service runtime environment  304 . However, as discussed throughout, the DNS provider  706  may also be implemented at the host runtime environment. The DNS provider  706  checks a local cache, and if the requested URL is not in the local cache, the DNS provider  706  forwards the DNS resolution request to an external DNS server. After the DNS resolution request has been satisfied the corresponding IP address is returned to the client application  702 . Notably, these same concepts can be applied to any type of service, such as web services, FTP services, time services, mail services, and so forth. 
     The security rules and policies  404  may be enforced in a variety of different locations, including the host runtime environment, guest runtime environments, or at the host service control manager  402 . The security rules and policies  404  may also include one or more of the following attributes: container identifier, container group, service type, process ID, and/or object ID 
     In some mixed deployments, such as in a public cloud or shared hosting there are potentially hostile parties sharing the same infrastructure. Here, the client runtime environment  308  may not want other entities, such as the host runtime environment or other client runtime environments, to be able to access, modify, or view communications between services. Thus, in one or more implementations VPN may be used to protect communications between the client stubs and service providers. In other implementations, proprietary authorization and cryptographic methods may be used to protect communications between clients and service providers. Provisioning for this may be created at the time of the guest operating system image, or provided by a provisioning service such as Lightweight Directory Access Protocol (LDAP) or Mobile Device Management (MDM). 
     In some mixed deployments, the client may require full control of the host service control manager and the service provider. In this case, the host service control manager and the service provider may be decoupled from the host runtime environment. As an example, consider  FIG. 8  which illustrates an example  800  of a host runtime environment  800  in which a service control manager and service provider are decoupled from the host runtime environment. In this example, the client stub  306 , the service endpoint  502 , the service provider  302 , a service control manager  802 , and a client management service  804  are all decoupled from the host runtime environment by being implemented in separate runtime environments and containers. In this environment, the client management service  804  acquires resources from the host runtime environment  800 , and maintains (e.g. allocates, monitors, and deallocates) these resources throughout the lifetime of the system. 
     In one or more implementations, monitoring data is acquired from one or more service endpoints  502 . Activities of client management service  804  may include measuring various aspects of service availability (e.g. responsiveness, capacity, and so forth) and in response, the client management service  804  may add more resources such as one or more service providers  302 . Activities of client management service  804  may also include deallocating resources in the event of overprovisioning. Service availability measurements may be collected over a time interval, and the client management service  802  may be provisioned with capacity planning models to automate this process. One or more implementations may locally calculate capacity planning models based on a set of measurements. 
     As many public clouds host multiple tenants, it is probable that there will be multiple instances of this scenario deployed on the same host runtime environment infrastructure. In one or more implementations, distributed deployments may span multiple host runtime environments. This will depend on service requirements such as latency and throughput, and the ability for the infrastructure to meet these requirements. In one or more implementations, supporting components may cross ownership and/or administrative boundaries. For example, instances of service stub  306  may have commercial subscriptions to a hosted infrastructure. Information about a user&#39;s subscription will be incorporated into rules and policies  404 . The rest of the system will work as described above. 
     Example Procedures 
       FIG. 9  is a flowchart illustrating an example process  900  for implementing distribution and management of services in virtual environments in accordance with one or more embodiments. Process  900  is carried out by a system, such as system  100  of  FIG. 1 , and can be implemented in software, firmware, hardware, or combinations thereof. Process  900  is shown as a set of acts and is not limited to the order shown for performing the operations of various acts. Process  900  is an example process for implementing distribution and management of services in virtual environments; additional discussions of implementing distribution and management of services in virtual environments are included herein with reference to different figures. 
     At  902 , a service control manager configured to distribute and manage services across container is provided in a host runtime environment. For example, host service control manager  402  is provided in host runtime environment  400  and is configured to distribute service across containers. 
     At  904 , a request to access a service is received at the service control manager. The request is received from a client stub of a client implemented in a client runtime environment of a first container. For example, the host service control manager  402  receives a request from a client stub  306  of a client implemented in a client runtime environment  308  of a container  310 . 
     At  906 , the request is validated against a set of rules and policies. For example, host service control manager  402  validates the request against a set of rules and policies  404 . 
     At  908 , access to the service is granted to the client if the client is permitted to access the service based on the set of security rules and policies. For example, host service control manager  402  grants access to the service to the client if the client is permitted to access the service based on the set of security rules and policies  404 . Note that in some implementations, the service provider access may be maintained over a period of time, and in some cases, the service provider access may be granted on a per-transaction basis. Some implementations may combine the two depending on a set of policy, such as the identity of the client runtime environment  308 , type of client stub  306 , type of service endpoint  502  and so forth. 
     At  910 , if a service provider of the service is available, connection information is returned to the client. The service provider of the service is implemented in a service runtime environment of a second container. For example, if service provider  302  is available, the host service control manager  402  returns connection information to the client. The service provider  302  of the client is implemented in a service runtime environment  304  of a container  305  that is separate from container  310  of the client runtime environment  308 . 
     Alternately, if the service provider of the service is not available, then at  912  a new instance of the service provider is started in a new service runtime environment and connection information is returned to the client. For example, if the service provider is not available, the host service control manager  402  starts a new instance of the service provider  302  in a new service runtime environment and connection information is returned to the client. 
     Example System 
     Although particular functionality is discussed herein with reference to particular modules, it should be noted that the functionality of individual modules discussed herein can be separated into multiple modules, and/or at least some functionality of multiple modules can be combined into a single module. Additionally, a particular module discussed herein as performing an action includes that particular module itself performing the action, or alternatively that particular module invoking or otherwise accessing another component or module that performs the action (or performs the action in conjunction with that particular module). Thus, a particular module performing an action includes that particular module itself performing the action and/or another module invoked or otherwise accessed by that particular module performing the action. 
       FIG. 10  illustrates an example system generally at  1000  that includes an example computing device  1002  that is representative of one or more systems and/or devices that may implement the various techniques described herein. The computing device  1002  may be, for example, a server of a service provider, a device associated with a client (e.g., a client device), an on-chip system, and/or any other suitable computing device or computing system. 
     The example computing device  1002  as illustrated includes a processing system  1004 , one or more computer-readable media  1006 , and one or more I/O Interfaces  1008  that are communicatively coupled, one to another. Although not shown, the computing device  1002  may further include a system bus or other data and command transfer system that couples the various components, one to another. A system bus can include any one or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and/or a processor or local bus that utilizes any of a variety of bus architectures. A variety of other examples are also contemplated, such as control and data lines. 
     The processing system  1004  is representative of functionality to perform one or more operations using hardware. Accordingly, the processing system  1004  is illustrated as including hardware elements  1010  that may be configured as processors, functional blocks, and so forth. This may include implementation in hardware as an application specific integrated circuit or other logic device formed using one or more semiconductors. The hardware elements  1010  are not limited by the materials from which they are formed or the processing mechanisms employed therein. For example, processors may be comprised of semiconductor(s) and/or transistors (e.g., electronic integrated circuits (ICs)). In such a context, processor-executable instructions may be electronically-executable instructions. 
     The computer-readable media  1006  is illustrated as including memory/storage  1012 . The memory/storage  1012  represents memory/storage capacity associated with one or more computer-readable media. The memory/storage  1012  may include volatile media (such as random access memory (RAM)) and/or nonvolatile media (such as read only memory (ROM), resistive RAM (ReRAM), Flash memory, optical disks, magnetic disks, and so forth). The memory/storage  1012  may include fixed media (e.g., RAM, ROM, a fixed hard drive, and so on) as well as removable media (e.g., Flash memory, a removable hard drive, an optical disc, and so forth). The computer-readable media  1006  may be configured in a variety of other ways as further described below. 
     The one or more input/output interface(s)  1008  are representative of functionality to allow a user to enter commands and information to computing device  1002 , and also allow information to be presented to the user and/or other components or devices using various input/output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone (e.g., for voice inputs), a scanner, touch functionality (e.g., capacitive or other sensors that are configured to detect physical touch), a camera (e.g., which may employ visible or non-visible wavelengths such as infrared frequencies to detect movement that does not involve touch as gestures), a sensor (e.g. an ambient light sensor or a motion sensor), and so forth. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, tactile-response device, and so forth. Thus, the computing device  1002  may be configured in a variety of ways as further described below to support user interaction. 
     The computing device  1002  also includes a host operating system  1014 . The host operating system  1014  provides various management of hardware-based virtualized security isolation, as discussed above. The host operating system  1014  can implement, for example, the host operating system  102  of  FIG. 1 . 
     Various techniques may be described herein in the general context of software, hardware elements, or program modules. Generally, such modules include routines, programs, objects, elements, components, data structures, and so forth that perform particular tasks or implement particular abstract data types. The terms “module,” “functionality,” and “component” as used herein generally represent software, firmware, hardware, or a combination thereof. The features of the techniques described herein are platform-independent, meaning that the techniques may be implemented on a variety of computing platforms having a variety of processors. 
     An implementation of the described modules and techniques may be stored on or transmitted across some form of computer-readable media. The computer-readable media may include a variety of media that may be accessed by the computing device  1002 . By way of example, and not limitation, computer-readable media may include “computer-readable storage media” and “computer-readable signal media.” 
     “Computer-readable storage media” refers to media and/or devices that enable persistent storage of information and/or storage that is tangible, in contrast to mere signal transmission, carrier waves, or signals per se. Thus, computer-readable storage media refers to non-signal bearing media. The computer-readable storage media includes hardware such as volatile and non-volatile, removable and non-removable media and/or storage devices implemented in a method or technology suitable for storage of information such as computer readable instructions, data structures, program modules, logic elements/circuits, or other data. Examples of computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, hard disks, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other storage device, tangible media, or article of manufacture suitable to store the desired information and which may be accessed by a computer. 
     “Computer-readable signal media” refers to a signal-bearing medium that is configured to transmit instructions to the hardware of the computing device  1002 , such as via a network. Signal media typically may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as carrier waves, data signals, or other transport mechanism. Signal media also include any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. 
     As previously described, the hardware elements  1010  and computer-readable media  1006  are representative of instructions, modules, programmable device logic and/or fixed device logic implemented in a hardware form that may be employed in some embodiments to implement at least some aspects of the techniques described herein. Hardware elements may include components of an integrated circuit or on-chip system, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), and other implementations in silicon or other hardware devices. In this context, a hardware element may operate as a processing device that performs program tasks defined by instructions, modules, and/or logic embodied by the hardware element as well as a hardware device utilized to store instructions for execution, e.g., the computer-readable storage media described previously. 
     Combinations of the foregoing may also be employed to implement various techniques and modules described herein. Accordingly, software, hardware, or program modules and other program modules may be implemented as one or more instructions and/or logic embodied on some form of computer-readable storage media and/or by one or more hardware elements  1010 . The computing device  1002  may be configured to implement particular instructions and/or functions corresponding to the software and/or hardware modules. Accordingly, implementation of modules as a module that is executable by the computing device  1002  as software may be achieved at least partially in hardware, e.g., through use of computer-readable storage media and/or hardware elements  1010  of the processing system. The instructions and/or functions may be executable/operable by one or more articles of manufacture (for example, one or more computing devices  1002  and/or processing systems  1004 ) to implement techniques, modules, and examples described herein. 
     As further illustrated in  FIG. 10 , the example system  1000  enables ubiquitous environments for a seamless user experience when running applications on a personal computer (PC), a television device, and/or a mobile device. Services and applications run substantially similar in all three environments for a common user experience when transitioning from one device to the next while utilizing an application, playing a video game, watching a video, and so on. 
     In the example system  1000 , multiple devices are interconnected through a central computing device. The central computing device may be local to the multiple devices or may be located remotely from the multiple devices. In one or more embodiments, the central computing device may be a cloud of one or more server computers that are connected to the multiple devices through a network, the Internet, or other data communication link. 
     In one or more embodiments, this interconnection architecture enables functionality to be delivered across multiple devices to provide a common and seamless experience to a user of the multiple devices. Each of the multiple devices may have different physical requirements and capabilities, and the central computing device uses a platform to enable the delivery of an experience to the device that is both tailored to the device and yet common to all devices. In one or more embodiments, a class of target devices is created and experiences are tailored to the generic class of devices. A class of devices may be defined by physical features, types of usage, or other common characteristics of the devices. 
     In various implementations, the computing device  1002  may assume a variety of different configurations, such as for computer  1016 , mobile  1018 , and television  1020  uses. Each of these configurations includes devices that may have generally different constructs and capabilities, and thus the computing device  1002  may be configured according to one or more of the different device classes. For instance, the computing device  1002  may be implemented as the computer  1016  class of a device that includes a personal computer, desktop computer, a multi-screen computer, laptop computer, netbook, and so on. 
     The computing device  1002  may also be implemented as the mobile  1018  class of device that includes mobile devices, such as a mobile phone, portable music player, portable gaming device, a tablet computer, a multi-screen computer, and so on. The computing device  1002  may also be implemented as the television  1020  class of device that includes devices having or connected to generally larger screens in casual viewing environments. These devices include televisions, set-top boxes, gaming consoles, and so on. 
     The techniques described herein may be supported by these various configurations of the computing device  1002  and are not limited to the specific examples of the techniques described herein. This functionality may also be implemented all or in part through use of a distributed system, such as over a “cloud”  1022  via a platform  1024  as described below. 
     The cloud  1022  includes and/or is representative of a platform  1024  for resources  1026 . The platform  1024  abstracts underlying functionality of hardware (e.g., servers) and software resources of the cloud  1022 . The resources  1026  may include applications and/or data that can be utilized while computer processing is executed on servers that are remote from the computing device  1002 . Resources  1026  can also include services provided over the Internet and/or through a subscriber network, such as a cellular or Wi-Fi network. 
     The platform  1024  may abstract resources and functions to connect the computing device  1002  with other computing devices. The platform  1024  may also serve to abstract scaling of resources to provide a corresponding level of scale to encountered demand for the resources  1026  that are implemented via the platform  1024 . Accordingly, in an interconnected device embodiment, implementation of functionality described herein may be distributed throughout the system  1000 . For example, the functionality may be implemented in part on the computing device  1002  as well as via the platform  1024  that abstracts the functionality of the cloud  1022 . It should be noted that the cloud  1022  can be arranged in a myriad of configurations. For example, the cloud  1022  can be implemented as a single cloud, as multiple instances of cloud  1022  all behaving as a single cloud, or with one or more instances of platform  1024  implemented behind the cloud  1022  and behaving as if the one or more instances of platform  1024  were implemented in the cloud. 
     In the discussions herein, various different embodiments are described. It is to be appreciated and understood that each embodiment described herein can be used on its own or in connection with one or more other embodiments described herein. 
     CONCLUSION AND EXAMPLE IMPLEMENTATIONS 
     Example implementations described herein include, but are not limited to, one or any combinations of one or more of the following examples: 
     In one or more examples, a system for distributing access to services in a host operating system of a computing device comprises: a host operating system configured to implement a host runtime environment; one or more services implemented by the host operating system; and a service control manager configured to enable communication between a client stub of a service implemented in a client runtime environment and a service provider of the service that is implemented in a service runtime environment that is separate from the first client runtime environment. 
     An example as described alone or in combination with any of the other examples described above or below, wherein the client runtime environment is implemented in a first container and the service runtime environment is implemented in a second container that is separate from the first container. 
     An example as described alone or in combination with any of the other examples described above or below, wherein the service control manager is implemented in a third container that is separate from the first container and the second container. 
     An example as described alone or in combination with any of the other examples described above or below, wherein the client runtime environment is implemented in a first virtual machine and the service runtime environment is implemented in a second virtual machine that is separate from the first virtual machine. 
     An example as described alone or in combination with any of the other examples described above or below, wherein the service control manager is implemented in the host runtime environment. 
     An example as described alone or in combination with any of the other examples described above or below, wherein the service control manager is configured to allow or restrict access to the client stub based on a set of security rules and policies. 
     An example as described alone or in combination with any of the other examples described above or below, further comprising a service endpoint that is configured to identify the service control manager and associate the service control manager with the client stub. 
     An example as described alone or in combination with any of the other examples described above or below, wherein the service endpoint is discoverable by the client stub. 
     An example as described alone or in combination with any of the other examples described above or below, wherein the service control manager is configured to manage the service providers based on demand from clients and to terminate a particular service provider if there is no demand for the service provider. 
     An example as described alone or in combination with any of the other examples described above or below, wherein VPN is used to protect communications between the client stub and the service provider. 
     An example as described alone or in combination with any of the other examples described above or below, further comprising a client management service configured to: provide, in the host runtime environment, monitoring of service demand; in response to monitoring an increase in service demand, allocate resources to meet the service demand; and in response to monitoring a decrease in service demand, deallocate resources to meet the service demand. 
     An example as described alone or in combination with any of the other examples described above or below, wherein the client management service locally calculates a capacity model based on the monitoring of service demand. 
     In one or more examples, a computer-implemented method comprises: providing, in a host runtime environment, a service control manager configured to distribute and manage services across containers; receiving, at the service control manager, a request to access a service, the request received from a client stub of a client implemented in a client runtime environment of a first container; validating the request against a set of security rules and policies; granting, to the client, access to the service if the client is permitted to access the service based on the set of security rules and policies; if a service provider of the service is available, returning connection information to the client, the service provider of the service implemented in a service runtime environment of a second container that is separate from the first container; and if the service provider of the service is not available, starting a new instance of the service provider in a new service runtime environment and return connection information to the client. 
     An example as described alone or in combination with any of the other examples described above or below, wherein the service control manager is configured to allow or restrict access to the client based on the set of security rules and policies. 
     An example as described alone or in combination with any of the other examples described above or below, further comprising identifying, at a service endpoint, the service control manager, and associating the service control manager with the client stub. 
     An example as described alone or in combination with any of the other examples described above or below, wherein the service endpoint is discoverable by the client stub. 
     An example as described alone or in combination with any of the other examples described above or below, further comprising managing, by the service control manager, the service providers based on demand from clients. 
     An example as described alone or in combination with any of the other examples described above or below, further comprising terminating a particular service provider if there is no demand for the service provider. 
     An example as described alone or in combination with any of the other examples described above or below, further comprising using VPN to protect communications between the client stub and the service provider. 
     An example as described alone or in combination with any of the other examples described above or below, further comprising: providing, in the host runtime environment, monitoring of service demand; in response to monitoring an increase in service demand, allocating resources to meet the service demand; and in response to monitoring a decrease in service demand, deallocating resources to meet the service demand. 
     Although the example implementations have been described in language specific to structural features and/or methodological acts, it is to be understood that the implementations defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claimed features.