Abstract: A host operating system running on a computing device monitors network communications for the computing device to identify network resources that are requested by the computing device. The host operating system compares requested network resources against security policies to determine if the requested network resources are trusted. When an untrusted network resource is identified, the host operating system accesses the untrusted network resource within a container that is isolated from the host operating system kernel using techniques discussed herein. By restricting access to untrusted network resources to isolated containers, the host operating system is protected from even kernel-level attacks or infections that may result from an untrusted network resource.

Abstract: Facilities are provided to secure guest runtime environments (GREs). Security policy specifications may be associated with GREs. A GRE's security policy may be specific to the GRE and may also include security policy inherited from higher levels such as a host operating environment. The security policy of a GRE specifies restrictions and/or permissions for activities that may be performed within the scope of execution of the GRE. A GRE's security policy may limit what the GRE's guest software may do within the GRE. Restrictions/permissions may be applied to objects such as files, configuration data, and the like. Security specifications may be applied to execution initiated within a GRE. A GRE's security specification may restrict/permit executable objects from loading and executing within the GRE. The executability or accessibility of objects may be conditioned on factors such as the health/integrity of the GRE, the host system, requested files, and others.

Abstract: Different containers are used for different usage sessions, a container referring to a virtualization layer for a computing device and used for isolation as well as hardware resource partitioning. A usage session refers to the time span beginning when one or more users begin to use the computing device, and ending when the one or more users cease using the computing device. During a particular usage session that uses a container, all interaction with the computing device is maintained in the container. The container is deleted when the usage session ends, leaving no data from the usage session behind after the usage session ends. Additionally, some usage sessions need not be run in containers, so data generated during such usage sessions is maintained after usage session ends. The host operating system automatically determines which usage sessions to run in containers and which usage sessions to run separate from any containers.

Abstract: Facilities are provided to secure guest runtime environments (GREs). Security policy specifications may be associated with GREs. A GRE's security policy may be specific to the GRE and may also include security policy inherited from higher levels such as a host operating environment. The security policy of a GRE specifies restrictions and/or permissions for activities that may be performed within the scope of execution of the GRE. A GRE's security policy may limit what the GRE's guest software may do within the GRE. Restrictions/permissions may be applied to objects such as files, configuration data, and the like. Security specifications may be applied to execution initiated within a GRE. A GRE's security specification may restrict/permit executable objects from loading and executing within the GRE. The executability or accessibility of objects may be conditioned on factors such as the health/integrity of the GRE, the host system, requested files, and others.

Abstract: Different containers are used for different usage sessions, a container referring to a virtualization layer for a computing device and used for isolation as well as hardware resource partitioning. A usage session refers to the time span beginning when one or more users begin to use the computing device, and ending when the one or more users cease using the computing device. During a particular usage session that uses a container, all interaction with the computing device is maintained in the container. The container is deleted when the usage session ends, leaving no data from the usage session behind after the usage session ends. Additionally, some usage sessions need not be run in containers, so data generated during such usage sessions is maintained after usage session ends. The host operating system automatically determines which usage sessions to run in containers and which usage sessions to run separate from any containers.

Abstract: Techniques for implementing operating system layering are described herein. In one example, a method includes managing one or more container temporary storage spaces and one or more container runtime environments. Furthermore, the method includes loading, one or more drivers to provide compatibility between a container operating system and a host operating system, the one or more drivers comprising application program interface (API) compatibility libraries to enable API compatibility between the container operating system and the host operating system; metadata arbitration logic to enable compatibility between the container operating system and the host operating system by modifying container operating system references; and file arbitration logic to modify operating system file locations accessed by the container operating system and the host operating system.

Abstract: A host operating system running on a computing device monitors network communications for the computing device to identify network resources that are requested by the computing device. The host operating system compares requested network resources against security policies to determine if the requested network resources are trusted. When an untrusted network resource is identified, the host operating system accesses the untrusted network resource within a container that is isolated from the host operating system kernel using techniques discussed herein. By restricting access to untrusted network resources to isolated containers, the host operating system is protected from even kernel-level attacks or infections that may result from an untrusted network resource.

Abstract: Techniques described herein can dynamically generate images. In one example, a method includes detecting a request to generate a container image based on a policy file and identifying a host image from a host operating system. The method can also include generating the container image based on the host image and the policy file, the policy file indicating a first set of files to be copied from the host image to the container image, a set of reparse points corresponding to a second set of files not to be copied from the host image to the container image, and a third set of files to be loaded into the container image from a remote source.

Abstract: Configuring a node. A method includes at a first configuration layer, modifying configuration settings. The method further includes propagating the modified configuration settings to one or more other configuration layers implemented at the first configuration layer to configure a node.

Abstract: Techniques for implementing operating system layering are described herein. In one example, a method includes managing one or more container temporary storage spaces and one or more container runtime environments. Furthermore, the method includes loading, one or more drivers to provide compatibility between a container operating system and a host operating system, the one or more drivers comprising application program interface (API) compatibility libraries to enable API compatibility between the container operating system and the host operating system; metadata arbitration logic to enable compatibility between the container operating system and the host operating system by modifying container operating system references; and file arbitration logic to modify operating system file locations accessed by the container operating system and the host operating system.

