Virtual environment type validation for policy enforcement

Abstract

Environment type verification can provide tamper-proof verification of the computing environment in which the environment type verification is being performed. Such information can then be used to perform policy management, which can include omitting verification to facilitate sharing of policies, such as application permissions, from the host computing environment to the container virtual computing environment. Environment type verification can perform multiple checks, including verification of the cryptographic infrastructure of the computing environment, verification of the code integrity mechanism of the computing environment, checks for the existence of the functionality of the certification management program, checks for the existence or absence of predetermined system drivers or other similar operating system components or functionalities, checks for the activation or deactivation of the resource management stack, and checks for the existence or absence of predetermined values ​​in the firmware.

Description

Background Art

[0001] Traditional virtual computing environments (commonly referred to as "virtual machines") virtualize most or all aspects of a computing environment, and can therefore present a computing environment that is very different from the host computing device hardware and operating system. However, traditional virtual computing environments may consume a large amount of memory, require a large amount of processing resources, or may be inefficient due to the need to virtualize most or all aspects of the host computing environment. In some instances, lightweight virtual computing environments, often referred to as "containers," can provide many of the isolation advantages of traditional virtual computing environments in a more efficient manner, such as by leveraging aspects of the host computing device hardware and operating system, rather than virtualizing these aspects of the computing environment. In this way, containers can be used to provide an isolated computing environment, such as limiting the impact of potentially malicious instructions, providing a pristine computing environment, such as for testing or troubleshooting purposes, and other similar benefits.

[0002] For example, a user who receives a word processing document as an attachment in an email message may be concerned that opening the word processing document may result in the execution of malicious computer executable instructions that may infect, damage, or otherwise negatively impact the user's computer. To prevent such negative impacts, the word processing document may be opened by an appropriate word processing application executed in a container. The executable instructions executed within the container may not know anything beyond the virtual computing environment presented by the container. Therefore, if the word processing document does contain malicious computer executable instructions, such instructions will only be able to infect the virtual computing environment of the container, which can be easily deleted or otherwise destroyed without compromising the user's main computing environment.

[0003] Unfortunately, because the container is perceived by the computer executable instructions executed therein as a computing environment different and distinct from the user's primary computing environment, executing the application within the container may require another license, or may not be able to take advantage of the licenses or other policies established by the user within the primary computing environment. Such additional licensing requirements may unnecessarily increase user costs, or may otherwise prevent users from taking advantage of their applications within the container environment. However, only allowing applications to execute within containers based on appropriately licensed applications within the user's primary computing environment creates a mechanism that may be easily exploited. For example, such a mechanism can be used to inappropriately share a single-user, single-instance application license between multiple users and multiple different computing environments (including different physical computing devices and different virtual machines), such as can be hosted in large quantities and provided to anyone over the Internet. Summary of the invention

[0004] Environment type verification can provide tamper-proof verification of the computing environment in which the environment type verification is being performed. Then, such information can be used to perform policy management, which can include omitting verification to facilitate sharing of policies from the host computing environment to the container virtual computing environment, such as application permissions. Environment type verification can perform multiple checks, including verification of the cryptographic infrastructure of the computing environment in which the environment type verification is being performed, verification of the code integrity mechanism of the computing environment, checks on the existence of the functionality of the certification management program, checks on the existence or non-existence of predetermined system drivers or other similar operating system components or functionalities, checks on the activation or deactivation of the resource management stack, checks on the existence or non-existence of predetermined values ​​in the firmware, and other similar checks that can be performed in the computing environment in which its environment type is being verified. In this way, policy management can enable sharing of policies between the host computing environment and the container virtual computing environment, including application permissions, while preventing such policy sharing from being used for malicious purposes, such as by deceiving a computing environment directly hosted by computing hardware or a virtual machine to present itself as a container virtual computing environment, thereby improperly obtaining access to an application or a specific functionality provided by it.

[0005] This Summary is provided to introduce a series of concepts in a simplified form, which are further described in the Detailed Description below. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0006] Additional features and advantages will become apparent from the following detailed description, which proceeds with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The following detailed description can be best understood when taken in conjunction with the accompanying drawings, in which:

[0008] Figure 1 is a system diagram of an exemplary system for policy enforcement;

[0009] Figure 2 is a system diagram of an exemplary system including a container virtual computing environment;

[0010] Figure 3 is a system diagram of an exemplary system for virtual environment type verification and policy enforcement;

[0011] Figure 4 is a flow chart of an exemplary verification of a virtual environment type;

[0012] Figure 5 is a flow chart of an exemplary policy enforcement utilizing virtual environment type authentication; and

[0013] Figure 6 is a block diagram of an exemplary computing device. DETAILED DESCRIPTION

[0014] The following description relates to tamper-proof environment type detection to enable sharing of policies (including application permissions) between a host computing environment and a container virtual computing environment, while preventing such policy sharing from being used for malicious purposes, such as by deceiving a computing environment directly hosted by computing hardware or a virtual machine to appear as a container virtual computing environment, thereby improperly obtaining access to an application or a specific functionality provided by it. Environment type verification can provide tamper-proof verification of the computing environment in which the environment type verification is being performed. Then, such information can be used to perform policy management, which can include omitting verification to facilitate sharing of policies from the host computing environment to the container virtual computing environment, such as application permissions. Environment type verification can perform multiple checks, including verification of the cryptographic infrastructure of the computing environment in which the environment type verification is being performed, verification of the code integrity mechanism of the computing environment, verification of the existence of the functionality of the attestation management program, verification of the existence or non-existence of a predetermined system driver or other similar operating system components or functionalities, checks for activation or deactivation of the resource management stack, checks for the existence or non-existence of predetermined values ​​in the firmware, and other similar checks that can be performed within the computing environment in which its environment type is being verified.

[0015] Although not required, the following description will be in the general context of computer-executable instructions, such as program modules, executed by a computing device. More specifically, unless otherwise noted, the description will refer to actions and symbolic representations of operations performed by one or more computing devices or peripherals. As such, it will be understood that these actions and operations, sometimes referred to as computer-executed, include manipulation of electrical signals representing data in a structured form by a processing unit. Such manipulation transforms the data or maintains it at a location in a memory, which reconfigures or otherwise changes the operation of the computing device or peripheral in a manner well known to those skilled in the art. A data structure that maintains data is a physical location with specific properties defined by a data format.

[0016] Typically, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In addition, those skilled in the art will appreciate that computing devices are not necessarily limited to conventional personal computers, and include other computing configurations, including servers, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframes, etc. Similarly, computing devices are not necessarily limited to stand-alone computing devices, as the mechanisms can also be practiced in distributed computing environments, where tasks are performed by remote processing devices linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

[0017] refer to Figure 1 , illustrates an exemplary system 100 to provide context for the following description. Exemplary system 100 includes an exemplary computing environment 190, which, for the purpose of providing context for the following description, may be a computing environment created by an operating system executing directly on computing hardware, sometimes referred to as a "bare metal" environment. The following description will refer to other types of computing environments, namely, virtual computing environments, such as those created by virtual machine programs, and computing environments such as those created by container processes.

