Security Namespace: Making Linux Security Frameworks Available To

Security Namespace: Making Linux Security Frameworks Available to Containers Yuqiong Sun, Symantec Research Labs; David Safford, GE Global Research; Mimi Zohar, Dimitrios Pendarakis, and Zhongshu Gu, IBM Research; Trent Jaeger, Pennsylvania State University https://www.usenix.org/conference/usenixsecurity18/presentation/sun This paper is included in the Proceedings of the 27th USENIX Security Symposium. August 15–17, 2018 • Baltimore, MD, USA ISBN 978-1-931971-46-1 Open access to the Proceedings of the 27th USENIX Security Symposium is sponsored by USENIX. Security Namespace : Making Linux Security Frameworks Available to Containers Yuqiong Sun David Safford Mimi Zohar Symantec Research Labs GE Global Research IBM Research Dimitrios Pendarakis Zhongshu Gu Trent Jaeger IBM Research IBM Research Pennsylvania State University Abstract 1 Introduction Lightweight virtualization (i.e., containers) offers a virtual host environment for applications without the need Lightweight virtualization (i.e., containers) offers a vir- for a separate kernel, enabling better resource utiliza- tual host environment for applications without the need tion and improved efficiency. It is broadly used in com- for a separate kernel, enabling better resource utiliza- putation scenarios where a dense deployment and fast tion and improved efficiency. However, the shared ker- spin-up speed is required, such as microservice archi- nel also prevents containers from taking advantage of se- tecture [39] and serverless computation (e.g., Amazon curity features that are available to traditional VMs and Lambda [26]). Many commercial cloud vendors [23, 20, hosts. Containers cannot apply local policies to gov- 1] have adopted the technology. ern integrity measurement, code execution, mandatory access control, etc. to prevent application-specific se- The key difference between containers and traditional curity problems. Changes have been proposed to make VMs is that containers share the same kernel. While this kernel security mechanisms available to containers, but enables better resource utilization, it also prevents con- such changes are often adhoc and expose the challenges tainers from taking advantage of security features in ker- of trusting containers to make security decisions without nel that are available to traditional VMs or hosts. Con- compromising host system or other containers. In this tainers cannot apply local security policies to govern in- paper, we propose security namespaces, a kernel abstrac- tegrity measurement, code execution, mandatory access tion that enables containers to have an autonomous con- control, etc. to prevent application specific security prob- trol over their security. The security namespace relaxes lems. Instead, they have to rely on a global policy spec- the global and mandatory assumption of kernel security ified by the host system admin, who often has different frameworks, thus enabling containers to independently security interests (i.e., protect the host system) and does define security policies and apply them to a limited scope not have enough insight about the security needs of indi- of processes. To preserve security, we propose a routing vidual containers. As a result, containers often run with- mechanism that can dynamically dispatch an operation out any protection [34, 40]. to a set of containers whose security might be affected Previous efforts of making kernel security frameworks by the operation, therefore ensuring the security decision available to containers are often adhoc and expose the made by one container cannot compromise the host or challenges of trusting containers to make security deci- other containers. We demonstrate security namespace by sions without compromising host system or other con- developing namespaces for integrity measurement and tainers. For example, a kernel patch [24] to Integrity mandatory access control in the Linux kernel for use by Measurement Architecture (IMA) [53] suggested that the Docker containers. Results show that security names- IMA measurement list can be extended with a container paces can effectively mitigate security problems within ID, such that during integrity attestation the measure- containers (e.g., malicious code execution) with less than ments will become separable based on containers. As 0.7% additional latency to system call and almost identi- another example, AppArmor and Tomoyo introduced the cal application throughput. As a result, security names- concept of profile and policy namespace [49, 44] to allow paces enable containers to obtain autonomous control certain processes to run under a policy different from the over their security without compromising the security of rest of the system. These changes, however, only made other containers or the host system. limited kernel security features available to containers, USENIX Association 27th USENIX Security Symposium 1423 and they all rely on the system owner to specify a global form the container owners of potential conflicts before policy, leaving containers no real freedom in enforcing they load their security policies. an autonomous security. We evaluate our design by developing two concrete in- In this paper, we explore approaches to make kernel stances of security namespace, one for IMA and one for security frameworks available to containers. Due to the AppArmor. Results show that leveraging the namespace diversity of kernel security frameworks and their differ- abstractions, containers (e.g., Docker and LXC) can ex- ent design perspectives and details, it is extremely dif- ercise the full functionality of IMA and AppArmor and ficult to reach a generic design that can cover all ker- apply autonomous security control, much like a VM or nel security frameworks in a single step. Instead, this host system. Specifically, we show that the IMA names- paper explores an initial step, by making two concrete pace enables containers to independently measure and kernel security frameworks available to containers, to in- appraise files that are loaded into the container, with- vestigate the common challenges and approaches behind. out violating any of the host system’s integrity policy. Hopefully, the results have enough generality to guide For AppArmor namespace, we show that it enables con- other kernel security frameworks and eventually lead to a tainers to enforce two policy profiles simultaneously, one generic design. In studying the two popular kernel secu- protects the host system and another protects the con- rity frameworks, namely IMA [53] for integrity and Ap- tainerized application, which was not possible as dis- pArmor [41] for mandatory access control, we make the cussed in Ubuntu LXC documentation [34]. We evaluate following observations: first, we find that the common the performance of both namespace abstractions. Results challenge for containers to obtain autonomous security show that security namespaces introduce less than 0.7% control is the implicit global and mandatory assumptions latency overhead to system calls in a typical container that kernel security frameworks often make. Kernel se- cloud use case (i.e., no nested namespaces) and an al- curity frameworks are designed to be global—they con- most identical throughput for containerized applications. trol all processes running on the system. They are also In summary, we make the following contributions. designed to be mandatory—only the owner of the system • Through studying IMA and AppArmor, we inves- may apply a security policy. However, autonomous se- tigate the common challenges and approaches be- curity control requires relaxation of both assumptions. A hind making kernel security frameworks available container need to apply local security policies to control to containers. a subset of processes running on the system (i.e., processes in the container). Relaxing these assumptions in- • We develop two concrete security namespace ab- volves security risks. Our second insight is that we can stractions, one for IMA and another for AppArmor, relax the global and mandatory assumptions in a secure which enables autonomous security control for con- way by checking if the autonomous security control of tainers while preserving security. a container may compromise the security of other containers or the host system. We do this by inferring from • We show that widely used container systems (e.g., containers’ security expectation towards an operation. Docker and LXC) can easily adopt the IMA and AppArmor security namespace abstractions to exer- Leveraging these insights, we propose the design of cise full functionality of kernel security frameworks security namespaces, kernel abstractions that enable con- with modest overhead. tainers to utilize kernel security frameworks to apply autonomous security control. Security namespace virtual- 2 Background izes kernel security frameworks into virtual instances, In this section, we first describe the namespace concept one per container. Each virtual instance applies inde- in the Linux kernel and how it is adopted by container. pendent security policies to control containerized pro- We then discuss security frameworks in Linux kernel. cesses and maintains their independent security states. To ensure that the relaxation does not compromise any 2.1 Namespace and Container principal’s security (i.e., other containers or the host sys- The Linux namespace abstraction provides isolation for tem), an Operation Router is inserted before the virtual various system resources. According to Linux man instances mediating

Load more