Patent Application
20090222880
The present invention is generally directed to computer security. More particularly, it is directed to implementing access control in a computer, and applications thereof.
A virtual machine (VM) is a software implementation that executes on a host computer. Virtualization (e.g., the use of one or more virtual machines) is being widely implemented, but contains inherent weaknesses. Many vulnerabilities have been discovered and exploited that allow an attacker to gain unexpected access to the host operating system from a virtual machine. To reduce these vulnerabilities, a security mechanism—commonly referred to as access control—has been used. There are two main types of access control: discretionary access control (DAC) and mandatory access control (MAC).
Under DAC, system resources have security attributes (e.g., passwords and/or access control lists) associated with them. Access to system resources is controlled based on these security attributes, which are used to protect the system resources (e.g., files) owned by one user from unauthorized access by other users. A weakness associated with DAC is that the security attributes assigned to each system resource are specified by the resource owner and can be modified or removed at will. During a computer attack, an attacker may be able to alter DAC security attributes and thereby gain access to any or all system resources. Not surprisingly, existing virtualization systems that rely on DAC have demonstrated security vulnerabilities.
Under MAC, access to system resources is controlled by security attributes that cannot be modified or removed during normal operation. In this way, MAC offers a greater level of security compared to DAC.
An example of MAC is type enforcement. Type enforcement is implemented, for example, in security-enhanced Linux (SELinux). In type enforcement, both applications and system resources are assigned a type. Access for a type enforcement system such as SELinux is defined by a collection of rules contained in a file called a policy. A policy file is loaded into the operating system kernel of a machine during the boot process. The type attributes assigned to applications and system resources cannot be changed during normal operation.
Although MAC such as type enforcement provides a greater level of security than DAC, configuring the policy is difficult. The policy language of SELinux, for example, includes many complexities that must be well understood by a system developer before the system developer can create an effective security-enhanced system. Many system developers, however, do not have such an understanding. Therefore, many system developers cannot take advantage of the enhanced security offered by MAC to provide secure and configurable resource sharing in virtualization systems.
What are needed are new techniques and tools for implementing access control that overcome the deficiencies noted above.
The present invention provides systems and methods for configurable access control for virtualization, and applications thereof. In an embodiment, the present invention provides a system that includes a container, a security policy, and a loader. The container is configured to contain one or more virtual machines. The security policy controls access to the container. The loader loads a first virtual machine image into the container based on the access granted by the security policy.
Further features and advantages of the invention, as well as the structure and operation of various embodiments of the invention, are described in detail below with reference to the accompanying drawings. It is noted that the invention is not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.
The accompanying drawings, which are incorporated herein and form part of the specification, illustrate the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the relevant art(s) to make and use the invention.
The features and advantages of the present invention will become more apparent from the detailed description set forth below when read in conjunction with the drawings. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.
The present invention provides systems and methods to provide configurable access control security for virtualization, and applications thereof. In the detailed description that follows, references to “one embodiment”, “an embodiment”, “an example embodiment”, etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
Virtualization may be categorized as Type I or Type II. Type I virtualization is hardware-based hypervisor virtualization (such as Xen founded by XenSource, Inc. of Cambridge, Mass.). Type II is para-virtualization that runs on top of the kernel (such as VMware provided by VMware, Inc. of Palo Alto, Calif.). Although example details set forth herein may only apply to one of these types of virtualization, this is for illustrative purposes only, and not limitation. It is to be appreciated that the systems and methods set forth herein can be applied to both Type I and Type II virtualization, as would be apparent to a person skilled in the relevant art(s).
A. Overview
Containers 112 are each configured to run one or more virtual machines. That is, containers 112 are security boundaries that may contain one or more virtual machines. For example, a loader 136A may retrieve one or more virtual machine images from a local source (namely, VM Sources A 140A), and load the one or more virtual machine images into first container 112A to run one or more virtual machines. Similarly, a loader 136B may retrieve one or more virtual machine images from a local source (namely, VM Sources B 140B) or a remote source (namely, Remote VM Sources 140C), and load the one or more virtual machine images into second container 112B to run one or more virtual machines.
Security policy 104 provides security for machine 102 based on security configuration information 116. For example, security policy 104 can control whether a virtual machine running in first container 112A or second container 112B is able to access the system resources of machine 102. Security policy 104 may be implemented, for example, as a MAC security policy in SELinux. SELinux is described in more detail, for example, in Bill McCarty, SELinux: NSA's Open Source Security Enhanced Linux (Andy Oram ed., 2005), and Frank Mayer et al., SELinux by Example (Prentice Hall, 2007), both of which are incorporated by reference herein.
B. Configurability of Security Policy
Security policy 104 may be easily configured and/or reconfigured by a system administrator. As would be known to persons skilled in the relevant art(s), a typical security policy can include upwards of 50,000 lines of source code. Reconfiguring such a security policy is difficult and time-consuming, requiring a detailed understanding of the source code and security policy. In contrast, an embodiment of the present invention provides a simplified manner for configuring and/or reconfiguring security policy 104.
According to this embodiment, the system administrator provides security configuration information 116 to system generation module 160 via display 130. For example, the system administrator may interact with a graphical user interface (GUI) provided on display 130 to provide security configuration information 116. Security configuration information 116 specifies the access profile for virtual machines running on machine 102. Based on security configuration information 116, system generation module 160 configures and/or reconfigures security policy 104.
Security configuration information 116 may specify one or more containers for machine 102, and the access rights to be granted to those containers. For example,
C. Security Policy Controls Access
The access profile of each container 112 is controlled by security policy 104. A set forth above, a system administrator can configure security policy 104 based on security configuration information 116. Thus, the system administrator can configure the access profile of each container 112 to provide for secure and flexible resource sharing between virtual machines of first container 112A and second container 112B. The access profile may include, for example, (1) the system resources that each container 112 may access, (2) the virtual machine images that may be loaded into each container 112, (3) the users that may access each container 112 and/or virtual machine images, and (4) other types of access controls and checks.
Security policy 104 may control, for example, the access that each container 112 has to system resources. In such an example, security policy 104 may be implemented as a MAC security policy. Such system resources may include, but are not limited to, a first network card 106A, a second network card 106B, a shared folder 114, and an external device interface 120 connected to an external device 124 (such as universal serial bus (USB) drives or removable storage devices (e.g., CD/DVD, floppy), etc.). As illustrated in
Host OS 180 receives the guest request 202 from the first guest OS, and translates it into a host request 204. Host request 204 is a request for access to one or more specific resources included in system resources 250.
Host OS 180 includes a process tracker 206 that labels each process running on machine 102. Referring to process tracker 206 of the example in
Security policy 104 controls whether the first guest OS may access system resources 250 based on the access rights granted to processes with label C1. Security policy 104 includes, for example, a security enforcer 210, definitions 220, labeling statements 240, and access rules 230. Definitions 220 define types used by security policy 104. Labeling statements 240 label each system resource with a label. Access rules 230 set forth which system resources each type may access based on the label associated with each system resource and each type. Security enforcer 210 enforces access rules 230 based on definitions 220 and labeling statements 240.
For the example of
Security policy 104 may also control, for example, the virtual machine images that may be loaded into containers 112, thereby controlling the virtual machines that may run in containers 112. In one embodiment, a MAC security policy controls the virtual machine images that may be loaded into container 112. In another embodiment, a DAC security policy controls the virtual machine images that may be loaded into container 112.
As is well-known in the art, a virtual machine image contains (1) a snapshot of a program or OS that a virtual machine can load and execute, (2) a file defining the resources that the program or OS can access, and (3) other files for housekeeping and administrative purposes. The virtual machine images loaded into containers 112 can be loaded from a local source or from a remote source.
For example,
In an embodiment, virtual machine images are reconfigured to reflect the access profile of a container. If security policy 104 has been reconfigured to grant (or deny) a container access to a system resource, for example, then the virtual machine image is automatically reconfigured to reflect the change in access rights given to that container. In an embodiment, the virtual machines can be automatically reconfigured when added to a container at run time.
For example,
Access rights granted to a container 112 in which virtual machine image 310 is to be loaded may not correspond to the access specified in the VMX file of that virtual machine image. In such a case, loader 136 can reconfigure the VMX file of virtual machine image 310 to provide a reconfigured VMX file in reconfigured virtual machine image 330, wherein the reconfigured VMX file corresponds with the access rights granted to container 112. In an embodiment, loader 136 does this by comparing the VMX file of virtual machine image 310 to the access rights granted to container 112 and making any required adjustments to form the reconfigured VMX file in reconfigured virtual machine image 330.
For example, if virtual machine image 310 is to be loaded into first container 112A, the virtual machine would only be allowed to access one network card (namely, first network card 106A) because first container 112A is only allowed to access one network card. In contrast, the VMX file may indicate that the virtual machine running the guest OS is able to access two different network cards. In this example, loader 136 reconfigures the VMX file of virtual machine image 310 to indicate that this virtual machine is only allowed to access one network card. The reconfigured VMX file is included in reconfigured virtual machine image 330 provided by loader 136.
Provided below in Table 1 is an example reconfigured VMX file. Lines that have been deleted are shown in strikethrough. Lines that have been added are shown in bold, italics, and underline. For illustrative purposes, line numbers have been added to the example VMX file of Table 1.
25
26
29
As illustrated in
Various changes to the VMX file will occur when the network cards are enabled or disabled. The extent of the changes will depend on the original configuration. For example, box 420 of
Various changes will occur when access to shared folders is added or removed. For example, box 440 of
Various changes will occur when access to the Clipboard is enabled or disabled. For example, box 450 of
Box 450 further illustrates that no sound adapters have been selected. Lines 32 and 33 of the example VMX file of Table 1 illustrate what happens when access to the sound adaptor is removed.
Box 450 further illustrates that a USB controller has been selected. Lines 38 and 39 of the example VMX file of Table 1 illustrate changes to the VMX file as a result of allowing access to the USB devices.
Security policy 104 may also be configured by an administrator to restrict access to containers 112 on a per-user basis. As is well-known, machine 102 may include an authentication process, whereby one of the users included in User List 150 may log into machine 102—e.g., by typing in a username and password. After authenticating and validating the username and password, security policy 104 can restrict access to containers 112 based on the user logged into machine 102. In addition, virtual machines running in containers 112 may also be restricted to particular users.
In an embodiment, system 100 is configured as a thin client, wherein all virtual machine images are dynamically retrieved over network 110 based on the user logged into system 100. In this embodiment, a user would log into system 100 using well-known means. Based on security configuration information 116 provided by a system administrator and configured into security policy 104, the user is granted access to one or more containers. When the user is authenticated to system 100, the virtual machine image(s) appropriate for the one or more containers are loaded from remote VM source 140C over network 110. Different users may have different virtual machine images for the same container. When the user logs out, the virtual machine image(s) for that user are deleted.
Security policy 104 may also control other types of access or operations as would be apparent to a person skilled in the relevant art(s). For example, security policy 104 can be configured to restrict or to allow cut and paste operations between a first virtual machine of first container 112A and a second virtual machine of second container 112B.
Additionally, hardware verification/validation may be performed when the system is installed to validate that the hardware on the system matches the hardware expected by the security configuration. For example, the number of network cards on machine 102 can be compared to the network cards expected by the administrator, and/or it can be verified whether the network cards are connected properly. Based on this comparison and/or verification process, a notification can be presented if the number of network cards does not match the expected number of cards and/or if the network cards are not connected properly. Furthermore, the network card connections can be validated by asking the user to verify the card is connected to the proper network. This can be done manually (for example, by flashing the lights on a card and asking the user to verify that the network cables are connected to the correct card), or the check can be automated by attempting to access some known resource on each network to verify which card is utilized (i.e., ping a known server on each network).
As mentioned above, security policy 104 can be modified based on security configuration information 116 provided to system generation module 160. In an embodiment, an installation package is generated based on security configuration information 116. This installation package can then be deployed to a local machine or a remote machine. In another embodiment, security policy 104 running on a local machine is reconfigured based on security configuration information 116.
Security configuration information 116 is provided to system generation module 160. As illustrated in
The system administrator may provide security configuration information 116 by interacting with a GUI on display 130. For example,
It is to be appreciated that GUI screenshot 610 is presented for illustrative purposes only, and not limitation. For example, it is to be appreciated that the system administrator can edit the access profile of other container(s) defined on the system in a similar manner to that illustrated in GUI screenshot 210. In addition, it is to be appreciated that security parameters other than the ones illustrated in GUI screenshot 610 can be modified in a similar manner to that illustrated without deviating from the spirit and scope of the present invention.
B. Reconfiguration of a Security Policy
Security configuration information 116 is provided to system generation module 160, along with security policy 104. As illustrated in
System generation module 160 can reconfigure definitions 220, labeling statements 240, and/or access rules 230 of security policy 104 as indicated in reconfigured security policy 804. Reconfigured security policy 804 includes reconfigured definitions 820, reconfigured labeling statements 840, and reconfigured access rules 830.
It is to be appreciated that these changes are presented for illustrative purposes only, and not limitation. Other types of changes to the security configuration information can be provided, and thereby other changes to the security policy can be made, without deviating from the spirit and scope of the present invention, as would be apparent to a person skilled in the relevant art(s).
Various systems and methods for implementing configurable access control security for virtualization in a computer, and applications thereof, have been described in detail herein. It is to be appreciated that the Detailed Description section, and not the Summary and Abstract sections, is intended to be used to interpret the claims. The Summary and Abstract sections may set forth one or more but not all exemplary embodiments of the present invention as contemplated by the inventor(s), and thus, are not intended to limit the present invention and the appended claims in any way. Furthermore, although aspects of the present invention have been described with reference to SELinux, the invention is not limited to the Linux operating system or SELinux. Based on the description contained herein, a person skilled in the relevant art(s) will appreciate that embodiments of the present invention can be implemented with regard to other operating systems.