[0018] Typically, when an application is instantiated, the ability of the application to execute may be affected by protections present within the computing environment 190, such as code integrity protections that dictate which applications may execute within the computing environment. Such protections may be based on whitelists, thereby preventing applications not explicitly listed from executing within the computing environment 190, or such protections may be based on blacklists, thereby allowing applications to execute within the computing environment 190 unless they are explicitly listed within a blacklist.

[0019] Subsequent execution of the application may be further affected by policy management, which may include verifying that the application is properly licensed to execute within computing environment 190. For example, an application that is not properly licensed may have its execution terminated, or a limited set of functionality may be presented to the user, such as a user may evaluate trial functionality of the application but may not be able to fully utilize it without proper licensing.

[0020] exist Figure 110, an application may be instantiated into an application instance 110. Application instance 110 is illustrated by dashed lines to indicate that its execution may occur based on multiple factors, including, for example, authorization 121 provided by example code integrity enforcement 120 and any restrictions enforced by example policy management 130. Turning first to example code integrity enforcement 120, instantiation of an application into application instance 110 may enable determination 124 by example code integrity enforcement 120 whether an associated code integrity policy file (such as example code integrity policy file 140) allows execution of the application within computing environment 190. As previously indicated, code integrity policy file 140 may be in the form of a blacklist or a whitelist.

[0021] According to one aspect, in addition to referencing a code integrity policy file, such as the exemplary code integrity policy file 140, the exemplary code integrity enforcement 120 may also perform verification that the referenced code integrity policy file 140 has not been tampered with to inappropriately indicate that an application should be allowed to execute. Such verification may allow a hash of the code integrity policy file 140 to be compared to a hash of a known good policy file, such as may be stored in the secure directory 160. For example, a hash of the code integrity policy file 140 may be generated when the computing environment 190 is first created, and such a hash may be stored in the exemplary secure directory 160. To prevent tampering with the secure directory 160, the secure directory 160 may be signed by cryptographic information of an organization's trust certificate or other similar trusted authority. The code integrity policy file 140 referenced by the code integrity enforcement 120 may be hashed, and the resulting hash may be compared to a corresponding hash stored in the secure directory 160, a matching comparison indicating that the referenced code integrity policy file 140 has not been improperly modified or tampered with, and therefore contains accurate information.

[0022] The instantiation of an application may be further affected by policy management (such as, exemplary policy management 130), which may enforce licensing, organizational policies, or other similar policy-based restrictions. For example, in order to prevent their applications from being pirated, and to provide monetization of their programming efforts, developers of applications instantiated into application instances 110 may prevent the application from executing unless it is properly licensed, such as by a user purchasing a license from the developer. In such a case, the exemplary application policy file 150 may be in the form of a license. The exemplary application policy file 150 may be referenced at the instantiation of an application to notify or restrict the execution of the application. For example, if the application policy file 150 is missing, the application may be notified and the application may terminate execution. As another example, if it is not properly licensed or if a license cannot be located, the application may have limited functionality.

[0023] In addition to permissions, other forms of policy may be enforced by the exemplary policy management 130. For example, an organization may seek to prevent execution of specific applications on computing devices of the organization. In this case, the exemplary application policy file 150 may be a whitelist or blacklist that may be curated by the organization. Other examples of application policy files may include transaction policy files, which may seek to prevent certain forms of transactions, such as in-app purchases, payments using specific computer payment plans, etc. Still other examples of application policy files may include deployment policy files and certificates.

[0024] A policy file, such as the exemplary application policy file 150, can provide a mechanism by which conditional behavior of an application can be enforced. As indicated, such conditional behavior may be desired by a developer of the application, an organization providing the computing environment 190, or other similar authoritative organization. Such a condition may be based on a user identifier, a computing device identifier, or other environmental factors. For example, the exemplary application policy file 150 may be a license purchased from an application program developer, which may indicate that it expires on a specific date. Therefore, the exemplary policy management 130 may obtain current date information in order to determine whether the exemplary application policy file 150 contains information that may affect the execution of the application, as illustrated by determination 135. For example, if current date information is passed, such as the date indicated in the exemplary application policy file 150, the exemplary policy management 130 may provide an indication to the application that it is no longer properly licensed. As another example, the exemplary application policy file 150 may be a valid purchased license that may be limited to a specific user or a specific computing device. In this case, the example policy management 130 may obtain a user identifier, computing device identifier, or other similar information to determine whether the example application policy file 150 contains information that may affect the execution of the application, as illustrated by determination 135. Also as before, for example, if the policy management 130 determines that the user identifier of the user seeking to instantiate the application into the application instance 110 is different than that defined by the application policy file 150, it may notify the application, which may then take appropriate remedial action, such as by terminating its execution, or providing only a limited set of functionality.

[0025] According to one aspect, to verify that an application policy file (such as, example application policy file 150) has not been improperly modified or otherwise tampered with, a hash of application policy file 150 may be compared to a "known good" application policy file or a hash of an application policy file taken when the file may not actually have been tampered with or otherwise modified from its expected state. For example, a policy management service such as example policy management service 170 may serve as a clearinghouse for policies and may retain hashes of "known good" policies. Example policy management service 170 may be a centralized service, such as a service executed on one or more server computing devices and accessible through network communications with such computing devices. Alternatively or in addition, example policy management service 170 may be executed locally on the same computing device executing computing environment 190, except in a separate process or other similar encapsulation. According to one aspect, a policy management service such as example policy management service 170 may include a policy repository (such as example policy repository 171) and a policy database (such as example policy database 172). The exemplary policy repository 171 may provide a mechanism by which updated policy information may be proactively distributed, such as to multiple computing devices of an organization, to multiple computing devices of previously licensed applications, such as proactive distribution of updated policy information from an application developer or application repository or other. The latest policy and a hash corresponding to the latest policy may be stored in the policy database 172. Because the policy management service 170 may not be accessible or less accessible than the application policy file 150, and may provide additional protection and otherwise prevent tampering, one mechanism for verifying that the exemplary application policy file 150 has not been tampered with or otherwise modified may be to hash the exemplary application policy file 150 and compare the resulting hash value to a corresponding hash value stored in the policy database 172, or by otherwise communicating with the exemplary policy management service 170. Once such a verification operation 137 is performed, the conditional requirements of the application policy file 150 may be considered, such as detailed above, and as illustrated by the exemplary notification 131, the application may be notified of any restrictions on the execution of the application or other similar effects that may be necessary for the evaluation of the corresponding application policy file 150.

[0026] Although described as a separate component, according to one aspect, the example policy management 130 may be part of the example application instance 110. In other words, some applications may reference their own application policy files without requiring externally provided policy management functionality.

