Validating Virtual Environment Types for Policy Enforcement

Abstract

The environment type validation can provide tamper-resistance validation of the computing environment in which the environment type validation is being performed. Such information can then be used to perform policy management, which can include eliminating checks to facilitate sharing of policies such as application licenses from the host computing environment into the container virtual computing environment. The environment type validation can perform multiple checks, including verifying the cryptographic infrastructure of the computing environment, verifying the code integrity mechanisms of the computing environment, verifying the presence of hypervisor attestation capabilities, verifying the presence of predetermined system drivers or other similar operating system components or functions, verifying the activation or deactivation of resource management stacks, and verifying the presence of predetermined values ​​in firmware.

Description

[Background technology]

[0001] background

[0001] Conventional virtual computing environments, commonly referred to as "virtual machines," virtualize most or all aspects of a computing environment, and can thereby present a computing environment that is very different from the hardware and operating system of the host computing device. However, because most or all aspects of the host computing device must be virtualized, conventional virtual computing environments can consume large amounts of memory, require excessive processing resources, and can be otherwise inefficient. In some instances, lightweight virtual computing environments, often referred to as "containers," can provide many of the isolation benefits of conventional virtual computing environments in a more efficient manner, such as by utilizing aspects of the hardware and operating system of the host computing device instead of virtualizing those aspects of the computing environment. Thus, containers can be used to provide isolated computing environments, such as to limit the impact of potentially malicious instructions, to provide unused computing environments for purposes such as testing or troubleshooting, and other similar benefits.

[0002]

[0002] A user who receives a word processing document, for example as an attachment in an email message, may be concerned that opening the word processing document may cause the execution of malicious computer-executable instructions that may infect, damage, or adversely affect the user's computer. To prevent such adverse effects, the word processing document may be opened by an appropriate word processing application program that runs in a container. The executable instructions that run in the container may not be aware of anything beyond the virtual computing environment presented by the container. Thus, even if the word processing document contains malicious computer-executable instructions, such instructions can only infect the virtual computing environment of the container and can be easily deleted or destroyed without harming the user's primary computing environment.

[0003]

[0003] Unfortunately, because a container is perceived by computer-executable instructions executing within the container as a computing environment distinct from and separate from the user's primary computing environment, executing an application program within a container may require a separate license or may not utilize licenses or other policies established by the user within the primary computing environment. Such additional licensing requirements may unnecessarily increase costs for the user or may prevent the user from utilizing his or her applications within the container environment. However, simply allowing application programs to be executed within a container based on properly licensed applications within the user's primary computing environment creates a mechanism that can be easily abused. For example, such a mechanism may be used to fraudulently share a single-user, single-instance application program license across multiple users and across multiple different computing environments, including various physical computing devices and various virtual machines, so that it can be hosted in large numbers and made available to anyone on the Internet. Summary of the Invention

[0004] overview

[0004] The environment type verification can provide a tamper-resistant 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 eliminating checks to facilitate sharing of policies such as application licenses from the host computing environment into the container virtual computing environment. The environment type verification can perform multiple checks, including checking the encryption infrastructure of the computing environment in which the environment type verification is being performed, checking the code integrity mechanism of the computing environment, checking the presence of a function to attest to a hypervisor, checking the presence or absence of a predetermined system driver or other similar operating system component or function, checking the activation or deactivation of a resource management stack, checking the presence or absence of a predetermined value in firmware, and other similar checks that can be performed in the computing environment whose type of environment is being verified. In such a manner, the policy management can enable the sharing of policies, including application licenses, between the host computing environment and the container virtual computing environment, while preventing the use of such policy sharing for malicious purposes, such as to fraudulently gain access to an application program or a specific function provided by an application program by spoofing a computing environment hosted directly by computing hardware or a virtual machine to appear as a container virtual computing environment.

[0005]

[0005] 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 to limit the scope of the claimed subject matter.

[0006]

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

[0007] Description of the drawings

[0007] The following detailed description can be best understood when read in conjunction with the accompanying drawings. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a system diagram of an exemplary system for policy enforcement. [Diagram 2]

[0009] FIG. 1 is a system diagram of an example system including a container virtual computing environment. [Diagram 3]

[0010] FIG. 1 is a system diagram of an exemplary system for virtual environment type validation and policy enforcement. [Figure 4]

[0011] 13 is a flow diagram of an example validation of a virtual environment type. [Diagram 5]

[0012] 1 is a flow diagram of an example policy enforcement utilizing virtual environment type validation. [Figure 6]

[0013] FIG. 1 is a block diagram of an exemplary computing device. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Detailed Description

[0014] The following description relates to tamper-resistant environment type detection to enable sharing of policies, including application licenses, between a host computing environment and a container virtual computing environment, while preventing use of such policy sharing for malicious purposes, such as to spoof a computing environment hosted directly by computing hardware or by a virtual machine to appear as a container virtual computing environment, thereby fraudulently gaining access to an application program or specific features provided by the application program. The environment type verification can provide a tamper-resistant 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 eliminating verifications to facilitate sharing of policies, such as application licenses, from the host computing environment into the container virtual computing environment. The environment type verification can perform multiple checks, including verifying the encryption infrastructure of the computing environment in which the environment type verification is being performed, verifying the code integrity mechanism of the computing environment, checking for the presence of a hypervisor attestation function, checking for the presence or absence of a predetermined system driver or other similar operating system component or feature, checking for activation or deactivation of a resource management stack, checking for the presence or absence of a predetermined value in firmware, and other similar checks that can be performed in the computing environment in which the environment type is being verified.

[0010]

