This chapter concludes this thesis report based on the experiments and discussion above in Section 10.1 and gives future work in Section 10.2.
10.1. Conclusions
This thesis report has addressed the problem of securely deploying third-party services on VRGs. This work was carried out in the context of the CareNet project, which intends to deploy third-party healthcare services on a Virtualized Residential Gateway. Security assessment on the RG virtualized with LXC has been conducted.
According to it, the weaknesses of LXC as well as potential strategies to mitigate them with respect to securely delivering third-party services have been presented.
These possible solutions have been evaluated and analyzed based on pre-defined metrics: Confidentiality and Integrity; Implementation Difficulties; Flexibility and System Overhead after placing each of them. We’d like to summarize the work in this thesis with answering all the sub-questions stated in Section 1.2:
· The inherent weakness of LXC falls into VM Escape. This kind of attack can be performed in several forms such as inserting unwanted modules and injecting malicious code. This is because the share kernel characteristic set a restriction of being unable to support kernel customizations, which greatly limit the usage of the containers. In addition, sensitive data on the service provider container remain unprotected as well since different roles in the CareNet service delivery model are equally regarded inside a container.
· Implementing SELinux and SMACK modules; deploying container management tool OpenQRM can be potential solutions. SELinux and SMACK both provide TE and MAC as a way of access control to set fine-grained restriction towards illegal action such as VM Escape attack. SELinux provides RBAC as well, which regulates Read/Write access to sensitive data on a different role’s basis. In context with OpenQRM, no direct access is allowed to container thus limits the operations in the set of the legitimate.
· Setting up SELinux will cost 7% system performance loss and there is an additional concern for the administrator to formulate policy rules due to its complex syntax, while bringing in SMACK only takes 5% more system resource and it’s easy to set up. OpenQRM, as a web-based management tool, is easy to implement and the cost on system performance is negligible. However, since no direct remote access is allowed inside a container, deploying services will be rather difficult since users have to modify container file system on the host machine before sending off containers to function.
· SELinux fully fits the requirements proposed in Section 5.1 so that we consider its
64
benefits to outweigh its drawbacks. Though not difficult to set up and lightweight, neither OpenQRM nor SMACK can provide an approach to protect sensitive medical data such as RBAC, which we consider as the critical reason of excluding them from reliable solutions.
· While due to having introduced Hypervisor layer to provide isolation, full virtualization and para-virtualization suffer from a rather big performance loss, we consider Linux Container fair as our virtualization technology. Because from a scalable and light-weight point of view, LXC is capable enough and it uses system resources more efficiently than other full virtualization solutions, which is in accordance with the CareNet requirements. In addition, since the Linux community recognizes LXC as a standard container-based virtualization solution, it receives widespread support by kernel developers.
We then come to answer the basic question proposed before those sub ones in Section 1.2:
· SELinux, can be used as a secure solution for RG virtualized with LXC to reliably deliver services.
Through the investigation of VRG vulnerabilities, we have shown that SELinux can effectively protect container from access to unauthorized resource or files. Therefore, this VRG with SELinux can achieve the same immunity to virtualization vulnerabilities as other types of virtualization do with associated. We have also shown that through the use of SELinux, we can protect sensitive data against unprivileged access. Moreover, through the evaluation, we show that, the cost of system resource for implementing SELinux with LXC is still lower than that of full-virtualization.
Finally, we can conclude that the conducted experiments have given valuable assessment of virtualization security; the merits and demerits of LXC as well as the benefits and limitations of the possible solutions.
10.2. Future Work
Since we used Fedora, which is shipped with SELinux support, as our platform of choice for solution, future work can investigate other Linux distributions. In addition, it might also be useful to follow the effort in [36], as they would build a sandbox using libvirt and SELinux.
As for the policy, in this thesis project, they are compiled only in the host machine.
This can make the system more flexible in dealing with security threats if operations within the container are constrained through specifying the container’s own policies.
When it comes to the security assessment, we have looked in to Hallberg’s work in [49]. Five issue of conducting security assessment was in it but we only took the first
65
approach due to limited time of this project: mapping the characteristic into security metrics. Future work could be follow Hallberg’s effort and further assess the VRG based on the rest of them, which are finding mechanisms to associate appropriate sub-sets of the security-related characteristics to system entities, seeking methods for assessment of the security strength of system entities, modeling techniques capturing security-relevant properties of system structures and aggregating the results for individual system entities.
66