[0027] As previously indicated, in an instance, a user may seek to execute an application within a container virtual computing environment, rather than on "bare metal" or within a full virtual machine hosted computing environment, such as is typically provided by a cloud computing provider. For example, security issues may arise that affect the execution of an application or files that the application will run, which may be ameliorated by executing the application within a restricted, protected computing environment that can be easily deleted or terminated if necessary. As another example, there may be advantages to executing an application within a clean computing environment. For example, web pages often utilize cookies or other data repositories to track users, such as by recording web pages visited, search terms utilized, and other similar personal information. Therefore, a user who does not wish to allow a web page to access previously stored information (such as cookies) can execute a web browser application within a container virtual computing environment, which can be a clean computing environment that does not contain such cookies or other similar data.

[0028] As used herein, the term "container" refers to the process of creating a separate computing environment that does not virtualize software and hardware in the manner of a virtual machine application, but instead leverages aspects of its host computing environment, including hardware and a defined subset of operating system processes and functionality.

[0029] Go to Figure 2 , wherein the illustrated system shows different associations between a container virtual computing environment and an established computing environment, such as a user may be presented by their personal computing device. For example, the exemplary system 201 includes a user 210 utilizing a personal computing device 220. The exemplary personal computing device 220 may present an established computing environment 231 to the user 210, such as may be generated by an operating system and corresponding computer executable instructions executed on the personal computing device 220. Such an established personal computing environment 231 may include a container manager 241, which may include computer executable instructions that may establish a container virtual computing environment and share appropriate aspects of an operating system or other similar resources of the established computing environment 231. If the user 210 requires such a container virtual computing environment, for example, to open an email attachment that may be malicious, the container manager 241 may create a container instance, such as the exemplary container instance 251, which may also be executed by the same personal computing device 220.

[0030] As another example, the exemplary system 202 illustrates a user 210 utilizing a personal computing device, such as the exemplary personal computing device 220, to connect to a server computing device 260, such as a server provided by a cloud service. The exemplary server computing device 260 may execute an established computing environment 232, which may be a virtual computing environment hosted by a virtual machine. The established computing environment 232 may include applications that the user seeks to utilize on the personal computing device 220. One mechanism by which the user 210 may utilize such applications on their personal computing device 220 may be within a container instance that may isolate other aspects of the personal computing device 220 from such applications. In the exemplary system 202, a container manager, such as the exemplary container manager 242, executing on the personal computing device 220 may launch a container instance, such as the exemplary container instance 252. The established computing environment 232 on the cloud service 260 may establish appropriate communications to act as a host computing environment for the container instance 252, even though the container instance 252 may be managed by the container manager 242 executing remotely from the cloud service 260.

[0031] In a similar manner, as illustrated by the exemplary system 203, a user 210 utilizing a public computing device 270 (e.g., a public kiosk) may seek to remotely access the user's personal computing device 220 in a secure manner. In such a case, an established computing environment 233 executing on the user's personal computing device 220 may communicate with a container manager (such as the exemplary container manager 243) executing on the public computing device 270. The exemplary container manager 243 may then create a container instance 253 on the public computing device 270, wherein the established computing environment 233 executing on the remote personal computing device 220 acts as a host environment for the container instance 253.

[0032] As previously indicated, because the container virtual computing environment can be perceived as a separate computing device by the computer executable instructions executed within the container virtual computing environment, permissions and other similar policy aspects may not be translated to the container virtual computing environment. Thus, for example, a user who receives a word processing attachment via email (which the user is concerned may be malicious) may open the attachment with a word processing application executed within the container virtual computing environment. However, although the user may have a valid license to utilize the word processing application, such a license may be limited to the host computing environment, and therefore when the user attempts to open the attachment with the word processing application executed within the container virtual computing environment, the user may receive an indication that their word processing application is unlicensed because, from the perspective of the computer executable instructions executed within the container virtual computing environment, it appears as if the application is being executed on different computing devices by different users. Thus, if the user has obtained multiple licenses for the application, opening the attachment with the word processing application executed within the container virtual computing environment may result in the use of another license in a set of pre-purchased licenses without the user's consent. Unfortunately, however, simply disabling license checking for applications executing within a container virtual computing environment may enable a malicious user to easily pirate or otherwise improperly obtain applications by simply causing the malicious user's personal computing device to appear as the authorized user's container virtual computing environment, thereby enabling the authorized user's single license to be inappropriately shared among many different users and exploited across many different computing devices.

[0033] To prevent such piracy and other improper acquisition of applications, while promoting legitimate use of applications within container virtual computing environments, environment type verification can be performed to verify that the computing environment is indeed a proper container and is not simply presented as such to bypass licensing or other policy restrictions. Such environment type verification can then inform the appropriate policy management mechanism to enable the application to respond appropriately.

[0034] Steering Figure 3 , wherein the illustrated exemplary system 300 illustrates the exemplary policy management service 170 and the exemplary computing environment 190 previously described in detail. In addition, Figure 3 The exemplary system 300 of FIG. 1 also illustrates a virtual computing environment created by a container process in the form of an exemplary container instance 390. The exemplary container instance 390 can be created by a container management functionality, such as described above with respect to Figure 2The exemplary computing environment 190 can serve as a host for the example container instance 390. As will be described in detail below, the mechanisms illustrated and described herein can enable a container application instance 310 of the same application as the application instance 110 executing within the computing environment 190 to execute within the virtual computing environment of the container instance 390 while utilizing the application policy file 150 from the host computing environment 190.

[0035] According to one aspect, secure communications may be established between the host computing environment 190 and the container instance 390, such as through the exemplary secure communications mechanisms 361 and 362. The exemplary secure communications mechanisms 361 and 362 may be constructed based on asymmetric key cryptography. For example, when the container instance 390 is launched, such as in the manner detailed above, the container instance 390 may be provided with a public key portion of an asymmetric key algorithm established by the host computing environment (such as, the exemplary computing environment 190). As another example, the container instance 390 may be provided with seed data from which, using a known cryptographic mechanism, the secure communications mechanism 362 executed within the container instance 390 may derive the same key as the exemplary secure communications mechanism 361 executed within the host computing environment 190. As yet another example, a user may be required to manually enter the required cryptographic information into the secure communications mechanism 361 and the secure communications mechanism 362, or other similar out-of-band communications may be utilized to securely exchange cryptographic information that may be used to establish a secure communications connection.

[0036] Once secure communication between the exemplary host computing environment 190 and the exemplary container instance 390 is established, the Figure 1 The application policy file 150 described in detail can then be shared with the container instance 390 from the exemplary host computing environment 190. For example, a secure file share such as the exemplary file share 363 can be established, whereby processes executing within the container instance 390 can access the application policy 150 in the exemplary host computing environment 190. The application policy file 150 is illustrated in both the exemplary host computing environment 190 and the exemplary container instance 390 to intuitively represent access to the application policy file 150 from within the container instance 390.

