Container Security

Linux containers are gaining popularity with the OS level virtualization being widely deployed in the cloud environments; however, they also attract attackers' attention. Particularly, since the same OS kernel is shared among all containers, when one malicious container can escape from the user-level process into the OS kernel via the vulnerable system calls, all other containers will be compromised. Based on the observation that two different sets of system calls are needed for the short-term booting phase and the long-term running phase, we had implemented a system call reduction mechanism called SPEAKER that can dramatically reduce the number of available system calls when a given container executes at the running phase. The experimental results showed that SPEAKER can reduce more than 50% and 35% system calls in the running phase for the data store containers and the web server containers, respectively. In this project, we focus on extending SPEAKER as a software product that can be smoothly adopted to enhance container security using our temporal-based fine-grained system resource constraint techniques.

Read more about our works:
SPEAKER Measurement Studies


There is an unabated growth in the usage of Linux containers (e.g., Docker) as an operating system level virtualization approach for running large-scale microservice-based applications in the cloud environment. Meanwhile, the wide adoption of containers also propagates the vulnerabilities embedded in the deployed applications. Since the system calls are the entry points for processes trapping into the kernel, the Linux seccomp security profile has been integrated into Docker to provide a course-grained system call whitelist that constrains the container. However, Docker cannot narrow down this set of necessary system calls for a given application. Also, we observe a large number of system calls are only used in the booting phase and can be disabled during the running phase that is much longer, which could further scale down the attack surface.

In this work, we propose a non-intrusive container security mechanism named SPEAKER that enables split-phase execution of application containers with minimal system call whitelists. For a given application container, our method automatically analyzes its behavior to identify execution phases (i.e., booting, running, or shutdown phase) and trace its invoked system calls of these three phases, respectively. Then, we extend the Linux seccomp filter to make it dynamically modifiable. After this, when the application is entering a new execution phase, the corresponding fine-grained system call whitelist will be automatically updated. We evaluate SPEAKER on eight popular database and web server containers on the Docker Hub. The experimental results show that it can successfully reduce more than 68\% system calls with a negligible performance overhead.

Download the Paper Code

author="Lei, Lingguang
and Sun, Jianhua
and Sun, Kun
and Shenefiel, Chris
and Ma, Rui
and Wang, Yuewu
and Li, Qi",
editor="Polychronakis, Michalis
and Meier, Michael",
title="SPEAKER: Split-Phase Execution of Application Containers",
booktitle="Detection of Intrusions and Malware, and Vulnerability Assessment",
publisher="Springer International Publishing",

Measurement Studies on Container Security

A Measurement Study on Linux Container Security: Attacks and Countermeasures

Linux container mechanism has attracted a lot of attention and is increasingly utilized to deploy industry applications. Though it is a consensus that the container mechanism is not secure due to the kernel-sharing property, it lacks a concrete and systematical evaluation of its security using real-world exploits. In this paper, we collect an attack dataset including 223 exploits that are effective on the container platform and classify them into different categories using a two-dimensional attack taxonomy. Then we evaluate the security of the existing Linux container mechanism using 88 typical exploits filtered out from the dataset. We find 50 (56.82%) exploits can successfully launch attacks from inside the container with the default configuration. Since the privilege escalation exploits can completely disable the container protection mechanism, we conduct an in-depth analysis on these exploits. We find the kernel security mechanisms such as Capability, Seccomp, and MAC play a more important role in preventing privilege escalation than the container isolation mechanisms (i.e., Namespace and Cgroup). However, the interdependence and mutual influence relationship among these kernel security mechanisms may make them fall into the "short board effect" and impair their protection capability. By studying the 11 exploits that still can successfully break the isolation provided by the container and achieve privilege escalation, we identify a common 4-step attack model followed by all 11 exploits. Finally, we propose a defense mechanism to effectively defeat those identified privilege escalation attacks.

Experiment Setup.

Security Evaluation Result Overview.

Download the Paper

author = {Lin, Xin and Lei, Lingguang and Wang, Yuewu and Jing, Jiwu and Sun, Kun and Zhou, Quan},
title = {A Measurement Study on Linux Container Security: Attacks and Countermeasures},
year = {2018},
isbn = {9781450365697},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {},
doi = {10.1145/3274694.3274720},
booktitle = {Proceedings of the 34th Annual Computer Security Applications Conference},
pages = {418–429},
numpages = {12},
keywords = {Container, Kernel Security Mechanisms, Privilege Escalation},
location = {San Juan, PR, USA},
series = {ACSAC '18}

Evaluation on the Security of Commercial Cloud Container Services

With the increasing adoption of the container mechanism in the industrial community, cloud vendors begin to provide cloud container services. Unfortunately, it lacks a concrete method to evaluate the security of cloud containers, whose security heavily depends on the security policies enforced by the cloud providers. In this paper, we first derive a metric checklist that identifies the critical factors associated with the security of cloud container services against the two most severe threats, i.e., the privilege escalation and container escaping attacks. Specifically, we identify the metrics which directly reflect the working conditions of the attacker. We also extract the metrics essential to achieve privilege escalation and container escaping attacks by investigating the feasible methods for breaking the security measures, including KASLR, SMEP, and SMAP, etc. Since memory corruption vulnerabilities are frequently adopted in the privilege escalation attacks, we collect a dataset of the publicly released memory corruption vulnerabilities to assist the evaluation. Then, we develop a tool to collect the metric data listed in the checklist from inside the cloud containers and perform security inspections on five in-service commercial cloud container services. The results show that some containers are enforced with weak protection mechanisms (e.g., with the Seccomp mechanism being disabled), and the KASLR could be bypassed on all five cloud containers. However, even after obtaining ROOT privilege in a container, attackers still can hardly escape from the container on the public cloud platforms, since the necessary files for crafting or compiling a loadable kernel module for the host OS are inaccessible to the container. Finally, we provide some suggestions to improve the security of the cloud container services.

Execution Environment of the Cloud Containers.

Download the Paper

author="Wu, Yifei
and Lei, Lingguang
and Wang, Yuewu
and Sun, Kun
and Meng, Jingzi",
editor="Susilo, Willy
and Deng, Robert H.
and Guo, Fuchun
and Li, Yannan
and Intan, Rolly",
title="Evaluation on the Security of Commercial Cloud Container Services",
booktitle="Information Security",
publisher="Springer International Publishing",



Dr. Kun Sun


Pengbin Feng (Postdoc)

Xinda Wang (PhD student)

Yunlong Xing  (Visiting Master student)

Zeyu Zhang (Visiting Master student)

External Collaborators:

Lingguang Le (Chinese Academy of Sciences)

Haining Wang (Virginia Tech)