[0015] Although not required, the following description is in the general context of computer-executable instructions, such as program modules, executed by a computing device. More particularly, the description refers to symbolic representations of acts and operations that are performed by one or more computing devices or peripherals, unless otherwise specified. As such, it will be understood that acts and operations sometimes referred to as being computer-performed include unitary manipulation of electrical signals that represent data in a structured form. This manipulation transforms the data or holds the data in locations in memory that reconfigure or alter the operation of the computing device or peripheral in ways that are well known to those skilled in the art. The data structures in which data is held are physical locations that have particular characteristics that are determined by the type of the data.

[0011]

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

[0012]

[0017] 1, an exemplary system 100 is shown to provide a context for the following description. The exemplary system 100 includes an exemplary computing environment 190, which for purposes of providing a 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 is directed to other types of computing environments, such as computing environments created by virtual machine programs and virtual computing environments, such as computing environments created by container processes.

[0013]

[0018] Typically, when an application program is instantiated, its ability to run may be subject to protections present within the computing environment 190, such as code integrity protections that delineate which application programs may run within the computing environment 190. Such protections may be based on a whitelist, whereby application programs that are not explicitly listed are prevented from running within the computing environment 190, or such protections may be based on a blacklist, whereby application programs are permitted to run within the computing environment 190 unless they are explicitly listed in the blacklist.

[0014]

[0019] Subsequent execution of the application program may be further subject to policy management, which may include verifying that the application program is properly licensed to execute within computing environment 190. For example, an application program that is not properly licensed may terminate its execution or may present the user with a limited set of functionality, such as trial functionality, that allows the user to evaluate the application program but cannot be fully utilized without a proper license.

[0015]

[0020] Within the example system 100 of FIG. 1, an application program may be instantiated into an application instance 110. The application instance 110 is illustrated with dashed lines to indicate that execution of the application instance 110 may be conditional on a number of factors including, for example, approval 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 the application program into the application instance 110 may involve a determination 124 by example code integrity enforcement 120 of whether an associated code integrity policy file, such as example code integrity policy file 140, permits execution of the application program within the computing environment 190. As previously indicated, the code integrity policy file 140 may take the form of a blacklist or a whitelist.

[0016]

[0021] According to one aspect, in addition to referencing a code integrity policy file, such as the example code integrity policy file 140, the example code integrity enforcement 120 may further verify that the referenced code integrity policy file 140 has not been tampered with to tamper with an application should be allowed to run. Such verification may involve comparing a hash of the code integrity policy file 140 to a hash of a known good policy file, such as may be stored in the security catalog 160. For example, a hash of the code integrity policy file 140 may be generated when the computing environment 190 is initially created, and such hash may be stored in the example security catalog 160. To prevent tampering with the security catalog 160, the security catalog 160 may be signed with an organizational trust certificate or other similar cryptographic information of a 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 security catalog 160, with a matching comparison indicating that the referenced code integrity policy file 140 has not been tampered with or has been tampered with, and therefore contains accurate information.

[0017]

[0022] The instantiation of an application program may further be subject to policy management, such as exemplary policy management 130, which may enforce licenses, organizational policies, or other similar policy-based restrictions. For example, a developer of an application program being instantiated into application instance 110 may prevent the application program from running unless it is properly licensed, such as by a user purchasing a license from the developer, to prevent theft of their application program and to provide monetization of their programming efforts. In such cases, exemplary application policy file 150 may be in the form of a license. Exemplary application policy file 150 may be referenced at the time of instantiation of an application program to inform or restrict the execution of the application. For example, if application policy file 150 is missing, the application program may be notified and may terminate execution. As another example, an application program may exhibit limited functionality if it is not properly licensed or if a license cannot be found.

[0018]

[0023] In addition to licensing, other forms of policy may be enforced by the example policy management 130. For example, an organization may wish to prevent certain applications from being executed on its computing devices. In such cases, the example 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 types of transactions, such as in-app purchases, payments utilizing certain computerized payment schemes, etc. Still other examples of application policy files may include deployment policy files and certificates.

[0019]

[0024] A policy file, such as the exemplary application policy file 150, can provide a mechanism by which conditional behavior of an application program can be enforced. As shown, such conditional behavior may be desired by the developer of the application program, an organization providing the computing environment 190, or other similar institution. Such conditions may be based on a user identifier, a computing device identifier, or other environmental factors. For example, the exemplary application policy file 150 can be a validly purchased license from the developer of the application program that may be indicated to expire on a particular date. As a result, the exemplary policy management 130 can obtain current date information to determine whether the exemplary application policy file 150 includes information that affects the execution of the application program, as indicated by decision 135. For example, if the current date information is past the date indicated in the exemplary application policy file 150, the exemplary policy management 130 can indicate to the application program that the application program is no longer properly licensed. As another example, the exemplary application policy file 150 can be a validly purchased license that may be restricted to a particular user or a particular computing device. In such cases, example policy management 130 can obtain a user identifier, computing device identifier, or other similar information to determine whether example application policy file 150 includes information that affects execution of the application program, as indicated by decision 135. Again, if policy management 130 determines that, for example, the user identifier of a user attempting to instantiate an application program into application instance 110 is different than that required by application policy file 150, policy management 130 can so inform the application program, and the application program can take appropriate corrective action, such as by terminating execution of the application or by presenting only a limited set of functionality.

[0020]