[0037] According to one aspect, when attempting to instantiate a container instance of application 310, a code integrity implementation such as exemplary code integrity enforcement implementation 320, similar to exemplary code integrity enforcement implementation 120 described in detail above (such as exemplary code integrity enforcement implementation 320) can verify that the application is allowed to execute within container instance 390. For example, container instance 390 can be created with a container instance that can be different from Figure 1The code integrity policy file 340 of the code integrity policy file 140 shown is created, and the code integrity policy file 340 can be part of the computing environment 190. As another example, the computing environment 190 may not execute Figure 1 Code integrity enforcement 120 is shown, and code integrity enforcement may be limited to a container instance, such as example code integrity enforcement 320 executing within example container instance 390 .

[0038] As before, a code integrity enforcement, such as the exemplary code integrity enforcement 320, can authorize 321 instantiation of the container application instance 310 based on checking 324 a relevant code integrity policy file, such as the exemplary code integrity policy file 340, provide for execution of the container application instance 310 within the exemplary container instance 390, and further verify 326 that the code integrity policy file 340 has not been modified or tampered with, such as by referencing the exemplary security catalog 360. As before, such verification can be based on a hash comparison.

[0039] Additionally, as described above, policy management, such as the exemplary policy management 330, can further affect the instantiation of the container application instance 310. However, in one aspect, when executing within a container instance (such as the exemplary container instance 390), the exemplary policy management 330 can be informed by an environment type verification (such as the exemplary environment type verification 350), which can provide information about the type of execution environment in which the policy management 330 and / or the container application instance 310 is executing. For example, the environment type verification can provide an indication of whether the container instance 390 is actually a proper container, thereby enabling the detection of other types of execution environments that may maliciously present themselves as container execution environments in an attempt to exploit license restrictions and gain inappropriate access to application functionality. The information provided by the environment type verification 350 information can then be utilized by the policy management 330 with reference to the shared application policy file 150. Alternatively or additionally, the environment type verification 350 can first inform the creation of the file share 363. For example, based on the mechanisms described in further detail below, if the environment type verification 350 determines that the container instance 390 is not a proper container, for example, if the container instance 390 is a virtual computing environment hosted by a virtual machine, or a computing environment of another computing device, and is maliciously modified to appear as a container instance for the sole purpose of improperly accessing an application, then the environment type verification 350 can prevent the creation of the file share 363, such as by retaining relevant information, such as necessary password information, or such as by explicitly indicating not to create the file share 363. According to such an aspect, the application policy file 150 is therefore inaccessible from within the container instance 390, and the container application instance 310 will not be able to obtain the proper license, thereby presenting a pirated version through deception of the virtual environment type.

[0040] Returning to the aspect indicated above, where environment type verification 350 provides information 353 that provides information about container instance 390, such information 353 may then be used by policy management 330 to perform a check 335 of application policy files 150 shared from computing environment 190. For example, application policy files 150 may include information indicating that an application cannot be properly licensed to execute within a container instance, such as exemplary container instance 390. In this case, policy management 330 may generate notification 331 that container application instance 310 is not associated with a valid application policy file 150, thereby allowing container application instance 310 to terminate its execution, or otherwise present a reduced set of functionality. As another example, application policy 150 may include information indicating that an application is licensed to execute within a container instance, such as exemplary container instance 390. In this case, application policy 150 may include additional information to facilitate licensing of the application executing within the container instance. For example, because the container instance 390 may include a different computer identifier, or may not have access to a user identifier, checks based on user identifiers, machine identifiers, etc. (including those detailed above) may not be performed from within the container instance 390. Therefore, if the container application instance 310 is executed within the appropriate container instance, the application policy 150 may omit such verification. As such, the information provided by the environment type verification 350 may prevent such verification omissions from being used for malicious purposes, such as improperly gaining access to an application.

[0041] According to one aspect, the policy management 330 can refer to the policy management service 170 to perform verification 337 in a manner similar to that detailed above. For example, the policy management 330 can hash the application policy file 150 and can compare such hashes, or can ask the policy management service 170 to compare such hashes with known good application policy files. According to one aspect, if the hash matches the known good application policy file hash, the policy management service 170 can further check whether the application policy corresponding to such hash has been assigned, such as assigned to the application instance 110 that can be executed within the computing environment 190. If the application policy has not been assigned, or if it has been assigned but the query from the policy management 330 originated from the appropriate container instance, such as determined by the environment type verification 350, the policy management service 170 can respond to the query as having been verified. In this way, it can be verified that the application policy 150 has not been tampered with or otherwise modified and that the request originated from the appropriate container instance. The exemplary policy management 330 can then allow the container application instance 310 to continue to execute and provide full license functionality.

[0042] As previously indicated, policy management, such as the example policy management 330, can be part of an application, such as the example container application instance 310. Likewise, as also previously indicated, a policy management service, such as the example policy management service 170, can be executed on one or more remote computing devices, on the same computing device, in addition to being external to the container instance 390, or within the container instance 390. Environment type validation (the operation of which will be further detailed below) can also be part of the application, or can be separate and called by the policy management 330, such as with Figure 3 The method illustrated in the exemplary system 300 of , or can be called directly by the application.

[0043] Turning to operation 351 of the exemplary environment type validation 350, according to one aspect, the exemplary environment type validation 350 may provide information 353 in the form of a Boolean value that simply indicates whether the container instance 390 is a "proper" container, where the "property" of the container instance 390 may be predetermined and evaluated based on a series of predefined checks, such as will be further described below. However, according to another aspect, the exemplary environment type validation 350 may output information 353, which may identify a particular type of execution environment, such as distinguishing between a computing environment hosted by a virtual machine application and a computing environment hosted by a container instance. According to another aspect, the information 353 provided by the exemplary environment type validation 350 may include information about the environment type or other environment type metadata, which may be related to one or more conditions enumerated in the application policy file 150, or may otherwise inform the conditional behavior of the policy management 330. For example, the information 353 may include detailed information about one or more checks that the environment type validation 350 may provide.

[0044] For purposes of describing operations of environment type validation, such as exemplary environment type validation 350, output 353 will be referenced in the form of a Boolean value. However, as detailed above, the described operations 351 may similarly produce outputs 353 of varying scope and complexity. Figure 3 As illustrated, turning to example operation 351, multiple checks may be performed to verify that the container instance 390 is a proper container instance and not a different virtual computing environment that has been spoofed or otherwise modified to present itself as a container instance in order to, for example, exploit a less restrictive application policy or otherwise inappropriately gain access to an application.

