Covert Flow Confinement For Vm Coalition
1 like788 views
The document proposes a Covert Flows Confinement mechanism (CFCC) for virtual machine (VM) coalitions in cloud computing environments. CFCC uses a prioritized Chinese Wall model to control covert information flows between VMs based on assigned labels, allowing flows between similarly-labeled VMs but disallowing flows between VMs from different conflict of interest sets. The architecture features distributed mandatory access control for all VMs and centralized information exchange. Experiments show the performance overhead of CFCC is acceptable. Future work will add application-level flow control for VM coalitions.
![Background(Problem Statement) To address the above questions, we propose a covert flows confinement mechanism for VM coalitions (CFCC) in VM-based cloud computing. CFCC uses an effective but simplified alternative of the prioritized Chinese-Wall model[1], with a mandatory access control mechanism for all communication, migration, startup of VMs without changing current MAC policies inside the coalitions. Enforcing MAC to managing the covert flows by CFCC is not to eliminate covert channels by rewriting of hypervisor code but (i) to prevent the covert flow through careful resource management. (ii)to enable users through configuration options to mitigate covert channels [1]Cheng, G., Jin, H., Zhou, D., Ohoussou, A.K., Zhao, F.: A Prioritized Chinese Wall Model for Managing the Covert Information Flows in Virtual Machine Systems. In: 9th International Conference for Young Computer Scientists, pp. 1481--1487. IEEE Press, Hunan (2008)](https://image.slidesharecdn.com/covertflowconfinementforvmcoalition-100222153559-phpapp01/85/Covert-Flow-Confinement-For-Vm-Coalition-8-320.jpg)
Covert Flow Confinement For Vm Coalition
- 1. CFCC: Covert Flows Confinement For VM Coalitions Ge Cheng, Hai Jin, Deqing Zou, Lei Shi, and Alex K. Ohoussou
- 2. Outline Background Cloud and Virtualization Problems Statement Design Requirement Architecture Algorithm Implementation and Experiment Performance Conclusion and Further work
- 3. Background(Cloud and Virtualization) Cloud computing currently emerges as a hot topic due to its abilities to enable companies to cut costs by outsourcing computations on-demand
- 4. Background(Cloud and Virtualization) Many cloud provider take Virtualization technology as the infrastructure , such as Elastic Compute Cloud of Amazon, Blue Cloud of IBM. So it is natural that resources in those cloud computing environment are allocated in VM granularity for cloud users.
- 5. Background(Problem Statement) Although multiple VMs on the same hardware platform offer great benefits, it also raises the risk of information leakage between VMs belonging to different companies which may compete with each other. Enforcing MAC between VMs provides an attractive mechanism to improve the security of VM based cloud computing. Dynamic coalitions , also called domains in some papers, are used to organize VMs over nodes, and security policies differ in each coalition normally.
- 6. Background(Problem Statement) There are many VM coalition building approaches, which have been proposed in distributed VM systems, such as NetTop, Shamon, and Trusted Virtual Domain. Shamon Trusted Virtual Domain
- 7. Background(Problem Statement) However the existing VM coalition systems cannot eliminate covert channel , which are not the mechanism designed for implicitly communication controlling between VMs. For example, if both two VMs have the access to a disk, they may use it as a covert channel by controlling the exhaustion of the disk’s storage space. Although overt communication channels are enforced by explicit authorizations and we have some tools to check comprehensive coverage of authorizations to these channels, covert channels are difficult to identify and perhaps impossible to eliminate completely .
- 8. Background(Problem Statement) To address the above questions, we propose a covert flows confinement mechanism for VM coalitions (CFCC) in VM-based cloud computing. CFCC uses an effective but simplified alternative of the prioritized Chinese-Wall model[1], with a mandatory access control mechanism for all communication, migration, startup of VMs without changing current MAC policies inside the coalitions. Enforcing MAC to managing the covert flows by CFCC is not to eliminate covert channels by rewriting of hypervisor code but (i) to prevent the covert flow through careful resource management. (ii)to enable users through configuration options to mitigate covert channels [1]Cheng, G., Jin, H., Zhou, D., Ohoussou, A.K., Zhao, F.: A Prioritized Chinese Wall Model for Managing the Covert Information Flows in Virtual Machine Systems. In: 9th International Conference for Young Computer Scientists, pp. 1481--1487. IEEE Press, Hunan (2008)
- 9. Design(Design Requirement ) We use the conflicts of interest set of Chinese-Wall policy to describe the requirement of covert flows confinement between two VMs. The coalitions will be dynamically constructed. Both the subjects and objects of the Chinese-Wall policies used in our mechanism are VMs. A label defined by the system administrator is attached to a VM, and the following information flows between label-attached VMs will be controlled. 1) covert information flows between label-attached VMs whose labels are the same are permitted ; 2) covert information flows between label-attached VMs whose labels belong to different conflicts of interest set are permitted; 3) covert information flows between label-free VMs are permitted; 4) covert information flows between label-attached VMs whose labels belong to the same conflicts of interest set are disallowed.
- 10. Design(Design Requirement ) The Chinese-Wall model is history-based , which needs to have the knowledge of the current system state to make decisions. Two features are needed in our architecture: distributed mandatory access control for all VMs and centralized information exchange. Both need to be implemented simultaneously based on the activity history of VMs.
- 11. Design(Architecture) System Architecture of CFCC
- 14. Design(Case) A scenario of covert flows confinement
- 15. Experiment (Performance) Overhead of VMs startup in a single-node Synchronization overhead we implement a prototype, which consists of 4 machines connected with a 1000Mbit Ethernet. Three nodes used is a 2.33 GHz Intel Core Duo processor with 2 MB L2 cache, 2 GB RAM and an 80 GB 7200 RPM disk. The OSS is Pentium 4 machine with 2GHz, 2GB RAM and Federal Linux installed.
- 16. Conclusions and Future Work Our contribution aims to provide a mechanism to confine the covert flows (CFCC) which become a problem for VM-based cloud computing environments even enforced with mandatory access control (MAC). Enforcing MAC to managing the covert flows by CFCC is (i) to prevent the covert flow through careful resource management. (ii)to enable users through configuration options to mitigate covert channels Experimental results show that the performance overhead is acceptable. In our future work, we plan to add application level information flows control for virtual machine coalitions.
- 17. Thank You! Any Question?
Editor's Notes
- #2: Services Computing Technology and System Lab, Huazhong University of Science and Technology
- #3: I will follow this outline to introduce our work.first,the next , then , finally
- #4: Cloud draw the attention of almost every IT giants, look at the logo please , I guess you are very familiar to them
- #5: Most of them take the Virtualization technology as the infrastructure of their cloud
- #6: Mandatory Access control ,
- #10: satisfies the enterprise level security requirement to assure that valuable information on such systems would not be leaked to the competitors, but can permit information leakage by the covert channels between different departments of the same company.
- #12: Locate in the nodes , policy management module and policy enforcement module. A policy management module is located in a specific node named Overall Security Server (OSS) acting as policy center, and other policy management modules are located in Local Security Servers (LSS) of other nodes
- #14: Formalized descripcation
- #15: As shown in above figure , in moment 1, when Back-C tries to start in node 1, we note the CIS as {(Oil-A, Oil-B)}. So we can risk the covert flows leakage between Bank-C and Oil-A, and Bank-C is permitted to start in node 1. Then Bank-C and Oil-A constitute a new coalition, and they have the same conflict of interest relationship. In moment 2, when Bank-B wants to communicate with Bank-C and other, Bank-C and Oil-A in the same coalition and the conflict of interest set has become {(Oil-A, Oil-B), (Oil-B, Bank-C)}. So the requirement of communication between Oil-B and Bank-C will be denied. But Oil-B and other has no conflict of interest, the requirement of communication between them is permitted, and they will constitute a new coalition. Finally there are two coalitions {Oil-A, Bank-C} and {Oil-B, other}. The coalitions are built dynamically according to the conflict set, and VM start, communication or migration sequence. In moment 3 and 4, communications between VMs and migration of VMs within the same coalition are permitted and those between different coalitions are denied. In moment 5, the nodes cannot run VMs belonging to different coalitions because in a moment a node can only belong to a coalition. But when there are no VMs running in the node, this node is released from a coalition and can join another coalition. We just simply use a label to represent a VM with the label.
- #16: we implement a prototype, which consists of 4 machines connected with a 1000Mbit Ethernet. Three nodes used is a 2.33 GHz Intel Core Duo processor with 2 MB L2 cache, 2 GB RAM and an 80 GB 7200 RPM disk. The OSS is Pentium 4 machine with 2GHz, 2GB RAM and Federal Linux installed.