[0025] According to one aspect, to verify that an application policy file, such as the exemplary application policy file 150, has not been tampered with or tampered with, a hash of the application policy file 150 can be compared to a hash of a "known good" application policy file, or to a hash of an application policy file whose hash was taken at a time when the file could not have been practically tampered with or modified from its intended state. A policy management service, such as the exemplary policy management service 170, can act as a clearinghouse for policies and can maintain hashes of "known good" policies. The exemplary policy management service 170 can be a centralized service that runs on one or more server computing devices and is accessible via network communications with such computing devices. Alternatively or additionally, the exemplary policy management service 170 can run locally on the same computing device that runs the computing environment 190, except as a separate process or other similar encapsulation. According to one aspect, a policy management service, such as exemplary policy management service 170, may include a policy store, such as exemplary policy store 171, and a policy database, such as exemplary policy database 172. Exemplary policy store 171 may provide a mechanism by which updated policy information can be actively distributed to multiple computing devices of an organization, multiple computing devices to which an application program was previously licensed from an application developer or application program store, or other similar active distribution of updated policy information. Recent policies may be stored in policy database 172 along with hashes corresponding to those most recent policies.Because policy management service 170 may be inaccessible or less accessible than application policy file 150, may provide additional protection, and may otherwise prevent tampering, one mechanism for verifying that example application policy file 150 has not been tampered with or modified may be to hash example application policy file 150 and compare the resulting hash value to a corresponding hash value stored in policy database 172 or communicate with example policy management service 170. Once such verification action 137 has been taken, conditional requirements of application policy file 150 as detailed above may be considered, and the application may be notified of any restrictions or other similar impacts on the application's execution that may be necessitated by evaluation of the corresponding application policy file 150, as illustrated by example notification 131.

[0021]

[0026] Although illustrated 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 a separate external policy management function.

[0022]

[0027] As indicated above, there may be instances where a user would like to run an application program in a container virtual computing environment, rather than in a computing environment hosted on "bare metal" or by a full-fledged virtual machine, as is often provided by cloud computing providers. For example, there may be security issues affecting the execution of the application program or the files it operates on, which may be remedied by running the application program in a limited and protected computing environment, which may be easily removed or terminated if the need arises. As another example, there may be advantages to running an application program in a clean computing environment. For example, web pages often utilize repositories of cookies or other data to track users, such as by recording web pages visited, search terms used, and other similar personal information. Thus, a user who does not want to allow web pages to access previously stored information, such as cookies, may run a web browser application program in a container virtual computing environment, which may be a clean computing environment that does not include such cookies or other similar data.

[0023]

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

[0024]

[0029] Turning to FIG. 2 , the illustrated system illustrates various associations between container virtual computing environments and established computing environments, such as those that a user may present via his or her personal computing device. For example, exemplary system 201 includes a user 210 utilizing a personal computing device 220. The exemplary personal computing device 220 may present to the user 210 an established computing environment 231, such as those that may be generated by an operating system and corresponding computer-executable instructions executing on the personal computing device 220. Such established personal computing environment 231 may include a container manager 241 that may establish a container virtual computing environment and share appropriate aspects of the operating system or other similar resources of the established computing environment 231. When the user 210 requires such a container virtual computing environment, such as to open a potentially malicious email attachment, the container manager 241 may create a container instance, such as exemplary container instance 251, which may also be executed by the same personal computing device 220.

[0025]