[0045] According to one aspect, environment type verification can verify the cryptographic infrastructure of the virtual computing environment in which the environment type verification is performed, including the cryptographic infrastructure utilized by, for example, secure communication mechanisms 361 and 362. For example, environment type verification 350 can check whether a certificate repository is available within container instance 390. Within such a certificate repository, environment type verification 350 can check whether the certificate has or is signed by an expected trust root, which can be an organization's trust root, or another known good trust root. As another example, environment type verification 350 can utilize existing authentication technology within container instance 390. The operating system executed within the virtual computing environment provided by container instance 390 can be "measured", such as by hashing, modules, or other similar sets of computer executable instructions, because they are loaded by the operating system as part of the boot sequence. Such measurements can be performed with the help of a trusted platform module (TPM), which can securely store such measurements. After the operating system boot is complete, if all modules and similar sets of computer executable instructions loaded as part of the operating system boot are not modified and are otherwise appropriate, the resulting measurement should match the known good measurement. In such a case, environment type verification 350 can confirm that such authentication was performed and was performed appropriately, such as by comparing measurements of the boot operating system to known good measurements. Environment type verification 350 can utilize an external authentication service to compare measurements of the boot operating system of container instance 390 to known good measurements. If the measurements do not match, environment type verification 350 can conclude that container instance 390 is not an appropriate container instance. Although described above with reference to operating system components, such authentication can be extended to the launch of specific applications, including applications that are instantiated to create container application instances 310.

[0046] According to another aspect, environment type verification can verify the code integrity infrastructure of container instance 390. For example, environment type verification 350 can interface with code integrity enforcement 320 to verify the hash of code integrity policy file 340, verify the signature of security directory 360, which, as previously indicated, can be signed by the organization's trust certificate or other similar trust root, or can perform other verifications of code integrity enforcement 320. Failure of any one or more of such verifications may cause environment type verification 350 to conclude that the virtual environment it is executing within is not an appropriate container instance. Verification of the code integrity infrastructure can be combined with stricter code integrity enforcement within the container instance to further reduce piracy or other malicious behavior. For example, a limited whitelist type code integrity policy file (such as, exemplary code integrity policy file 340) can be used to create a container instance. Container instance 390 can, for example, include code integrity policy file 340, can only allow container application instances 310 or other appropriately restricted whitelists. Any attempt to utilize such a container instance 390 to execute a different application may fail, either due to code integrity enforcement 320, or if the code integrity infrastructure is inappropriately modified to allow execution of a different application, such modification may be detected by environment type verification 350, which may then generate information 353 that will again prevent the container instance 390 from being utilized to execute such a different application.

[0047] According to another aspect, the environment type verification 350 can perform checks on various functionalities or their absence, specific code segments or their absence, and other similar indicators of the environment type. For example, the environment type verification 350 can check whether the hypervisor exists or is accessible. Such a check can be performed through an application program interface that can query the capabilities of one or more central processing units. More specifically, a central processing unit with hypervisor capabilities can expose such functionality or capabilities through such an application program interface, and the presence of such functionality or capabilities can indicate the presence of a hypervisor. According to one aspect, if the environment type verification 350 detects the presence of a hypervisor, it can conclude that the environment in which it is executing is not a suitable container, or conclude that the environment is not a container-hosted execution environment, and on the contrary, it may be a virtual machine-hosted execution environment. Similarly, the environment type verification 350 can check whether a specific system driver exists in the environment. The presence or absence of such a system driver can cause the environment type verification 350 to conclude that the environment in which it is executing is not a suitable container. For example, a similar check can be performed on whether a specific functionality is closed. In particular, environment type verification 350 may check whether resource management stacks are shut down, and if these resource management stacks are not shut down, environment type verification 350 may conclude that container instance 390 is not appropriate. Another check may be made on firmware, as accessible from the execution environment. For example, it may be necessary to add specific firmware variables to the environment, such as by a container manager, or a host computing environment, such as exemplary host computing environment 190. The absence of such firmware variables may cause environment type verification 350 to conclude that container instance 390 is not an appropriate container.

[0048] The operations 351 described above are exemplary only, and the checks performed and their order may be customized to detect specific attack vectors or other similar avenues that may enable malicious or inappropriate exploitation. Other checks may also be performed, and again as previously indicated, the output 353 provided by the environment type verification 350 may provide more details, such as identifying a specific execution environment type, or authenticating information about one or more checks. For example, the exemplary environment type verification 350 may check whether the container instance 390 is kernel isolated. As another example, the environment type verification 350 may check for specific exposed operating system functionality.

[0049] According to one aspect, the information 353 provided by the environment type verification 350 can enable the policy management 330 and / or the container application instance 310 to select from a plurality of different versions of the application, including different versions that can be generated, sold, and / or processed as separate products (such as by having different SKU numbers or other similar product identifiers). For example, if a particular check in the checks 351 passes, the environment type verification 350 can provide an output 353 indicating that such a check is passed to the policy management 330, which can be part of the container application instance 310 as previously indicated. For example, based on the information 353 provided by the environment type verification 350, the policy management 330 can determine that one version of the application instantiated into the container application instance 310 can be allowed to execute within the container instance 390, but another version of the same application cannot be allowed to execute. For example, the detection of the absence of a particular system driver in the container instance 390 by the environment type verification 350 can cause the policy management 330 to allow execution of a more limited version of a music editing program, such as to not allow input of external audio sources, such as a microphone, for example. In such an example, detection of environment type validation 350 may not cause container application instance 310 to terminate execution, but may instead cause it to execute a different version of the application product. Thus, including such an example, if application instance 110 is an extended version of a music editing program, and a user executes the same music editing program in container instance 390, detection of environment type validation 350 combined with policy management 330 acting on information 353 provided by environment type validation 350 may cause the application to seamlessly transition and execute a more limited version of the same music editing program as container application instance 310.

[0050] Steering Figure 4 , wherein an exemplary flowchart 400 is illustrated illustrating an exemplary series of steps that may be performed by an environment type validation, such as the exemplary environment type validation detailed above. According to one aspect, one or more of such steps may be performed as preliminary steps, with subsequent steps being performed to further validate conclusions drawn by the preliminary steps. Alternatively or additionally, a conclusion 480 that the execution environment is not a suitable container may be drawn if any one or more of the steps make a particular determination, while a conclusion 470 that the execution environment is a suitable container may be drawn only if no step determines otherwise. Additionally, the order in which the steps are performed may vary, and Figure 4The illustrated sequence is exemplary only. Finally, as previously indicated, the conclusions 470 and 480 as Boolean values ​​output by the environment type verification are only one aspect, and in other aspects, the conclusions drawn can indicate a specific type of execution environment, such as selected from a predefined range of possibilities, as well as provide information or other similar metadata, including outputting information about the results of any one or more checks performed, such as those illustrated in steps 420-460.

