Patent Application
20120047580
The present disclosure generally relates to the field of computing. More particularly, an embodiment of the invention relates to enforcing mandatory security policies for anti-virus scan agents running in a computing system.
Anti-virus (AV) scan agent application programs typically run as operating system (OS) processes. AV scan agents protect themselves from malware/rootkit attacks by employing some the same stealth techniques employed by malware. Recent changes in OS design employ mandatory access control (MAC) labels that tag processes in terms of low, medium, and high integrity classification. Processes at different levels are not allowed to modify/access each other. However, the MAC level semantics are enforced at the OS Ring-0 (kernel privilege). Compromise of Ring-0 implies a compromise of the MAC enforcement mechanism and therefore compromise of AV scan agents running in Ring-3 (user privilege) and Ring-0. Compromise of a virtual memory manager (VMM) (if used) also may result in compromise of the user OS (UOS) MAC mechanism. Use of MAC mechanisms in the OS makes it more difficult for AV scan agents to hide from malware targeting AV scan agent code. Therefore, AV scan agent code is more vulnerable despite improvements in OS security.
The detailed description is provided with reference to the accompanying figures. The use of the same reference numbers in different figures indicates similar or identical items.
In the following description, numerous specific details are set forth in order to provide a thorough understanding of various embodiments. However, various embodiments of the invention may be practiced without the specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the particular embodiments of the invention. Further, various aspects of embodiments of the invention may be performed using various means, such as integrated semiconductor circuits (“hardware”), computer-readable instructions organized into one or more programs stored on a computer readable storage medium (“software”), or some combination of hardware and software. For the purposes of this disclosure reference to “logic” shall mean either hardware, software (including for example micro-code that controls the operations of a processor), firmware, or some combination thereof.
In an embodiment, an AV scan agent application program may be executed in a protected execution environment in a computing system where the AV scan agent may be assigned a MAC privilege that dominates the MAC privileges employed by the user operating system (UOS) (or a virtual machine manager (VMM)). The AV scan agent configures memory pages containing a UOS agent that are protected using the protected execution environment. These memory pages have effective MAC privileges that exceed the highest privilege granted by the UOS (or VMM) hence, compromise of the UOS does not translate to compromise of the AV scan agent in the UOS.
Embodiments of the present invention employ a combination of at least two technologies: protected execution environment microcode and MAC labels applied at a hardware level, separate from operating system MAC abstractions. Execution containers within the protected execution environment provide execution isolation for the AV scan agent runtime operating at a security level that is “higher” than the highest possible OS ring-0 level. This level is enforced by the protected execution environment. Because the protected execution environment respects the MAC security model, the protected execution environment may prevent malicious modification of the AV scan agent runtime while still allowing read access to OS file system objects. Embodiments of the present invention uniformly associate MAC labels, while setting traps on guest OS resources. The methodology of an embodiment cascades label assignment with trap assignment recursively over guest resources and pages until the AV scan agent application and associated data are protected. Malware attempts to modify protected resources may be detected and prevented by the processor of the computing system. Recovery from detected attacks may be administered by a handler agent program running at a higher integrity level from the protected execution environment without violating the system integrity model.
MAC security models protect information by assigning a security label to subjects and objects in the system. One such MAC security model is the Biba model, as disclosed in Biba, K. J. “Integrity Considerations for Secure Computer Systems” MTR-3153, The Mitre Corporation, April 1977. The Biba Integrity Model is a formal state transition system of computer system security policy that describes a set of access control rules designed to ensure data integrity. Data and subjects are grouped into ordered levels of integrity. The model is designed so that subjects may not corrupt data in a level ranked higher than the subject, or be corrupted by data from a lower level than the subject. In general, preservation of data integrity has the goals of preventing data modification by unauthorized parties, preventing unauthorized data modification by authorized parties, and maintaining internal and external consistency (i.e., data reflects the real world). This security model is directed toward data integrity and is characterized by the phrase “no read down, no write up.” The Biba MAC rules may be summarized as: 1) Resources (subjects and objects) are given a Biba integrity label such that a higher level “dominates” a lower level. Subjects that dominate objects or other subjects can “write down” to those resources. 2) Lower level resources can “read up” to higher-level resources.
The Biba model may be applied to a protected execution environment such that devices, memory, direct memory access (DMA) buffers, interrupts and configuration space can be stereotyped with Biba labels such that the Biba access rules can be uniformly applied. Applications running in a protected execution environment where the OS running in an execution container enforces the Biba security model may be assigned virtualization resources corresponding to MAC label constraints. A resource manager component of the protected execution environment may be trusted to enforce privilege semantics across the hardware interface boundary between the execution container (protected memory) and device resources.
In an embodiment, the protected execution environment provides a mechanism to create execution containers in the computing system by partitioning the platform resources (central processing unit (CPU), memory, chipset, flash, etc.) using hardware support for arbitrating accesses to these resources. The intent is that in addition to the container for the user OS (UOS), other independent operating environments could run, typically taking advantage of cycles on cores in a multi-core processor that are unused as the UOS takes cores offline during low activity for power savings. This will have a slight impact on power consumption and performance, but provides an environment for a program execution that could be used for activities out of band (OOB) of the UOS, such as security, manageability, secure commerce, or licensing. With an OOB execution environment, applications running in these containers will be safe from user tampering, malware, and resistant to OS failures. To enable this functionality, several new hardware features may be added to the processor (such as a timer, device filtering, scheduling buffers, page tables, interrupt mapping support, and space in flash memory), an extensive software stack may also be needed (kernel, UOS drivers, kernel drivers, firmware, etc.), and uncore patching support may also be needed. Each execution container will have memory that is separate (including individual extended page tables (EPTs)), their own state, a way to control the time slices needed to execute on the processor, and the potential for dedicated access to hardware devices (enforced through device filtering, local Advanced Programmable Interrupt Controllers (APICs) and interrupt remapping). One example of a protected execution environment and a usage model for improving power efficiency in a computing system is disclosed in Kumar, et al., “Method and Apparatus for Cost and Power Efficient Scalable OS-Independent Services,” filed Dec. 26, 2007, Ser. No. 11/964,439, assigned to the assignee of the present application, and hereby incorporated by reference.
In an embodiment, applications communicate with a protected execution environment resource manager (RM) 110. In an embodiment, the RM may be implemented as micro-code in the processor of the computing system, and create threads to run at different integrity levels. In an embodiment, the RM may run as a separate hyper-thread which is not accessible by Ring-0 or Ring-3 processes. The RM's protected hyper-thread may be instantiated during system boot processing, and may be scheduled but not modified by the OS. Enforcing Biba security policies over applications running in the Execution Container 100 may be achieved by having the RM 110 operate at a higher integrity level than the Execution Container such that any attempt on behalf of the Execution Container to modify or subvert the RM constitutes a violation of the security policy. The RM can establish trust in the Execution Container as part of loading and verifying the OS in the Execution Container. In an embodiment, the Execution Container launch control policy asserts that Execution Container capabilities include the ability to enforce Biba security rules.
A Domain Policy Manager 112 in the RM assigns a range of Biba labels (i.e. privileges) to the Application Policy Manager 102. The Domain Policy Manager keeps track of labels that domains can run at in the processor. The Execution Container enforces Biba rules according to the range supplied. The Application Policy Manager then assigns privileges to Execution Container applications from within that range. This ensures semantic consistency of Biba levels system-wide even though the Execution Container may not have a global view of all computing platform resources. RM 110 provides a plurality of security domains. In an embodiment, a domain is a partition of a physical resource such as memory, disk storage device or network interface device where the partition contains data labeled according to a Biba label applied by a resource manager. In the example shown in
New techniques to protect memory pages in a guest OS that may include an AV scan agent may “harden” those pages against possible attack by malware in the guest OS. By staging such memory page protection configuration and runtime software using protected execution environments, the protected components in the guest OS can operate at an elevated security level whose security policy is consistent with regard to the system wide policy.
Domain A 114: Highest Integrity level (SYS_HI). This domain may be established by the computing system and has the highest integrity level. It consists of the computing hardware (registers, memory), the RM 110 and RM controlled devices, and an Application Policy Manager 102 that can accept a manifest and a region of memory and verify that the region of memory matches the manifest and the validity of the signature based on a root of trust stored within the Application Policy Manager.
Domain B 116: (Domain B <Domain A). Domain B contains the protected execution environment 100 applications that are running to support AV scan agent protection mechanisms. These applications may be verified by the RM 110 along with other programs running in the Execution Container 100. Components include a runtime/light-weight OS (not shown), a Loader 302, a Fault Handler 304, an App Manifest 322 and an App Policy Manager 102 that provides services to the Domain C AV application 300, and is responsible for validating the Domain C AV application 300 and installing the AV application into the Execution Container 100.
Domain C 310: (Domain C <Domain B). This is the domain in which the AV application will execute. The AV application in Domain C has a lower integrity level than the Execution Container 100 applications but is elevated above the rest of the computing system because the integrity of the applications in this domain may be verified by digital signatures and the Application Policy Manager 102 in Domain A. In an embodiment, there may be at least two applications in this domain, a Fault Handler 304 running in Execution Container 100 and AV application 300 running in the in the user (Guest) OS 200 in protected pages. The AV application may have guest OS-specific knowledge but may need to be protected by a Biba mode higher than Domain D.
Domains C-1, C-2, . . . C-n: (Domain C-i<Domain C-j, if i>j. Domain C-2<Domain C-1<Domain C). The applications of Domain C (AV application 300 and Fault Handler 304) will create a series of fine-grained domains below Domain C. They will place memory in the guest OS into these domains as write traps are placed around those memory regions. These domains have a lower integrity level than Domain C in that the value within the memory region is not known to be free of malware, but it is known to have not changed since the trap was set. This contrasts to Domain C where the software included is signed by a manifest showing that the software has not changed since the software was created. It also contrasts with Domain D (discussed below, i.e., the Guest OS environment) in that within Domain D, memory can be changed at any time. In an embodiment, a series of these domains may be used so that the AV application may to distinguish between different levels of integrity in the protected items. For example, the value in the Global Descriptor Table Register (GDTR) of the processor can be known with high assurance since the GDTR is stored in Domain A hardware, while the value of a linear to physical memory mapping may depend on values stored in previously established domains C-i. Therefore, the value cannot be established with the same integrity level as domain C-i and must therefore have its own domain C-(i+1).
Domain D 312: (Domain D<Domain C-n<Domain-C). In an embodiment, Domain D may be a global domain assigned to all unprotected resources 306 accessible by Guest Applications 308. This includes Guest Ring-0 applications and kernel. It also includes all Ring-3 application software. Guest OS storage resources are allocated from a partition of a physical storage device where the partition 320 consists of tracks t0-tn in Domain D with label (X4:Y).
An AV application (300) contained in protected guest OS memory pages 303 has memory page traps that when de-referenced will cause the Fault Handler 304 to consult a Biba MAC policy whereby the default guest OS Biba label may be overridden with a label that dominates the default label including Domain C. These memory pages are generally represented by 318.
Physical resources consumed by the Execution Container 100 are allocated from pools of memory and storage resources 314 and 316. Execution Container 100 has exclusive access to these resources enforced by label separation and by partitioning. The application manifest 322 may be stored in execution container storage 314 having a label assignment consistent with Domain A 114.
At block 412, once the Loader verifies the integrity of the AV Application image and has set up the conditions so that other Guest OS applications (or even Guest OS kernel code) can't modify the image without triggering page traps (detectable by the Fault Handler), the Loader promotes the AV Application to Domain C. In an embodiment, now that the Fault Handler 304 and the AV Application 300 are in the same domain, they can communicate via the processor hardware-implemented SendMessage command. At block 414, the Fault Handler verifies that every message received from the AV Application originates from within the memory region defined and locked above. Both code segments and data segments are included in Domain C. The code segments for the message are locked and placed into Domain C with the code segment of the Fault Handler, and the AV Application may be permitted to have access to those pages.
At this point, Domain C has been established, consisting of the Fault Handler running in the Execution Container 100 and the AV Application 300 running in the Guest OS 200. Both of these components have been verified by manifests and memory traps retain the integrity of the software images. The AV Application may now run to scan for malware.
In an embodiment, Domain C-1502 may be established first and consists of all kernel elements that are in registers 512 to be protected. Domain C-2504 may then be established by using the elements of Domain C-1 to obtain the correct addresses. Domain C-1 will contain the registers 514 of the system that must be monitored for unauthorized changes (SYSENTER MSR, CR3, etc.) and Domain C-2 will consist of the address translation page tables (PTs) and page fault handlers (PFHs) 514. Once these domains are established, further C-i domains may be created (such as Domain C-N 506) that rely on the integrity of Domains C-1 and C-2. Further domain n's may contain device drivers 516 and applications whose pages are protected using page fault traps 9 such as AV Scanner 518).
So far, the AV Application has been presented as a single entity within the protected execution environment system, but in an embodiment the AV Application may consist of a plurality of parts and those parts may reside in different domains within the system. For example, in an embodiment, the AV Application may consist of two components: an AV Configuration (Config) Application 510 that sets traps on Guest OS objects, and an AV Scanner Application 518 that reads unprotected pages and files looking for malware infections. With this split model, the AV Configuration component may be elevated to Domain C 500, but the AV Scanner 518 may remain at a lower domain. In one embodiment, the AV Scanner may be placed into the lowest of the sub-C domains, Domain C-n 506, and the AV Scanner depends on the integrity of all of the higher domains, but it is isolated from attack from Domain D 306 malware because any write into the AV Scanner by Domain D malware will generate a Biba fault.
When Biba is used in the “ring” mode, the AV Scanner 518 is permitted to read Domain D objects while operating at Domain C-n 506. If an infected object is detected, the AV Scanner may spawn a sub-process at Domain D to delete or quarantine the affected object. The AV Scanner is never threatened by the offending malware because the AV Scanner can't run at Domain C-n. The AV Scanner may assign a new label to the hard disk drive (HDD) or solid state drive (SSD) 320 or memory pages that successfully pass AV scans. The new label is a domain greater than D and less than Domain C-n. The Resource Manager (RM) 110 verifies that the AV Scanner is trusted (e.g. page trap protections are in place) to perform the label change on scanned objects by verifying that the label change request originated from AV Scanner pages while page traps were activated and the AV Scanner label was at Domain C-n or higher.
When Biba is used in the “low-watermark” mode, the AV Scanner automatically switches the label to Domain D to perform the scan. If infected objects are detected, the scanner may remove or quarantine immediately, but may not change the label of clean objects. The AV Scanner may however change its label to Domain C-n as described, by asserting that the AV Scanner meets the requirements of the Domain C-n which is that traps have been placed on all critical code and data regions and that these traps have been in place while it was operating in Domain D. AV Scanner 518 is protected from Domain D malware due to resource traps only; there is no Biba restriction imposed. When Biba is used in the “strict” mode, the AV Scanner must request a label change to Domain D prior to performing object scans and to quarantine. Then, when completed, the AV Scanner must request a label change back to Domain C-n to re-label clean objects.
In an embodiment, placing the AV Scanner into Domain C-n may be accomplished as follows. The AV Configuration Application 510 determines the locations within the AV Scanner Application 518 that need protection. The AV Configuration Application signals the Fault Handler 304 to place traps on the appropriate AV Scanner Applications locations. The Fault Handler sets the appropriate trap, and places the locations into Domain C-n 506, since Domain C-n depends on all other sub-C domains.
For example, if an application program such as App L1104 in the Execution Container 100 is assigned a privilege Domain A 114 and an application such as App G11006 running in a Guest VM 11008 is assigned a privilege Domain A 114, both applications will operate using like privileges. Furthermore, if App L1104 downgraded information for consumption by App L2106, then App L2 could communicate that information to App G21010 running in Guest VM 21012 in the Guest OS 200 environment without violating the system wide security policy. Similarly, the App G21010 could downgrade information and share it with App G31014 running in Guest VM 31016 and having Domain C 310, and/or App L3108 without violating a security policy.
Having a commonly understood security policy model allows flexible interaction between system components, while still ensuring that the security objectives of the system are maintained. If the Guest OS environment is determined to have a maximum level of trustworthiness that is lower than the protected execution environment, then the RM would reserve privilege levels at the top of the range that are not assigned to the VMM environment. If the VMM became corrupted and assigned privileges that are outside of its assigned range, the RM can perform a range check on memory and device accesses to detect cheating. If the VMM environment was launched using secure launch technology (e.g., trusted execution technology (TXT)), then the RM may trust the VMM to enforce range checks on VM pages. This may have beneficial performance implications.
Use of a protected execution environment may be combined with virtualization while maintaining Biba security policy consistency system wide.
In the case of a guest OS in a VM 1008 that is not Biba aware, application 1006 pages 1018 can be registered to generate VMExit traps by a VMM 1002 such that a VM manifest 1020 contains a policy for constructing VMExit traps and a Biba label assignment that overrides the default label assigned by a Biba aware VMM 1002.
In the case of a guest OS in a Biba-aware VMs 1012 & 1016, the VM allocates memory pages according to the label assignments made by the VM.
Embodiments of the present invention provide a protected execution environment by implementing a mandatory integrity policy enforced by microcode of the processor. The integrity rules are formally specified (e.g. Biba) making validation and security evaluation simpler. Enforcement in processor hardware (microcode) ensures that a compromised OS cannot easily undermine the security policy. Embodiments of the present invention may be applied in both virtualized and non-virtualized environments and in any operating system environment.
More particularly, the computing system 1200 may include one or more central processing unit(s) (CPUs) 1202 or processors that communicate via an interconnection network (or bus) 1204. Hence, various operations discussed herein may be performed by a processor in some embodiments. Moreover, the processors 1202 may include a general purpose processor, a network processor (that processes data communicated over a computer network 1203, or other types of a processor (including a reduced instruction set computer (RISC) processor or a complex instruction set computer (CISC)). Moreover, the processors 1202 may have a single or multiple core design. The processors 1202 with a multiple core design may integrate different types of processor cores on the same integrated circuit (IC) die. Also, the processors 1202 with a multiple core design may be implemented as symmetrical or asymmetrical multiprocessors. Moreover, the operations discussed with reference to
A chipset 1206 may also communicate with the interconnection network 1204. The chipset 1206 may include a graphics and memory control hub (GMCH) 1208. The GMCH 1208 may include a memory controller 1210 that communicates with a memory 1212. The memory 1212 may store data, including sequences of instructions that are executed by the processor 1202, or any other device included in the computing system 1200. Furthermore, memory 1212 may store one or more of the programs or algorithms discussed herein such as Execution Container 100, Guest OS 200, a compiler 1213, instructions corresponding to executables, mappings, etc. Same or at least a portion of this data (including instructions) may be stored in disk drive 1228 and/or one or more caches within processors 1202. In one embodiment of the invention, the memory 1212 may include one or more volatile storage (or memory) devices such as random access memory (RAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), static RAM (SRAM), or other types of storage devices. Nonvolatile memory may also be utilized such as a hard disk. Additional devices may communicate via the interconnection network 1204, such as multiple processors and/or multiple system memories.
The GMCH 1208 may also include a graphics interface 1214 that communicates with a display 1216. In one embodiment of the invention, the graphics interface 1214 may communicate with the display 1216 via an accelerated graphics port (AGP). In an embodiment of the invention, the display 1216 may be a flat panel display that communicates with the graphics interface 1214 through, for example, a signal converter that translates a digital representation of an image stored in a storage device such as video memory or system memory into display signals that are interpreted and displayed by the display 1216. The display signals produced by the interface 1214 may pass through various control devices before being interpreted by and subsequently displayed on the display 1216.
A hub interface 1218 may allow the GMCH 1208 and an input/output (I/O) control hub (ICH) 1220 to communicate. The ICH 1220 may provide an interface to I/O devices that communicate with the computing system 1200. The ICH 1220 may communicate with a bus 1222 through a peripheral bridge (or controller) 1224, such as a peripheral component interconnect (PCI) bridge, a universal serial bus (USB) controller, or other types of peripheral bridges or controllers. The bridge 1224 may provide a data path between the processor 1202 and peripheral devices. Other types of topologies may be utilized. Also, multiple buses may communicate with the ICH 1220, e.g., through multiple bridges or controllers. Moreover, other peripherals in communication with the ICH 1220 may include, in various embodiments of the invention, integrated drive electronics (IDE) or small computer system interface (SCSI) hard drive(s), USB port(s), a keyboard, a mouse, parallel port(s), serial port(s), floppy disk drive(s), digital output support (e.g., digital video interface (DVI)), or other devices.
The bus 1222 may communicate with an audio device 1226, one or more disk drive(s) 1228, and a network interface device 1230, which may be in communication with the computer network 1203. In an embodiment, the device 1230 may be a network interface controller (NIC) capable of wired or wireless communication. Other devices may communicate via the bus 1222. Also, various components (such as the network interface device 1230) may communicate with the GMCH 1208 in some embodiments of the invention. In addition, the processor 1202, the GMCH 1208, and/or the graphics interface 1214 may be combined to form a single chip.
Furthermore, the computing system 1200 may include volatile and/or nonvolatile memory (or storage). For example, nonvolatile memory may include one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically EPROM (EEPROM), a disk drive (e.g., 1228), a floppy disk, a compact disk ROM (CD-ROM), a digital versatile disk (DVD), flash memory, a magneto-optical disk, or other types of nonvolatile machine-readable media that are capable of storing electronic data (e.g., including instructions).
In an embodiment, components of the system 1200 may be arranged in a point-to-point (PtP) configuration such as discussed with reference to
More specifically,
As illustrated in
The processors 1302 and 1304 may be any suitable processor such as those discussed with reference to the processors 1302 of
At least one embodiment of the invention may be provided by utilizing the processors 1302 and 1304. For example, the processors 1302 and/or 1304 may perform one or more of the operations of
The chipset 1320 may be coupled to a bus 1340 using a PtP interface circuit 1341. The bus 1340 may have one or more devices coupled to it, such as a bus bridge 1342 and I/O devices 1343. Via a bus 1344, the bus bridge 1343 may be coupled to other devices such as a keyboard/mouse 1345, the network interface device 1330 discussed with reference to
In various embodiments of the invention, the operations discussed herein, e.g., with reference to
Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least an implementation. The appearances of the phrase “in one embodiment” in various places in the specification may or may not be all referring to the same embodiment.
Also, in the description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. In some embodiments of the invention, “connected” may be used to indicate that two or more elements are in direct physical or electrical contact with each other. “Coupled” may mean that two or more elements are in direct physical or electrical contact. However, “coupled” may also mean that two or more elements may not be in direct contact with each other, but may still cooperate or interact with each other.
Additionally, such computer-readable media may be downloaded as a computer program product, wherein the program may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals, via a communication link (e.g., a bus, a modem, or a network connection).
Thus, although embodiments of the invention have been described in language specific to structural features and/or methodological acts, it is to be understood that claimed subject matter may not be limited to the specific features or acts described. Rather, the specific features and acts are disclosed as sample forms of implementing the claimed subject matter.