Abstract: A containment mechanism provides for the grouping and isolation of multiple processes running on a single computer using a single instance of the operating system. A system is divided into one or more side-by-side and/or nested isolated environments enabling the partitioning and controlled sharing of resources by creating different views of hierarchical name spaces via virtual hierarchies.

Abstract: Methods, systems, and computer-readable media for deploying an update to nodes propagated throughout a data center are provided. Launching new upgrade to hosting environment residing on the nodes typically invokes a mechanism (e.g., fabric controller) to form a group of nodes that are independent of one another with respect to upgrade domains, which are assigned to tenants (e.g., program components of service applications running within the data center) presently hosted by the nodes. The constraints of the update domains are articulated by service level agreements established for the service applications, respectively. Forming the group involves identifying independent nodes for membership, where no two members of the group host analogous tenants (belonging to a common service application) that are assigned to distinct update domains. However, it is acceptable to join to the group those nodes hosting analogous tenants that are each assigned to the same update domain.

Abstract: Embodiments described herein are directed to updating the various software associated with a distributed application in a piecemeal fashion. All instances of the software are analyzed and separated into different portions, called “roles.” Each instance of a role is strategically assigned to an update domain based on the structural information included in the service model of the distributed application. The distributed application is upgraded one update at a time by selecting an update or host update domain, bringing the roles assigned thereto offline, updating the offline roles, bringing the roles back online, and repeating for other update or host update domains.

Abstract: A containment mechanism provides for the grouping and isolation of multiple processes running on a single computer using a single instance of the operating system. A system environment is divided into one or more side-by-side and/or nested spaces enabling the partitioning and controlled sharing of resources by creating different views of hierarchical name spaces via virtual hierarchies. A set of declarative rules specifying access capabilities may specify a set of filter drivers to be used to limit access to nodes in the hierarchical name space. The rules may be applied in sequence to construct a new name space from an existing one, or to add to an existing hierarchy. Filter drivers are used to limit access to nodes in the new name space or new portion of the name space. Access to nodes can be limited (read-only access instead of read/write) or nodes can be hidden altogether. Rules may be specified in a declarative language such as XML.

Abstract: Methods, systems, and computer-readable media for deploying an update to nodes propagated throughout a data center are provided. Launching new upgrade to hosting environment residing on the nodes typically invokes a mechanism (e.g., fabric controller) to form a group of nodes that are independent of one another with respect to upgrade domains, which are assigned to tenants (e.g., program components of service applications running within the data center) presently hosted by the nodes. The constraints of the update domains are articulated by service level agreements established for the service applications, respectively. Forming the group involves identifying independent nodes for membership, where no two members of the group host analogous tenants (belonging to a common service application) that are assigned to distinct update domains. However, it is acceptable to join to the group those nodes hosting analogous tenants that are each assigned to the same update domain.

Abstract: A containment mechanism provides for the grouping and isolation of multiple processes running on a single computer using a single instance of the operating system. A system is divided into one or more side-by-side and/or nested spaces enabling the partitioning and controlled sharing of resources by creating different views of hierarchical name spaces by creating a new branch of an existing global system name space or by linking the sub-root level nodes of a new hierarchy to a subset of nodes in an existing global system name space.

Abstract: A silo-specific view of the file system is provided to processes running in the silo. Processes can access a file only by uttering the silo-relative name. To determine if access to a file identified by a file ID should be permitted, a list of physical names of the file identified by the file ID is constructed. If a silo-relative name that translates to a name in the list can be uttered, the file is opened and the file ID for the opened file is retrieved. If the file IDs match, the silo-relative name is used to open the file. If a process running within a silo requests a list of names for a file that has been opened using a file ID, results returned are filtered so that only names visible in the silo are returned, thus restricting the process' access to files to those files within its hierarchical namespace.

Abstract: An element of a file system is virtually deleted by creating a deletion marker for the element. Two or more separate physical file system directories are presented as one merged (virtual) file system directory to a process running in a silo. The operating system provides the merged view of the file system directories by monitoring file system requests made by processes in silos on a computer or computer system and filtering out those elements associated with deletion markers. Special processing is invoked in response to detecting certain types of file system access requests, including: enumeration, open, create, rename or delete.

Abstract: Embodiments described herein are directed to updating the various software associated with a distributed application in a piecemeal fashion. All instances of the software are analyzed and separated into different portions, called “roles.” Each instance of a role is strategically assigned to an update domain based on the structural information included in the service model of the distributed application. The distributed application is upgraded one update at a time by selecting an update or host update domain, bringing the roles assigned thereto offline, updating the offline roles, bringing the roles back online, and repeating for other update or host update domains.

Abstract: In some techniques for resource recovery, a region of code can be considered untrusted. To catch problems in the untrusted region, entry points are wrapped with exception logic for processing exceptions raised within the untrusted region. Until an exception has been raised within the untrusted region, instructions corresponding to the entry points may be executed. However, once an exception has been raised within the untrusted region, further access to the untrusted code is prevented. A time element may be recorded for indicating execution time within an untrusted display hardware driver. Once a threshold execution time is reached, indicating a graphics processor hang, driver execution stops and an exception raised. When execution continues, the exception is processed based on the exception logic. Updating the display hardware then occurs without using the graphics processor. The display hardware may notify a user that the graphic processor is not functioning.