[0051] The exemplary flowchart 400 begins at step 410, at which time an environment type verification may be requested or initiated. In response, an initial determination, such as verification of a cryptographic infrastructure, may be performed at step 420. As previously indicated, such verification of the cryptographic infrastructure may be verification of a proper authentication of the boot operating system of the execution environment, or a proper authentication of the boot operating system in combination with one or more executed applications, or other similar authentications. Also as previously indicated, verification of the cryptographic infrastructure, such as at step 420, may be verification that the certificates in the certificate repository of the execution environment have the expected trust root, or are otherwise properly signed. If the execution environment includes a TPM, step 420 may also include a comparison of measurements from the host computing environment TPM (such as, obtained during authentication of the host computing environment) with measurements from the execution environment, within which instructions correspond to the execution of step 420, such as verifying a container environment. If, at step 420, the cryptographic infrastructure, such as in the manner detailed above, is not verified, a conclusion 480 may be drawn that the execution environment is not a suitable container. Alternatively, if the cryptographic infrastructure is verified at step 420 , processing may continue to perform one or more other checks, such as those illustrated by steps 430 - 460 .

[0052] Although illustrated as a subsequent step 430 in the exemplary flowchart 400, according to one aspect, step 430 may be initially performed instead of step 420. As detailed above, at step 430, the code integrity mechanism may be verified. For example, the code integrity policy file may be verified, such as by confirming that a hash of the code integrity policy file matches a hash of a known good code integrity policy file. As another example, the known good code integrity policy file and its corresponding hash may be stored in a secure directory or other similar data structure that may itself be protected. As such, another aspect of step 430 may be to verify that such a secure directory has been signed by an organization's trust certificate, or may be verified in other ways. If, at step 430, the code integrity mechanism is not verified, such as in the manner detailed above, then a conclusion 480 may be reached that the execution environment is not a suitable container. Alternatively, if the code integrity mechanism is verified at step 430, processing may continue to perform one or more other checks, such as the checks of steps 440 to 460.

[0053] As previously indicated, steps 440 to 460 may be alternatives or secondary verifications that may be performed to further verify the type of environment. For example, in step 440, the presence or absence, availability or unavailability of specific resources, such as the presence of a hypervisor, may be checked. As detailed above, the presence of a hypervisor may be indirectly determined by determining that the available CPUs within the execution environment expose functionality provided by the hypervisor, which may be determined by appropriate API calls. Other resources whose presence may be determined may include a resource management stack that may be shut down in a container, and therefore, detection of a resource management stack being shut down may indicate that the execution environment is an appropriate container. Conversely, detection of a hypervisor or detection that a resource management stack is opened may lead to the conclusion 480 that the environment is not an appropriate container.

[0054] As another example, at step 450, it may be checked whether particular system drivers are present within the execution environment. If the relevant system drivers are not present within the execution environment, or if they are configured in a manner different from the predetermined correct configuration, it may be concluded 480 that the environment is not a suitable container. As yet another example, at step 460, a check may be made on firmware accessible from the execution environment. For example, it may be necessary to add particular firmware variables to the environment, such as by a container manager or a host computing environment. The absence of such firmware variables may lead to the conclusion 480 that the environment is not a suitable container.

[0055] After the various checks are completed, if it is not otherwise concluded 480 that the environment is not a suitable container, then an opposite conclusion can be drawn 470 that the environment is a suitable container and communicated to a process that invokes environment type verification.

[0056] As previously indicated, such environment type verification can be part of a larger verification mechanism to provide permission sharing between the host execution environment and the container execution environment. Figure 5 , wherein an exemplary flowchart 500 is illustrated illustrating an exemplary series of steps that may be performed to facilitate such sharing and allow an application to be executed within a container instance. Initially, at step 510, a container instance may be created, such as by a container manager, and one or more cryptographic data, such as an asymmetric security key, may be provided, which data may then be utilized to establish a secure communication channel between the container instance and an established computing environment that may serve as a host computing environment, such as at step 515, and creation of the container instance may be triggered at step 510. At step 520, the secure communication channel established at step 515 may be used to share an application policy file from the host computing environment to the container instance. As previously indicated, according to one aspect, establishment of the secure communication channel 515 may be dependent upon confirmation of the execution environment as an appropriate container, such as with Figure 4The performance is shown in the figure. Figure 5 This is generally shown as step 545 in the exemplary flowchart 500 of .

[0057] At step 525, the relevant application may attempt to instantiate inside the container instance created at step 510. As part of such instantiation, processing may proceed to step 530, where a code integrity policy file may be checked to confirm that the application is allowed to execute. As previously indicated, code integrity protection may be enforced by a policy file, which may be in the form of a whitelist, a blacklist, or a combination thereof. At step 535, the code integrity policy may be verified, such as by hashing the code integrity policy and verifying the hash against a security directory that may include hashes of known good code integrity policies. At step 535, verification may further entail verifying the security directory itself, such as by verifying that it is properly signed. At step 540, the code integrity may authorize the instantiation of the application inside the container instance.

[0058] As part of the reference to the application policy shared at step 520, the execution environment may be verified as an appropriate container, such as described above with reference to Figure 4 The method described in detail. Figure 5Within the illustrated exemplary flowchart 500, such verification is shown as occurring at step 545, however, as previously indicated, it may occur at other points within the exemplary flowchart 500 and may be provided as input to multiple steps of the exemplary flowchart 500. One such step may be referencing a shared application policy at step 550. As previously indicated, if the execution environment is verified as a proper container at step 545, the shared application policy may be referenced at step 550 to determine whether licensing or other policy implications allow the execution of the application within the virtual computing environment created by the properly verified container. At step 550, the reference may determine that, in order to facilitate the execution of the application within the container, the associated policy file may deactivate certain checks, such as restrictions based on user identification, machine identification, and other similar checks that cannot be performed due to verification of the execution environment as a proper container. Subsequently, at step 555, a hash of the application policy may be generated, and at step 560, the hash may be verified by comparing it to a known good policy hash, such as by referencing a remote policy management service. As previously indicated, the policy management service may be executed within the container instance, may be executed on the same computing device as the container instance but external to the container instance, or may be executed on one or more remote computing devices. If the shared application policy is verified at step 560, processing may proceed to step 565 and the application may be appropriately notified, such as by being instructed to execute with appropriate restrictions based on the conditions in the shared application policy, as notified by the verification of step 545. More specifically, while some checks may be deactivated due to verification of the execution environment as a proper container, such as at step 545, other checks such as time-based checks may still be part of the application policy, and if the application attempts to execute after the license has expired, for example, then the execution of the application inside the container instance may still be restricted at step 565. In other cases, step 565 may not restrict the execution of the application, but instead may allow the application to execute within the container instance and provide full functionality. With appropriate feedback from policy management, the execution of the application inside the container instance may then continue at step 570.

[0059] Steering Figure 6, illustrates an exemplary computing device 600 that can perform some or all of the mechanisms and actions described above. The exemplary computing device 600 may include, but is not limited to, one or more central processing units (CPUs) 620, a system memory 630, and a system bus 621 that couples various system components including the system memory to the processing unit 620. The system bus 621 can be any of a variety of types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The computing device 600 may optionally include graphics hardware, including, but not limited to, a graphics hardware interface 660 and a display device 661, which may include a display device capable of receiving touch-based user input, such as a touch-sensitive or multi-touch-enabled display device. Depending on the specific physical implementation, one or more of the CPU 620, the system memory 630, and the other components of the computing device 600 may be physically collocated, such as on a single chip. In this case, some or all of the system bus 621 may be nothing more than silicon paths within a single chip structure, and its Figure 6 The illustrations in the figure may be for illustration purposes only and are convenient symbols.