[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 can execute an established computing environment 232, which can be a virtual computing environment hosted by a virtual machine. The established computing environment 232 can include application programs that the user wishes to utilize on the personal computing device 220. One mechanism by which the user 210 can utilize such application programs on his or her personal computing device 220 can be within a container instance, which can 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 can launch a container instance, such as the exemplary container instance 252. The established computing environment 232 on the cloud service 260 can establish appropriate communications to serve as a host computing environment for the container instance 252, even though the container instance 252 can be managed by the container manager 242 executing remotely from the cloud service 260.

[0026]

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

[0027]

[0032] As indicated above, because a container virtual computing environment may be perceived as a separate computing device by computer executable instructions executed within the container virtual computing environment, licensing and other similar policy aspects may not transfer to the container virtual computing environment. Thus, for example, a user who receives a word processing attachment via an email message that the user is concerned may be malicious may be able to open the attachment using a word processing application program executed within the container virtual computing environment. However, while the user may have a valid license to use the word processing application program, the license may be limited to the host computing environment, and thus, when the user attempts to open the attachment using the word processing application program executed within the container virtual computing environment, the user may receive an indication that his or her word processing application program is not licensed, since from the perspective of the computer executable instructions executed within the container virtual computing environment, the application may appear to be running on a different computing device by a different user. Thus, if a user has multiple licenses for an application program, opening the attachment using a word processing application program executed within the container virtual computing environment may consume another license from a set of pre-purchased licenses without the user's consent. Unfortunately, however, simply disabling license checking for application programs executed within a container virtual computing environment may allow a malicious user to easily steal or fraudulently obtain application programs by simply having the malicious user's personal computing device present itself as an authorized user's container virtual computing environment, thereby allowing the authorized user's single license to be fraudulently shared among many different users and utilized among many different computing devices.

[0028]

[0033] To prevent such theft and other unauthorized acquisition of application programs, while at the same time facilitating legitimate use of application programs within container virtual computing environments, environment type verification can be performed to verify that the computing environment is in fact a proper container and is not merely presenting itself as being a proper environment for bypassing license or other policy restrictions. Such environment type verification can then inform appropriate policy management mechanisms to enable the application program to respond appropriately.

[0029]

[0034] Turning now to FIG. 3, the illustrated example system 300 illustrates the example policy management service 170 and the example computing environment 190 described in detail above. Additionally, a virtual computing environment created by a container process in the form of an example container instance 390 is also illustrated in the example system 300 FIG. 3. The example container instance 390 may have been created by a container management function as detailed above with respect to FIG. 2, and the example computing environment 190 may act as a host for the example container instance 390. As will be described in more detail below, the mechanisms illustrated and described herein may enable a container application instance 310 of the same application program as the application instance 110 executing in the computing environment 190 to execute in the virtual computing environment of the container instance 390 while utilizing the application policy file 150 of the host computing environment 190.

[0030]

[0035] According to one aspect, a secure communication can be established between the host computing environment 190 and the container instance 390, such as by the exemplary secure communication mechanisms 361 and 362. The exemplary secure communication mechanisms 361 and 362 can be based on an asymmetric key cryptography structure. For example, when the container instance 390 is launched in a manner as detailed above, the container instance 390 can be provided with the 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 can be provided with seed data from which the secure communication mechanism 362 executing within the container instance 390 can derive the same keys as the exemplary secure communication mechanism 361 executing within the host computing environment 190, using known cryptographic mechanisms. As yet another example, a user may be required to manually enter the required cryptographic information into both the secure communication mechanism 361 and the secure communication mechanism 362, or other similar out-of-band communication can be used to securely exchange cryptographic information to establish a secure communication connection.

[0031]

[0036] Once a secure communication between the example host computing environment 190 and the example container instance 390 is established, the application policy file 150, described in detail above with respect to FIG. 1, may be shared from the example host computing environment 190 to the container instance 390. For example, a secure file share, such as the example file share 363, may be established such that processes executing within the container instance 390 may access the application policy 150 within the example host computing environment 190. To visually represent the access of the application policy file 150 from within the container instance 390, the application policy file 150 is shown in both the example host computing environment 190 and the example container instance 390.

[0032]

[0037] According to one aspect, when an attempt is made to instantiate a container instance 310 for an application, code integrity enforcement, such as example code integrity enforcement 320 similar to example code integrity enforcement 120 described in detail above, may verify that the application is permitted to run within the container instance 390. For example, the container instance 390 may have been created with a code integrity policy file 340 that may be different than the code integrity policy file 140 shown in FIG. 1 that may be part of the computing environment 190. As another example, the computing environment 190 may not implement code integrity enforcement 120 shown in FIG. 1 and code integrity enforcement may be limited to the container instance, such as example code integrity enforcement 320 running within the example container instance 390.

[0033]

[0038] As previously mentioned, a code integrity enforcement, such as example code integrity enforcement 320, may approve 321 instantiation of the container application instance 310 based on verifying 324 that an associated code integrity policy file, such as example code integrity policy file 340, supports execution of the container application instance 310 within the example container instance 390, and further verifying 326 that the code integrity policy file 340 has not been modified or tampered with, such as by referencing example security catalog 360. As previously mentioned, such verification may be based on a hash comparison.

[0034]

[0039] Additionally, as also described above, a policy manager, such as the example policy manager 330, may further influence the instantiation of the container application instance 310. However, according to one aspect, when executed within a container instance, such as the example container instance 390, the example policy manager 330 may be informed by an environment type validation, such as the example environment type validation 350, which may provide information regarding the type of execution environment in which the policy manager 330 and / or the container application instance 310 are executing. For example, the environment type validation may provide an indication of whether the container instance 390 is in fact a proper container, thereby enabling detection of other types of execution environments that may maliciously appear as container execution environments in order to exploit licensing restrictions and gain unauthorized access to application program functionality. The information provided by the environment type validation 350 information may be utilized by the policy manager 330 in conjunction with the shared application policy file 150. Alternatively or additionally, the environment type validation 350 may first inform the creation of the file share 363. For example, based on mechanisms described in more detail below, if environment type validation 350 determines that container instance 390 is not a proper container, e.g., because container instance 390 is a virtual computing environment hosted by a virtual machine or a computing environment of another computing device that has simply been maliciously modified to appear as a container instance in order to unauthorizedly access application programs, environment type validation 350 can prevent the creation of file share 363, e.g., by withholding relevant information, e.g., necessary cryptographic information, or by explicitly indicating that file share 363 not be created. Thus, according to such an aspect, application policy file 150 is not accessible from within container instance 390 and container application instance 310 is not properly licensed, thereby indicating theft by spoofing a virtual environment type.

[0035]

[0040] Returning to the manner in which environment type validation 350 provides information 353 providing information regarding container instance 390, such information 353 may be utilized by policy management 330 to perform inspection 335 of application policy file 150 shared from computing environment 190. For example, application policy file 150 may include information indicating that an application program cannot be properly licensed to run within a container instance, such as exemplary container instance 390. In such a 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 exhibit a reduced set of functionality. As another example, application policy 150 may include information indicating that an application program is licensed to run within a container instance, such as exemplary container instance 390. In that case, application policy 150 may include further information to facilitate licensing of application programs to run within a container instance. For example, checks based on user identifiers, machine identifiers, etc., including those detailed above, may not be possible to perform from within container instance 390 because container instance 390 may include a different machine identifier or may not have access to a user identifier. Thus, application policy 150 may allow for bypassing such checks if container application instance 310 is running within an appropriate container instance. Thus, the information provided by environment type validation 350 may prevent bypassing such checks from being used for malicious purposes, such as to fraudulently gain access to application programs.

[0036]

[0041] According to one embodiment, policy management 330 can perform a validation 337 with policy management service 170 in a manner similar to that detailed above. For example, policy management 330 can hash application policy file 150 and compare such hash or request that policy management service 170 compare the hash with a hash of a known good application policy file. According to one embodiment, if the hash matches a hash of a known good application policy file, policy management service 170 can further check whether an application policy corresponding to such hash has already been assigned, such as to an application instance 110 that may be running within computing environment 190. If an application policy has not yet been assigned, or if it has been assigned but the query from policy management 330 originates from the proper container instance as determined by environment type validation 350, policy management service 170 can respond that the query has been validated. In such a manner, validation can be performed both that application policy 150 has not been tampered with or modified and that the request originates from the proper container instance. The example policy management 330 may then allow the container application instance 310 to continue running and provide full licensed functionality.

[0037]

[0042] As indicated above, a policy manager, such as the example policy manager 330, can be part of an application program, such as the example container application instance 310. Similarly, as also indicated above, a policy management service, such as the example policy management service 170, can run on one or more remote computing devices, on the same computing device but outside of the container instance 390, or within the container instance 390. Environment type validation, the operation of which is described in further detail below, can be part of the application program or can be separate and invoked by the policy manager 330 in the manner shown in the example system 300 of FIG. 3, or can be invoked directly by the application program.

[0038]

[0043] Moving to operation 351 of the example environment type validation 350, according to one aspect, the example environment type validation 350 may provide Boolean information 353 indicating only whether the container instance 390 is or is not a "suitable" container, where the "suitability" of the container instance 390 may be pre-determined and evaluated based on a set of predefined tests as described in further detail below. However, according to another aspect, the example environment type validation 350 may output information 353 that may identify a particular type of execution environment, such as distinguishing between a computing environment hosted by a virtual machine application program and a computing environment hosted by a container instance. According to yet another aspect, the information 353 provided by the example environment type validation 350 may include information about the environment type or other environment type metadata that may be related to one or more conditions enumerated in the application policy file 150 or that may otherwise inform the conditional behavior of the policy management 330. For example, the information 353 may include details regarding one or more of the tests that the environment type validation 350 may provide.

[0039]

[0044] To describe an environment type verification operation, such as exemplary environment type verification 350, reference is made to a Boolean output 353. However, as detailed above, the described operations 351 can equally produce outputs 353 that can vary in scope and complexity. Turning to exemplary operation 351, as shown in FIG. 3, a number of checks can be performed to verify that container instance 390 is a proper container instance and not a different virtual computing environment that has been spoofed or modified to appear as a container instance, for example, to exploit a less restrictive application policy or to illicitly gain access to an application program.

[0040]

[0045] According to one aspect, the environment type validation can verify the cryptographic infrastructure of the virtual computing environment in which the environment type validation is being performed, including, for example, the cryptographic infrastructure utilized by the secure communication mechanisms 361 and 362. For example, the environment type validation 350 can check whether a certificate store is available within the container instance 390. Within such a certificate store, the environment type validation 350 can check whether a certificate has or is signed by an expected root of trust, which may be an organizational root of trust or another known good root of trust. As another example, the environment type validation 350 can leverage existing attestation techniques within the container instance 390. For example, an operating system running within the virtual computing environment provided by the container instance 390 can be "measured" by hashing, modules, or other similar collections of computer executable instructions, etc., when loaded by the operating system as part of a boot sequence. This measurement can be performed with the aid of a Trusted Platform Module (TPM) that can securely store such measurements. Upon completion of the operating system boot, if all of the modules and similar collections of computer-executable instructions loaded as part of the operating system boot are unmodified and otherwise proper, the resulting measurements should match the known good measurements. In such cases, environment type validation 350 can verify that such attestation occurred, and was performed correctly, such as by referencing the measurements of the booted operating system against the known good measurements. Environment type validation 350 can utilize an external attestation service to compare the measurements of the booted operating system of container instance 390 against the known good measurements. If the measurements do not match, environment type validation 350 can conclude that container instance 390 is not a proper container instance.Although discussed above with respect to operating system components, such attestation can be extended to the invocation of specific application programs, including application programs instantiated to create container application instances 310.

[0041]

[0046] According to another aspect, the environment type validation can verify the code integrity infrastructure of the container instance 390. For example, the environment type validation 350 can interface with the code integrity enforcement 320 to verify a hash of the code integrity policy file 340, verify the signature of the security catalog 360, which may be signed by an organizational trust certificate or other similar root of trust as previously indicated, or perform other checks of the code integrity enforcement 320. Failure of any one or more of such checks can result in the environment type validation 350 concluding that the virtual environment in which it is executing is not a proper container instance. To further reduce theft or other malicious behavior, the code integrity infrastructure validation can be utilized in combination with more restrictive code integrity enforcement within the container instance. For example, the container instance can be created with a limited whitelist type code integrity policy file, such as the exemplary code integrity policy file 340. The container instance 390 can include, for example, the code integrity policy file 340, and can allow only container application instances 310 or otherwise a limited whitelist as appropriate. Any attempt to use such a container instance 390 to run a different application may fail due to code integrity enforcement 320, or if the code integrity infrastructure is tampered with to enable the execution of a different application, such modification may be detected by environment type validation 350, which may then generate information 353 that still prevents the use of the container instance 390 to run the different application.

[0042]

[0047] According to yet another aspect, environment type validation 350 can check for various features or lack of such features, specific code segments or lack of such code segments, and other similar indicators of environment type. For example, environment type validation 350 can check for the presence or accessibility of a hypervisor. Such checks can be made by an application program interface that can query the capabilities of one or more central processing units. More specifically, a central processing unit having hypervisor capabilities can expose its features or capabilities by such an application program interface, and the presence of such features or capabilities can indicate the presence of a hypervisor. According to an aspect, if environment type validation 350 detects the presence of a hypervisor, environment type validation 350 can conclude that the environment in which it is running is not a proper container, or that the environment is not a container-hosted execution environment, but may instead be a virtual machine-hosted execution environment. Similarly, environment type validation 350 can check for the presence of certain system drivers in the environment. The presence or absence of such system drivers can cause environment type validation 350 to conclude that the environment in which it is running is not a proper container. Similar checks can be made, for example, regarding whether certain features have been turned off. Specifically, environment type validation 350 can check whether a resource management stack has been turned off, and if such resource management stack has not been turned off, environment type validation 350 can conclude that container instance 390 is invalid. Another check can be made on firmware accessible to the execution environment. For example, certain firmware variables may be required to be added 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 can cause environment type validation 350 to conclude that container instance 390 is not a proper container.

[0043]

[0048] The above operations 351 are merely exemplary, and the tests performed and their order can be adjusted to detect specific attack vectors or other similar means by which malicious or malicious exploitation may be achieved. Other tests can be performed as well, and again, the output 353 provided by environment type validation 350, as previously shown, can provide further details, such as identifying a particular execution environment type or providing information regarding one or more of the tests. For example, an exemplary environment type validation 350 can check whether a container instance 390 is kernel quarantined. As another example, environment type validation 350 can check for a particular exposed operating system feature.

[0044]

[0049] According to one aspect, information 353 provided by environment type validation 350 may enable policy management 330 and / or container application instance 310 to select among multiple different versions of an application program, including different versions that may be produced, sold, and / or treated as separate products (e.g., by having different SKU numbers or other similar product identifiers). For example, if a particular one of the tests 351 is passed, environment type validation 350 may provide an output 353 indicating that such test was passed to policy management 330, which may be part of container application instance 310 as previously indicated. Policy management 330 may determine, for example, based on information 353 provided by environment type validation 350, such as by referencing application policy file 150, that one version of an application program instantiated into container application instance 310 may be permitted to run within container instance 390, but another version of the same application program may not be permitted to run. For example, detecting the absence of a particular system driver within container instance 390 by environment type validation 350 may cause policy management 330 to allow a more restricted version of a music editing program to be executed that does not allow input from an external audio source, such as a microphone. In such an example, detection by environment type validation 350 may not cause container application instance 310 to terminate execution, but may instead cause a different version of the application program product to be executed. Thus, including in such an example, if application instance 110 is an enhanced version of a music editing program and a user executes the same music editing program within container instance 390, detection by environment type validation 350 in combination with policy management 330 acting on information 353 provided by environment type validation 350 may cause the application program to seamlessly transition to and execute the more restricted version of the same music editing program as container application instance 310.

[0045]

[0050] Turning now to FIG. 4, an exemplary flow diagram 400 is shown illustrating a series of exemplary 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 the conclusion reached by the preliminary steps. Alternatively or additionally, a conclusion 480 that the execution environment is not a suitable container may be reached 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 reached only if none of the steps make a contrary determination. Additionally, the order of steps performed may vary, and the order shown in FIG. 4 is merely exemplary. Finally, the boolean conclusions 470 and 480 output by the environment type validation as shown above are only one aspect, and in other aspects the conclusions made may be an indication of a particular type of execution environment, as selected from a predetermined set of possibilities, as well as providing information or other similar metadata, including outputting information regarding the results of any one or more of the tests performed, as indicated by steps 420-460.

[0046]

[0051] The exemplary flow diagram 400 begins at step 410, where an environment type verification may be requested or initiated. In response, an initial determination may be made at step 420, such as a verification of the cryptographic infrastructure. As indicated above, such a verification of the cryptographic infrastructure may be a verification of proper attestation of the booted operating system of the execution environment, or of the booted operating system in combination with one or more executed application programs, or other similar attestation. As also indicated above, a verification of the cryptographic infrastructure, such as at step 420, may be a verification that a certificate in a certificate store of the execution environment has an expected root of trust or is properly signed. If the execution environment includes a TPM, step 420 may also include comparing measurements from the TPM of the host computing environment, as may have been obtained during attestation of the host computing environment, with measurements from the execution environment, such as a verified container environment in which the instructions corresponding to step 420 are executed. If at step 420, the cryptographic infrastructure is not verified in the manner detailed above, a conclusion 480 may be reached that the execution environment is not a proper container. Alternatively, if the encryption infrastructure is verified in step 420 , processing may proceed to perform one or more other checks, such as in steps 430 through 460 .

[0047]

[0052] Although shown as a subsequent step 430 in the exemplary flow diagram 400, according to one aspect, step 430 may be performed first instead of step 420. As detailed above, step 430 may verify the code integrity mechanism. For example, the code integrity policy file may be verified, such as by verifying 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 security catalog or other similar data structure that may itself be protected. Thus, another aspect of step 430 may be verifying that such a security catalog is signed by an organizational trust certificate or may be otherwise verified. If step 430 does not verify the code integrity mechanism in the manner detailed above, a conclusion 480 may be reached that the execution environment is not a suitable container. Alternatively, if step 430 does verify the code integrity mechanism, processing may proceed to perform one or more other checks, such as in steps 440 through 460.

[0048]

[0053] As indicated above, steps 440 through 460 may be alternative or secondary checks that may be performed to further verify the environment type. For example, step 440 may check for the presence or availability of certain resources, such as the presence of a hypervisor. As detailed above, the presence of a hypervisor may be indirectly revealed by determining that the CPUs available in the execution environment expose the functionality provided by the hypervisor, which may be determined by appropriate API calls. Other resources whose presence may be revealed may include a resource management stack that may be turned off in a container, such that detecting that the resource management stack is turned off may be an indication that the execution environment is a proper container. Conversely, detecting a hypervisor or detecting that the resource management stack is turned on may result in a conclusion 480 that the environment is not a proper container.

[0049]

[0054] As another example, a check may be made at step 450 for the presence of a particular system driver within the execution environment. If the relevant system driver is not present within the execution environment, or is configured differently than the predefined correct configuration, a conclusion 480 may be reached that the environment is not a suitable container. As yet another example, a check may be made at step 460 for firmware accessible to the execution environment. For example, a particular firmware variable may be required to be added to the environment, such as by a container manager or the host computing environment. The absence of such a firmware variable may result in a conclusion 480 that the environment is not a suitable container.

[0050]

[0055] Upon completing the various checks, if a conclusion 480 that the environment is not a suitable container is not otherwise reached, a converse conclusion 470 that the environment is a suitable container may be reached and the conclusion 470 communicated to the process invoking the environment type validation.

[0051]

[0056] As previously indicated, such environment type validation may be part of a larger validation mechanism to enable license sharing between the host execution environment and the container execution environment. Turning now to FIG. 5, an exemplary flow diagram 500 is shown illustrating a series of exemplary steps that may be taken to facilitate such sharing and enable application programs to be executed within a container instance. Initially, at step 510, a container instance may be created, such as by a container manager, and provisioned with one or more cryptographic data, such as asymmetric security keys, that may be utilized, such as at step 515, to establish a secure communication channel between the container instance and an established computing environment that may serve as a host computing environment and may have triggered the creation of the container instance at step 510. At step 520, the secure communication channel established at step 515 may be utilized to share an application policy file from the host computing environment to the container instance. As previously indicated, according to one aspect, establishing the secure communication channel (515) is contingent on validating the execution environment as a suitable container in the manner illustrated in FIG. 4, the execution of which is illustrated generally as step 545 in the exemplary flow diagram 500 of FIG. 5.

[0052]

[0057] At step 525, the associated application program may attempt to be instantiated within 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 verify that the application is permitted to run. As previously indicated, code integrity protection may be enforced by a policy file, which may be in the form of a whitelist, 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 that hash against a security catalog, which may contain hashes of known good code integrity policies. The verification at step 535 may further involve verifying the security catalog itself, such as by verifying that it is properly signed. At step 540, code integrity may approve instantiation of the application program within the container instance.

[0053]

[0058] As part of referencing the shared application policy at step 520, the execution environment may be verified as a suitable container in the manner detailed above with respect to FIG. 4. In the example flow diagram 500 shown in FIG. 5, such verification is shown as occurring at step 545, but as previously indicated, such verification may occur at other points in the example flow diagram 500 and may be provided as input to multiple steps of the example flow diagram 500. One such step may be the reference of the shared application policy at step 550. As previously indicated, if the execution environment is verified as a suitable container at step 545, the shared application policy may be referenced at step 550 to determine whether a license or other policy implication permits the application program to be executed within the virtual computing environment created by the properly verified container. The reference at step 550 may determine that, to facilitate the execution of the application program within the container, the associated policy file may deactivate certain checks, such as restrictions based on user identity, machine identity, and other similar checks that cannot be performed to validate the execution environment. A hash of the application policy may then be generated in step 555, and verified in step 560 by comparing the hash to known good policy hashes, such as by reference to a remote policy management service. As previously indicated, the policy management service may run within the container instance, may run on the same computing device as the container instance but outside of the container instance, or may run on one or more remote computing devices. If the shared application policy is verified in step 560, processing may proceed to step 565, where the application may be appropriately notified, such as by being instructed to run with appropriate restrictions based on the conditions in the shared application policy informed by the verification of step 545.More specifically, while some checks may be deactivated, such as by validating the execution environment as a suitable container at step 545, other checks, such as time-based checks, may still be part of the application policy and may still restrict execution of the application within the container instance at step 565, for example if the application attempts to run after a license has expired. In other examples, step 565 may not restrict execution of the application and may instead allow the application to run and provide full functionality within the container instance. With appropriate feedback from policy management, execution of the application within the container instance may proceed at step 570.

[0054]

[0059] Turning now to FIG. 6, an exemplary computing device 600 capable of performing some or all of the above mechanisms and actions is illustrated. The exemplary computing device 600 may include one or more central processing units (CPUs) 620, a system memory 630, and a system bus 621 coupling various system components, including the system memory, to the processing unit 620. The system bus 621 may be any of several 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 accepting user input via touch, such as a touch-sensitive display device or a multi-touch enabled display device. Depending on the particular physical implementation, the CPU 620, the system memory 630, and one or more of the other components of the computing device 600 may be physically co-located, such as on a single chip. In that case, some or all of the system bus 621 may simply be silicon paths within a single chip structure, and its illustration in FIG. 6 may be merely a notation for explanatory purposes.

[0055]

[0060] Computing device 600 also typically includes computer readable media, which may include any available media accessible by computing device 600, including both volatile and non-volatile media, and removable and non-removable media. By way of example and not limitation, computer readable media may include computer storage media and communication media. Computer storage media includes 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 includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired content and accessible by computing device 600. However, computer storage media does not include communication media. Communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any content delivery media. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above are also intended to be included within the scope of computer-readable media.

[0056]

[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 the basic routines that help to transfer content between elements within the computing device 600, such as during start-up, is typically stored in ROM 631. RAM 632 typically contains data and / or program modules that are immediately accessible to and / or presently being operated on by the processing unit 620. By way of example, and not limitation, FIG. 6 illustrates operating system 634, other program modules 635, and program data 636.

[0057]

[0062] Computing device 600 may also include other removable / non-removable, volatile / non-volatile computer storage media. By way of example only, FIG. 6 illustrates a hard disk drive 641 that reads from and writes to a non-removable, non-volatile magnetic medium. Other removable / non-removable, volatile / non-volatile computer storage media that may be used with the exemplary computing device include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and other computer storage media as defined and described in detail above. Hard disk drive 641 is typically connected to system bus 621 by a non-volatile memory interface such as interface 640.

[0058]

[0063] The drives and their associated computer storage media discussed above and illustrated in Figure 6 provide storage of computer readable instructions, data structures, program modules and other data for computing device 600. In Figure 6, hard disk drive 641 is illustrated as storing, for example, operating system 644, other program modules 645, and program data 646. Note that these components can either 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 to illustrate that, at a minimum, they are different copies.

[0059]

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

[0060]

[0065] Although described as a single physical device, the exemplary computing device 600 may be a virtual computing device, where 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 dynamically distributed across multiple physical computing devices so that the particular physical computing device hosting such computer-executable instructions may change dynamically over time depending on demand and availability. In situations where the exemplary computing device 600 is a virtualized device, the underlying physical computing device hosting such virtualized computing device may itself include physical components similar to those described above and operating similarly. Furthermore, virtual computing devices may be utilized within multiple layers, where one virtual computing device executes within the construct of another virtual computing device. Thus, as used herein, the term "computing device" refers to a virtualized computing environment, including a physical computing device or a virtual computing device, in which computer-executable instructions may be executed in a manner consistent with their execution by a physical computing device. Similarly, as used herein, terms referring to physical components of a computing device may refer to those physical components or to virtualizations thereof that perform the same or equivalent functions.

[0061]

[0066] The above description includes, as a first example, a method for enforcing policy restrictions on execution of an application program in a first computing environment, the method including 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 pre-condition to be bypassed if the first computing environment is a container virtual computing environment; performing an environment type verification including at least one of 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 restricting execution of the application program based on the first pre-condition if the environment type verification determined that the first computing environment is not a container virtual computing environment.

[0062]

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

[0063]

[0068] A third example is the method of the second example, where verifying the cryptographic infrastructure includes verifying proper attestation of an operating system and application program combination of the first computing environment.

[0064]

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

[0065]

[0070] A fifth example is the method of the second example, where verifying proper attestation of the operating system of the first computing environment includes comparing attestation measurements from a first Trusted Platform Module (TPM) in the first computing environment with attestation measurements from a second TPM in the second computing environment.

[0066]

[0071] A sixth example is the method of the first example, where verifying 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.

[0067]

[0072] A seventh example is the method of the first example, where validating the code integrity infrastructure includes verifying a hash of the active code integrity policy file against a security catalog that includes hashes of known good code integrity policy files.

[0068]

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

[0069]

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

[0070]

[0075] A tenth example is the method of the first example, where performing the environment type validation includes checking whether a predefined system driver component is present in the first computing environment.

[0071]

[0076] An eleventh example is the method of the first example, where performing the environment type validation includes checking whether a resource management stack is deactivated in the first computing environment.

[0072]

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

[0073]

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

[0074]

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

[0075]

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

[0076]

[0081] A sixteenth example is a computing device that includes one or more processing devices and one or more computer-readable storage media containing computer-executable instructions that, when executed by at least a portion of the processing devices, cause the computing device to obtain application policy data corresponding to an application program from a second computing environment different from a first computing environment, the application policy data specifying a first pre-condition to be bypassed if the first computing environment is a container virtual computing environment; perform an environment type verification including at least one of 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 restrict execution of the application program based on the first pre-condition if the environment type verification performed determines that the first computing environment is not a container virtual computing environment.

[0077]

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

[0078]

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

[0079]

[0084] A nineteenth example is one or more computer-readable storage media including computer-executable instructions that, when executed within a first computing environment, perform steps including receiving a request to verify a type of the first computing environment; 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 indicating the first computing environment is not a container virtual computing environment if at least one of the checking of the encryption infrastructure or the checking of the code integrity infrastructure fails or if the checking of the hypervisor functionality confirms hypervisor functionality in the first computing environment.

[0080]

[0085] A twentieth example is one or more computer-readable storage media of the nineteenth example, where the computer-executable instructions, when executed, perform further steps including at least one of checking whether a predetermined system driver component is present in the first computing environment, checking whether a resource management stack is deactivated in the first computing environment, or checking whether a predetermined firmware variable is set to a predetermined value in firmware of the first computing environment.

[0081]

[0086] As can be seen from the above description, we have presented a mechanism for robustly verifying a virtual environment type and utilizing such robust verification to provide tamper-resistant policy enforcement. In view of the many possible variations of what is described herein, we claim as our invention all such embodiments as may come within the scope of the following claims and equivalents thereto.

Claims

1. A method for a computer to enforce policy restrictions on the execution of application programs in a first computing environment, 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 defining a first pre-condition to be bypassed if the first computing environment is a container virtual computing environment that satisfies a predetermined condition; inspecting a cryptographic infrastructure of the first computing environment; inspecting the code integrity infrastructure of the first computing environment; or Checking hypervisor functionality within the first computing environment. performing an environment type validation including at least one of: restricting the execution of the application program based on the first precondition if the environment type verification determines that the first computing environment is not a container virtual computing environment that satisfies the predetermined condition; A method comprising:

2. The method of claim 1 , wherein the inspecting the cryptographic infrastructure includes verifying proper attestation of an operating system of the first computing environment.

3. The method of claim 2 , wherein the inspecting the cryptographic infrastructure includes verifying proper attestation of a combination of the operating system and the application programs of the first computing environment.

4. The method of claim 2 , wherein the verifying the proper attestation of the operating system of the first computing environment includes communicating with a remote attestation service external to the first computing environment.

5. 3. The method of claim 2, wherein the verifying the proper attestation of the operating system of the first computing environment includes comparing attestation measurements from a first Trusted Platform Module (TPM) in the first computing environment with attestation measurements from a second TPM in the second computing environment.

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

7. The method of claim 1 , wherein the checking the code integrity infrastructure comprises checking a hash of an active code integrity policy file against a security catalog that contains hashes of known good code integrity policy files.

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

9. 2. The method of claim 1, wherein said checking the hypervisor capabilities comprises checking whether hypervisor-compatible processor capabilities are exposed by a central processing unit of the first computing environment.

10. One or more computer-readable storage media comprising computer-executable instructions that, when executed within a first computing environment, perform the steps recited in claim 1.

11. The method of claim 1 , wherein said performing said environment type verification comprises checking for the presence of a predefined system driver component in said first computing environment.

12. 2. 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.

13. 2. 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.

14. 2. The method of claim 1, wherein the first precondition restricts execution of the application program to a hardware machine identifier of a particular computing device.

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. one or more processing devices; and one or more computer-readable storage media containing computer-executable instructions that, when executed by at least a portion of the processing unit, cause the computing device to: obtaining application policy data corresponding to an application program from a second computing environment different from a first computing environment, the application policy data defining a first pre-condition to be bypassed if the first computing environment is a container virtual computing environment that satisfies a predetermined condition; inspecting a cryptographic infrastructure of the first computing environment; inspecting the code integrity infrastructure of the first computing environment; or Checking hypervisor functionality within the first computing environment. performing an environment type validation including at least one of: restricting the execution of the application program based on the first precondition if the environment type verification determines that the first computing environment is not a container virtual computing environment that satisfies the predetermined condition; A computing device that causes

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

18. 17. 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 distinct from the computing device, the second computing device being communicatively coupled to the computing device.

Images