[0060] The computing device 600 also typically includes computer-readable media, which may include any available media that can be accessed by the computing device 600 and include volatile and non-volatile media and removable and non-removable media. As an example and not a limitation, computer-readable media may include computer storage media and communication media. Computer storage media include media implemented by any method or technology for storing content such as computer-readable instructions, data structures, program modules or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, tape, tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired content and can be accessed by the computing device 600. However, computer storage media do not include communication media. Communication media typically embody computer-readable instructions, data structures, program modules or other data in modulated data signals such as carrier waves or other transmission mechanisms, and include any content delivery media. As an example and not a limitation, communication media include wired media such as wired networks or direct wired connections, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer-readable media.

[0061] The system memory 630 includes computer storage media in the form of volatile and / or nonvolatile memory, such as read-only memory (ROM) 631 and random access memory (RAM) 632. A basic input / output system 633 (BIOS), containing basic routines that help transfer content between elements within the computing device 600, such as during startup, is typically stored in ROM 631. RAM 632 typically contains data and / or program modules that are immediately accessible and / or currently being operated on by the processing unit 620. By way of example and not limitation, Figure 6 Operating system 634 , other program modules 635 , and program data 636 are shown.

[0062] The computing device 600 may also include other removable / non-removable volatile / non-volatile computer storage media. For example only, Figure 6 A hard disk drive 641 is illustrated that reads from or writes to a non-removable non-volatile magnetic medium. Other removable / non-removable volatile / non-volatile computer storage media that can be used with the exemplary computing device include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital videotapes, solid-state RAM, solid-state ROM, and other computer storage media defined and described above. The hard disk drive 641 is typically connected to the system bus 621 via a non-volatile memory interface such as interface 640.

[0063] The above discussion and Figure 6 The drives and their associated computer storage media shown in the figure provide storage of computer readable instructions, data structures, program modules and other data for the computing device 600. Figure 6 6, for example, hard drive 641 is illustrated as storing operating system 644, other program modules 645, and program data 646. Note that these components may be the same as or different from operating system 634, other program modules 635, and program data 636. Operating system 644, other program modules 645, and program data 646 are given different numbers here to illustrate that at least they are different copies.

[0064] The computing device 600 can operate in a network environment using logical connections to one or more remote computers. The computing device 600 is illustrated as being connected to a general network connection 651 (to a network 670) via a network interface or adapter 650, which in turn is connected to a system bus 621. In a network environment, program modules depicted relative to the computing device 600, or portions or peripherals thereof, may be stored in the memory of one or more other computing devices that are communicatively coupled to the computing device 800 via a general network connection 661. It should be understood that the network connections shown are exemplary and other ways of establishing a communications link between computing devices may be used.

[0065] Although described as a single physical device, the exemplary computing device 600 may be a virtual computing device, in which case the functionality of the above-mentioned physical components (such as, CPU 620, system memory 630, network interface 640 and other similar components) may be provided by computer executable instructions. Such computer executable instructions may be executed on a single physical computing device, or may be distributed across multiple physical computing devices, including being distributed across multiple physical computing devices in a dynamic manner, so that the specific physical computing device hosting such computer executable instructions may dynamically change over time according to needs and availability. In the case where the exemplary computing device 600 is a virtualized device, the underlying physical computing device hosting such a virtualized computing device may itself include physical components similar to those described above and operate in a similar manner. In addition, virtual computing devices may be utilized in multiple layers, where one virtual computing device is executed within the fabric of another virtual computing device. Therefore, as utilized herein, the term "computing device" refers to a physical computing device or a virtualized computing environment, including a virtual computing device, in which computer executable instructions may be executed in a manner consistent with the manner in which a physical computing device executes instructions. Similarly, as utilized herein, terms referring to physical components of a computing device refer to those physical components or virtualizations thereof that perform the same or equivalent functions.

[0066] As a first example, the above description includes a method for enforcing policy restrictions on the execution of an application within a first computing environment, the method comprising: obtaining application policy data corresponding to the application from a second computing environment different from the first computing environment, the application policy data specifying a first prerequisite to be bypassed when the first computing environment is a container virtual computing environment; performing environment type verification, including at least one of the following: checking the encryption infrastructure of the first computing environment; checking the code integrity infrastructure of the first computing environment; or checking the hypervisor functionality within the first computing environment; and when the performed environment type verification determines that the first computing environment is not a container virtual computing environment, restricting the execution of the application based on the first prerequisite.

[0067] A second example is the method of the first example, wherein checking the cryptographic infrastructure includes verifying proper authentication of an operating system of the first computing environment.

[0068] A third example is the method of the second example, wherein checking the cryptographic infrastructure includes verifying proper authentication of a combination of an operating system and an application of the first computing environment.

[0069] A fourth example is the method of the second example, wherein verifying proper authentication of the operating system of the first computing environment includes communicating with a remote authentication service external to the first computing environment.

[0070] A fifth example is the method of the second example, wherein verifying proper authentication of the operating system of the first computing environment includes comparing an authentication measurement from a first trusted platform module (TPM) in the first computing environment with an authentication measurement from a second TPM in the second computing environment.

[0071] A sixth example is the method of the first example, wherein checking the cryptographic infrastructure includes verifying that a certificate in a first certificate store of the first computing environment is signed by a predetermined root of trust.

[0072] A seventh example is the method of the first example, wherein checking the code integrity infrastructure includes verifying the hash of the active code integrity policy file against a secure directory including hashes of known good code integrity policy files.

[0073] An eighth example is the method of the seventh example, wherein checking the code integrity infrastructure includes verifying that the security catalog is signed by one of the certificates of a predetermined trusted organization.

[0074] A ninth example is the method of the first example, wherein checking hypervisor functionality includes checking whether processor functionality commensurate with the hypervisor is exposed by a central processing unit of the first computing environment.

[0075] A tenth example is the method of the first example, wherein performing environment type verification includes checking whether a predetermined system driver component exists within the first computing environment.

[0076] An eleventh example is the method of the first example, wherein performing the environment type verification includes checking whether the resource management stack is deactivated within the first computing environment.

[0077] A twelfth example is the method of the first example, wherein performing environment type verification includes checking whether a predetermined firmware variable is set to a predetermined value within the firmware of the first computing environment.

[0078] A thirteenth example is the method of the first example, wherein the first precondition restricts execution of the application to a specific computing device hardware machine identifier.

[0079] A fourteenth example is the method of the first example, wherein the first precondition restricts execution of the application to a particular user identifier.

[0080] A fifteenth example is the method of the first example, further comprising validating the obtained application policy data by referencing a policy management service external to the first computing environment.

[0081] The sixteenth example is a computing device, which includes: one or more processing units; and one or more computer-readable storage media, the one or more computer-readable storage media including computer-executable instructions, which, when executed by at least some of the processing units, cause the computing device to: obtain application policy data corresponding to an application from a second computing environment different from the first computing environment, the application policy data specifying a first prerequisite to be bypassed when the first computing environment is a container virtual computing environment; perform environment type verification, including at least one of the following: checking the encryption infrastructure of the first computing environment; checking the code integrity infrastructure of the first computing environment; or checking the hypervisor functionality within the first computing environment; and when the performed environment type verification determines that the first computing environment is not a container virtual computing environment, restricting the execution of the application based on the first prerequisite.

[0082] The seventeenth example is the computing device of the sixteenth example, wherein both the first computing environment and the second computing environment are hosted by the computing device.

[0083] An eighteenth example is the computing device of the sixteenth example, wherein the first computing environment is hosted by the computing device, and the second computing environment is hosted by a second computing device different from the first computing device, the second computing device being communicatively coupled to the computing device.

[0084] The nineteenth example is one or more computer-readable storage media, including computer-executable instructions, which, when executed within a first computing environment, perform steps including: receiving a request to verify the type of a first computing environment; performing at least one of the following: checking an encryption infrastructure of the first computing environment; checking a code integrity infrastructure of the first computing environment; or checking hypervisor functionality within the first computing environment; and generating an environment type verification Boolean output value, if at least one of the check of the encryption infrastructure or the check of the code integrity infrastructure fails, or if the check of the hypervisor functionality confirms the hypervisor functionality within the first computing environment, then the environment type verification Boolean output value indicates that the first computing environment is not a container virtual computing environment.

[0085] The twentieth example is one or more computer-readable storage media of the nineteenth example, wherein the computer-executable instructions, when executed, perform steps including the following: performing at least one of the following: checking whether a predetermined system driver component exists within the first computing environment; checking whether the resource management stack is deactivated within the first computing environment; or checking whether a predetermined firmware variable is set to a predetermined value within the firmware of the first computing environment.

[0086] From the above description, it can be seen that a mechanism for securely verifying the type of a virtual environment and utilizing such secure verification to provide tamper-resistant policy enforcement has been presented. In view of the many possible variations of the subject matter described herein, we claim all such embodiments that may fall within the scope of the appended claims and their equivalents as our invention.

Claims

1. A method for enforcing policy restrictions on execution of an application program within a first computing environment, the method comprising: obtaining application policy data corresponding to the application program from a second computing environment different from the first computing environment, the application policy data specifying a first prerequisite to be bypassed when the first computing environment is a container virtual computing environment; Perform environment type verification, including at least one of the following: inspecting the cryptographic infrastructure of the first computing environment; checking the code integrity infrastructure of the first computing environment; or checking hypervisor functionality within the first computing environment; as well as When the performed environment type verification determines that the first computing environment is not a container virtual computing environment, the execution of the application is restricted based on the first precondition.

2. The method of claim 1, wherein said checking said cryptographic infrastructure comprises verifying proper authentication of an operating system of said first computing environment.

3. The method of claim 2, wherein said checking said cryptographic infrastructure comprises verifying proper authentication of a combination of said operating system and said application of said first computing environment. 4 . The method of claim 2 , wherein said verifying said proper authentication of said operating system of said first computing environment comprises communicating with a remote authentication service external to said first computing environment.

5. The method of claim 2, wherein the verifying the proper authentication of the operating system of the first computing environment comprises comparing an authentication measurement from a first Trusted Platform Module (TPM) in the first computing environment with an authentication measurement from a second TPM in the second computing environment.

6. The method of claim 1, wherein the checking the cryptographic infrastructure comprises verifying that a certificate in a first certificate repository of the first computing environment is signed by a predetermined root of trust.

7. The method of claim 1, wherein the checking the code integrity infrastructure comprises verifying a hash of an active code integrity policy file against a secure directory comprising hashes of known good code integrity policy files.

8. The method of claim 7, wherein the checking the code integrity infrastructure comprises verifying that the security catalog is signed by one of the certificates of a predetermined trusted organization.

9. The method of claim 1, wherein the checking the hypervisor functionality comprises checking whether processor functionality commensurate with a hypervisor is exposed by a central processing unit of the first computing environment.

10. The method of claim 1, wherein said performing said environment type verification comprises checking whether a predetermined system driver component exists within said first computing environment.

11. The method of claim 1, wherein said performing said environment type verification comprises checking whether a resource management stack is deactivated within said first computing environment.

12. The method of claim 1, wherein said performing said environment type verification comprises checking whether a predetermined firmware variable is set to a predetermined value within firmware of said first computing environment.

13. The method of claim 1, wherein the first precondition restricts execution of the application to a specific computing device hardware machine identifier.

14. The method of claim 1, wherein the first precondition restricts execution of the application to a specific user identifier.

15. The method of claim 1, further comprising validating the obtained application policy data by referencing a policy management service external to the first computing environment.

16. A computing device comprising: one or more processing units; as well as one or more non-transitory computer-readable storage media comprising computer-executable instructions that, when executed by at least some of the processing units, cause the computing device to: obtaining application policy data corresponding to an application program from a second computing environment different from the first computing environment, the application policy data specifying a first prerequisite to be bypassed when the first computing environment is a container virtual computing environment; Perform environment type verification, including at least one of the following: inspecting the cryptographic infrastructure of the first computing environment; checking the code integrity infrastructure of the first computing environment; or checking hypervisor functionality within the first computing environment; as well as When the performed environment type verification determines that the first computing environment is not a container virtual computing environment, the execution of the application is restricted based on the first precondition.

17. The computing device of claim 16, wherein the first computing environment and the second computing environment are both hosted by the computing device.

18. The computing device of claim 16, wherein the first computing environment is hosted by the computing device and the second computing environment is hosted by a second computing device different from the computing device, the second computing device being communicatively coupled to the computing device.

19. One or more non-transitory computer-readable storage media comprising computer-executable instructions that, when executed within a first computing environment, perform steps comprising: receiving a request to verify the type of the first computing environment; Do at least one of the following: inspecting the cryptographic infrastructure of the first computing environment; checking the code integrity infrastructure of the first computing environment; or checking hypervisor functionality within the first computing environment; and If at least one of the check of the cryptographic infrastructure or the check of the code integrity infrastructure fails, or if the check of the hypervisor functionality confirms hypervisor functionality within the first computing environment, an environment type validation Boolean output value is generated, the environment type validation Boolean output value indicating that the first computing environment is not a container virtual computing environment.

20. The one or more non-transitory computer-readable storage media of claim 19, wherein the computer-executable instructions, when executed, perform additional steps including performing at least one of the following: checking whether a predetermined system driver component exists in the first computing environment; checking whether the resource management stack is deactivated in the first computing environment; or A check is made as to whether a predetermined firmware variable is set to a predetermined value within the firmware of the first computing environment.

Images