Penetration Testing for Linux Jail as
Exploit-resistant Linux Container
Shintaro Suzuki

Yuki Nakata

Katsuya Matsubara

Future University Hakodate
Hokkaido, Japan
g2123032@fun.ac.jp

SAKURA internet Inc.
Hokkaido, Japany-nakata@sakura.ad.jp

Future University Hakodate
Hokkaido, Japanmatsu@fun.ac.jp

Abstract—Containers provide lightweight and fine-grained isolation for computational resources, such as central processing
units’ CPUs, memory, storage, and networks. Still, they are
not genuinely sandboxed as they share the host OS kernel.
Consequently, vulnerabilities in the host OS kernel can be
exploited to escape the container isolation. We have proposeda Container Transplantation approach by adopting FreeBSD as
the runtime platform for Linux containers to reduce the attack
surface to Linux kernel vulnerabilities with low overhead. To
verify our proposal, this work runs code that exploits Linuxkernel vulnerabilities on the Linuxulator to explore whether it
can defend or neutralize the attacks. Our test adopts known
Linux kernel vulnerabilities and attack codes released as proof
of concept but excludes ones that depend on functionalities
unsupported by the Linuxulator. Therefore, the test results would
indicate whether differences in implementation provide effectiveness in resisting vulnerability exploits, even if they implementcompatible OS functionalities.

I. I NTRODUCTION
Container-virtualization technologies, such as Docker [1],are now widely used as lightweight application-execution
environments in cloud services. They are based on operating
system (OS) processes, which are lightweight compared withtraditional virtual machines (VMs), resulting in faster startup
and a lower memory footprint. Many cloud services [2], [3]take advantage of the characteristics of containers for rapid
scale-out, scale-in, and more efficient resource usage.
When using container virtualization as an applicationexecution environment in the cloud, cloud-service providers
must ensure robust isolation between containers to prevent
one user from negatively impacting another. Unfortunately, theOS kernel is shared among containers. This means that vulnerabilities in the OS kernel can be exploited to escape fromthe container to the host environment or obtain unauthorized
root privileges [4]–[6]. Sandboxes that create additional isolation environments to address such attacks improve isolation
between containers by creating VMs for each container [7]and isolating OS kernels between containers using user-space
kernels [8].
However, creating additional isolation environments hinders
rapid container startup and degrades application performance.
Kata Containers [7] creates a VM for each container, isolating the OS to keep the impact of privilege escalation andcontainer-escaping attacks contained within VMs. This hinders
the characteristic of a fast container startup. The container

sandbox gVisor [8] reduces the attack surface of the OS kernel
by intercepting system calls issued by applications and redirecting them to a securely re-implemented user-space kernel.
It significantly degrades the performance of applications due
to intercepting all system calls issued by the application andreimplementing many OS resources in user space [9].
We aim to achieve a container sandbox with Container
Transplantation in which Linux containers run compatibly inanother OS and apply another OS-specific security mechanism
to resolve the trade-off between robust container isolationand container characteristics and application performance.
Since many cloud services use Linux as the environment for
hosting containers, vulnerabilities in the Linux kernel andits functions are directly linked to container vulnerabilities.
Unfortunately, attacks that exploit those vulnerabilities often
have fatal adverse effects that make it impossible for cloudservices to run correctly, such as unauthorized access tohosts and other containers through privilege escalation andthe theft of sensitive information. We argue that executing
Linux containers in another OS can avoid these various attacks
that exploit vulnerabilities related to the Linux kernel andits functionality. It is also possible to apply unique security
models and functions implemented in various OSes to Linuxcontainers to achieve more finely grained access control andisolation between containers resilient to attacks targeting specific OSes.
To resolve the trade-off between robust container isolation, container characteristics, and application performance,
we have proposed a lightweight container sandboxing thatruns Linux containers compatibly on a heterogeneous OS
and applies uncommon security mechanisms in Linux, named‘Container Transplantation’ [10]. The implementation of the
proposed Container Transplantation adopts FreeBSD as theheterogeneous OS.
This study investigates the possibility of resisting attacks
using Linux kernel vulnerabilities through the Linux jails.
Among exploit codes against the vulnerabilities in Linux
Kernel 5.15.0, emulated by Linux jails on FreeBSD 14.0, we
have chosen ones that the Linuxulator can execute. We thencategorized the Linux kernel vulnerabilities that the securecontainer must be able to avoid, tried the attacks on bothLinux and the Linuxulator, and summarized the success or
failure of the attacks. Our experimental results indicate that theLinuxulator can efficiently neutralize exploits against Linuxkernel vulnerabilities with low overheads.
II. C ONTAINER T RANSPLANTATION IN F REE BSD
We aim to enable Container Transplantation, which compatibly executes Linux containers on heterogeneous OSesand applies heterogeneous OS-specific security mechanisms
to prevent attacks on containers that exploit vulnerabilities ina specific OS kernel. It makes the host OS and container’s OS
kernel different, so that attacks on the host OS that exploit OS
kernel-specific vulnerabilities fail. It can be resistant to attacks
targeting specific OSes by combining the isolation provided
by conventional containers with heterogeneous OS-specificsecurity mechanisms (e.g., limiting unnecessary system callinvocations) for fine-grained access control/restriction. As asimilar approach, live migration to heterogeneous environments is effective in mitigating attacks that exploit vulnerabilities in specific OS kernels or Virtual Machine Monitors(VMMs) [11], [12]. We expect our Container Transplantation
approach to be similarly resistant to attacks that exploit
those vulnerabilities because it runs virtual environments on aheterogeneous OS, similar to live migrations.
Our Container Transplantation approach reduces application
performance and startup overhead compared with traditional
approaches for container sandboxes while preventing attacks
that exploit OS kernel vulnerabilities. It is a primitive emulation that runs containers created for one OS on a heterogeneous OS but without VMs. While VMs emulate computing
resources and intercept all I/O, our approach translates differences between OSs only for system calls and OS functions
within the OS kernel space. Therefore, it not only eliminates
the OS startup process required for VMs but also reduces theoverhead of application-performance degradation due to userspace interception and redirection.
We proposed a lightweight container sandbox that emulatesLinux containers on FreeBSD, based on FreeBSD’s LinuxJail,as one implementation of Container Transplantation [10].
LinuxJail can execute Linux binaries by using the Linuxulator, which translates system calls invoked by Linux binaries
into FreeBSD system calls. It provides the Linux systemcall interface and translates arguments and options in kernel
space, thus having less overhead on application performance.
Furthermore, we combine LinuxJail with FreeBSD’s Capsicum
to reduce the attack surface. Figure 1 shows an overview of
our Container Transplantation for FreeBSD.
When using a system-call translation such as the Linuxulator, we have to give due consideration to the compatibilityof the system calls. With such translations, specific options or
the system calls are not supported, limiting the applications
that can be run. The Linuxulator has been reported to workwith major server applications such as Apache HTTP Serverand MySQL [13]. Our discussion of the compatibility between
the Linuxulator and other methods [10] also concluded that it
is sufficient to support common web applications running incloud environments.

_Capsicum Sandbox_

Malicious
Container…

Container

Capsicum reduces attack surface
Kernel implementation differences
avoid vulnerabilities

Linuxulator

FreeBSD

Fig. 1. Overview of Container Transplantation for FreeBSD.

III. P ENETRATION T EST
We evaluated the robustness of our proposed sandbox with
Container Transplantation by testing whether the Linuxulator
system call translation that we used in our implementation
could prevent exploits that exploit known vulnerabilities in theLinux kernel implementation. The first step of this penetration
test was to list the vulnerabilities and their exploit codes thatcan be exploited in the environment we targeted from among
the large number of known vulnerabilities reported in theLinux kernel. We then executed the listed vulnerabilities on
the Linux kernel and LinuxJail environment and compared
the success or failure of the exploits.
A. OS Environments
It is important to standardize the Linux kernel version
and settings related to security mechanisms on both Linuxkernel environments and FreeBSD’s Linuxulator to correctlycompare the results of penetration tests. There are various
Linux kernel vulnerabilities, including those that depend ona specific version and those that cross multiple versions, anddifferences in kernel versions are related to the success or
failure of the execution of exploit codes. To evaluate thevulnerability in a realistic environment, it is also desirable
to evaluate whether the exploit can be avoided with kernel versions that are supported by the Linux communityand patched for the vulnerability. Many OSes have security
mechanisms, such as memory-access restrictions and memoryaddress randomization, that can prevent the execution ofcertain exploit codes. However, since the support for thesemechanisms differs among OSes, it is necessary to standardize
the security mechanisms used so that evaluation can be based
only on differences in kernel implementations.
We chose Linux Kernel 5.15.0 as the kernel version for our
testing environment because it is the kernel version available
for the Linuxulator and currently supported by the Linux
community. We used FreeBSD version 14.0-RELEASE to use
the Linuxulator with Linux Kernel 5.15 compatibility.
In the experimental environment, the Supervisor Mode
Access Prevention (SMAP) and Supervisor Mode Execution
Prevention (SMEP), mechanisms for restricting unauthorizedStartGetting Linux Kernel
CVE Information
No

Yes
No

We used a VM for each exploit code and ran the exploit
on an independent environment. The VMs were VirtualBox,
with 4 GB and 4 cores per VM. Some exploits made a single
core desirable, depending on the exploit. The Linux VMs
used Ubuntu 22.04 as the VM image, built Kernel 5.15.0,

Yes

Searchingattack CodeNo

Existing
Attack Code
Yes

No

Using in SMAP/SMEP
Enabled Environment

12 Vulnerabilities

C. exploit Environment

Meeting theFour Conditions

408 Vulnerabilities

Kernel 5.15

B. exploit Codes
We are currently evaluating known vulnerabilities in theLinux kernel 5.15, although not all published vulnerabilities
can be used in our experiments. Vulnerabilities that cannot
be used in our experiments are those under the following
conditions.
• Vulnerability related to functions that do not exist inLinuxulator: the library or functionality required by the
exploit code is not available, so the exploit does notalways succeed• Architectures not expected to be used in cloud environments: Since we targeted cloud environments, CPUarchitectures used in embedded environments or laptops
are out of scope• Features not expected to be used in cloud environment:
Vulnerabilities related to specific hardware devices orminor protocols are not included because they are notavailable in the cloud• exploit code is not published: If the exploit code is not
published on a vulnerability-reporting page or sourcecode hosting service, it is not covered because it cannot
be reproduced
On the basis of these conditions, we mechanically selected
12 available vulnerabilities out of the 600 vulnerabilities that
had been publicly reported as of January 16, 2024. All vulnerabilities related to the Linux kernel are managed by version atLinux Kernel CVE, a project that tracks Linux vulnerabilities.
It lists vulnerabilities in the form of a CVE-ID, the commit
that was fixed, function for which the vulnerability was found,
version in which it was fixed, and a description of thevulnerability. We excluded vulnerabilities that fit conditions 1,
2, and 3 on the basis of the function in which the vulnerability
was found listed in it and extracted 408 vulnerabilities. For theremaining vulnerabilities, we surveyed vulnerability-reporting
pages and source-code hosting services such as GitHub forthe existence of exploit code and excluded those we could not
find, resulting in the extraction of 14 vulnerabilities. Figure 2
shows the flow of vulnerability extraction.

600 Vulnerabilities

memory access, were enabled, and Kernel Address Space
Layout Randomization (KASLR), which randomizes kernel
memory addresses, was disabled. SMAP prohibits access touser-space memory from kernel space, and SMEP prohibits
the execution of user-space code while kernel-space codeis executing. KASLR applies ASLR to the kernel to randomize binary memory addresses. SMAP and SMEP wereenabled because they are implemented in both Linux and
FreeBSD. However, KASLR is implemented in Linux but not
in FreeBSD, so we disabled KASLR in Linux.

Yes

Out of Scope

Adding to
the Attack List

End

Fig. 2. The flow of extracting vulnerabilities to be evaluated.

and booted it. For the kernel config, we used localmodconfig
from generic/ubuntu2204. The kernel configurations that had
to be changed for each exploit code were changed as needed.
We configured grub to enable smap, smep and disable kaslr.
The FreeBSD VM was based on FreeBSD 14.0-RELEASE,
and the kernel build was done according to the exploit. The
exploit used bastille to manage the jail, and Linux emulation
was used. exploit tests were conducted in this environment.
D. Test Results
In our experiments, we tested exploit codes on Linuxulator
that had previously succeeded on Linux. However, we didn’t
test codes relying on Linux-specific features not available inLinuxulator, focusing instead on the underlying vulnerabilities.
For instance, eBPF not supported in FreeBSD, and fuse, it
can’t be used on Linuxulator, were excluded from our tests.
Success datermination of the exploit depends on the eachcode. When explicit success indicators were provided within
the exploit code, we adhered to them. For race condition
exploits, we followed the set number of trials when specified,otherwise considering the exploit unsuccessful if it didn’t
succeed within 24 hours. For result is shown I. confirmed(exploit confirm), failed (exploit failed), N/A (can’t build)TABLE I
LIST OF PENETRATION TESTING AT L INUX VULNERABILITIES .

CVEIDVulnerability detailCVE-2021-4155

data leak caused by ’IOCTL with XFS’CVE-2022-2585

UAF caused by ’POSIX CPU timer’CVE-2022-2588

UAF caused by ’net scheduler’

CVE-2022-24122

UAF and privilege escalation caused by ’ucount’CVE-2022-25258

Memory corrupt caused by ’USB Gadget subsystem’

CVE-2022-25265
CVE-2022-27666
CVE-2022-36402
CVE-2022-38096
CVE-2023-0045
CVE-2023-3640

Arbitrary code execution caused by binary files exec-all attributeprivilege escalation caused by ’IPsec ESP’privilege escalation or Dos caused by ’vmwgfx driver’
privilege escalation or Dos caused by ’vmwgfx driver’data leak caused by Spectre-BTI
privilege escalation caused by ’x86 memory management’CVE-2023-6606

crash system or data leak caused by ’samba cifs’

The results showed that most exploits that succeeded on
Linux. The conditions necessary for a successful exploit are
difficult to reproduce and were caused by the complexity ofdeciphering the exploit code It due to their use of magic numbers and unconventional functions. Identifying the necessarybuild and kernel options for setting up a comparable exploit
environment proved challenging.
Additionally, certain exploit codes employed loopback devices and system calls like unshare and fuse, which lack emulation in Linuxulator, thus couldn’t be directly executed. We
modified such codes to work on Linuxulator where possible,
substituting functionalities with equivalent ones available in
FreeBSD or Linuxulator, and replacing virtual devices withphysical ones where necessary. Some exploits were abandoned due to infeasibility of emulation, such as with fuse,
which, despite being available in FreeBSD, couldn’t be usedon Linuxulator. Through these modifications, we aimed toadapt the exploit codes for Linuxulator to the best of ourability. However, the only exploit we managed to verify, CVE2021-4155, involved an IOCTL exploit that failed because
the specific system call options used were not supported on
Linuxulator
E. Analysis of CVE-2021-4155 Exploit
The vulnerability, CVE-2021-4155, which allows unauthorized access to files by using the IOCTL XFS IOC ALLOCSP
on devices with an XFS filesystem, only succeeded in a
Linux environment. This was due to the exploit leveraging
a system call option not supported by Linuxulator. For the
exploit, a loopback device was used to mount the XFS
filesystem, writing an XFS-formatted img file to loopback,then mounting it at /mnt. The exploit code, when executed
against /mnt/read me, enabled illegal reading of the XFS data.
Given the unavailability of the loopback device in Linuxulator,
we adapted the code to use a physical partition instead. This
modified code was tested on both Linux and Linuxulator
environments. The execution results are shown in III-E, III-E,
III-E On Linux, the exploit was successful, allowing theresult in Linuxconfirmed

result in Linux jailfailed(target functionality not exist)

failed(race condition never reproduced)
failedfailed(No Kernel crashed)
N/A(USB gadget func. required in H/W)
failedfailedfailedfailedfailedfailedN/A(Error occurred)

not tested
not tested
not tested
not tested
not tested
not tested
not tested
not tested
not tested
not tested
not tested

Fig. 3. CVE-2021-4155 result on Linux 1

Fig. 4. CVE-2021-4155 result on Linux 2contents of the img file to be read when executing xxd against/mnt/read me. However, on Linuxulator, the eploit failed, withxxd revealing only 0-filled data, due to the absence of the
IOCTL option XFS IOC ALLOCSP. XFS IOC ALLOCSP
is an IOCTL option and is related to file size expansion.
Fortunately, the functionality must be minor and useless formost container applications.
IV. C ONCLUSION
While it is known that vulnerabilities of the underlying
OS kernel may allow to escape the container isolation, thefinding of this penetration test is that if Linux containers canbe transplanted to Linux jails on FreeBSD, it may be possible
to neutralize exploits to the Linux kernel vulnerabilities. This
study aimed to evaluate the vulnerability resistance of Linux
jails by executing code that attacks known Linux vulnerabilities on both Linux and Linux jails. Unfortunately, reproducing
the attacks was not easy. Many attack codes released as
PoCs are poorly documented; even if the reproduction of

TABLE II
LIST OF MD5 HASHES OF EXPLOIT CODE URL

CVE IDCVE-2021-4155
CVE-2022-2585
CVE-2022-2588
CVE-2022-24122
CVE-2022-25258
CVE-2022-25265
CVE-2022-27666
CVE-2022-36402
CVE-2022-38096
CVE-2023-0045
CVE-2023-3640
CVE-2023-6606

Repository
gist
githubgithubgithubgithubgithubgithubgithubgithubgithubgithubbugzillaFig. 5. CVE-2021-4155 result on freebsd

the attack on Linux fails, the unreadable and abnormal code
implementation could hinder the analysis of the exploit failure.
In addition, the code implementation, which is not directly
related to the vulnerability, uses Linux-specific features suchas namespace, which has required some code modification
to execute the code on Linux jails. The penetration tests
have confirmed that an exploit against CVE-2021-4155, avulnerability in Linux kernel 5.15.0, makes it fail by running
it in a Linux jail. This is because the functionality that causes
the vulnerability is not supported by Linuxurator.
The following two points need to be considered in our
future work. We plan to implement a robust Linux-compatible
container environment against vulnerabilities in the OS kernel
and libraries by establishing a method of applying Capsicum
and Casper to Linux jails. In addition, since new vulnerabilities
are still being discovered one after another, we would like toevaluate to what extent Linux jails can resist zero-day attacks
against these new vulnerabilities.

R EFERENCES[1] D. Merkel, “Docker: Lightweight linux containers for consistent development and deployment,” Linux J., vol. 2014, no. 239, Mar. 2014.

Source of Exploit CodeMD5 hash of URL
ec70d8a77cab68fcd24b149046c7dffd
19ec3bf26fbef0c3f1929b7f771d9181
e241e11a514c93846a95c358276db850
08dbd96faed08fa20e0e9e0c1ace7af1
fe0a7553ecc457fe230b4031fff3650f
6bdca7fc4f72aca7e66dafb172e179b3
25fb27e898ac93e88b2366e64fa83ebb
7a0b62ff3eb293c829e52807d0bb2671
52ae378444a25983fca01639bf0c85d1
76f65a6f26c638be1ad2f86ac57fb9cd
647ad4e927826b1e18abe585598c0429
1518be6f4c8e9e791e31a5c5c7f842a1[2] I. Salesforce.com. Cloud application platform — heroku. (Accessed on
2022/10/18). [Online]. Available: https://www.heroku.com/[3] G. LLC. Cloud functions — google cloud. (Accessed on 2022/10/18).
[Online]. Available: https://cloud.google.com/functions[4] X. Lin, L. Lei, Y. Wang, J. Jing, K. Sun, and Q. Zhou, “A measurement
study on linux container security: Attacks and countermeasures,” in Proceedings of the 34th Annual Computer Security Applications Conference,ser. ACSAC ’18. New York, NY, USA: Association for Computing
Machinery, 2018, pp. 418–429.
[5] S. Sultan, I. Ahmad, and T. Dimitriou, “Container security: Issues,challenges, and the road ahead,” IEEE Access, vol. 7, pp. 52 976–52 996,
2019.
[6] X. Gao, Z. Gu, M. Kayaalp, D. Pendarakis, and H. Wang, “Containerleaks: Emerging security threats of information leakages in container
clouds,” in 2017 47th Annual IEEE/IFIP International Conference on
Dependable Systems and Networks (DSN), 2017, pp. 237–248.
[7] O. I. Foundation, “Kata containers - open source container
runtime software,” (Accessed on 2021/05/08). [Online]. Available:
https://katacontainers.io/[8] T. gVisor Authors, “gvisor,” 2021, (Accessed on 2021/05/08). [Online].
Available: https://gvisor.dev/[9] E. G. Young, P. Zhu, T. Caraza-Harter, A. C. Arpaci-Dusseau, and R. H.
Arpaci-Dusseau, “The true cost of containing: A gvisor case study,” in11th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud19). Renton, WA: USENIX Association, Jul. 2019.
[10] Y. Nakata, S. Suzuki, and K. Matsubara, “Reducing attack surface withcontainer transplantation for lightweight sandboxing,” in Proc. of the
14th ACM SIGOPS Asia-Pacific Workshop on Systems, 2023, pp. 58–
64.
[11] T. D. Ngoc, B. Teabe, A. Tchana, G. Muller, and D. Hagimont,“Mitigating vulnerability windows with hypervisor transplant,” inProceedings of the Sixteenth European Conference on Computer
Systems, ser. EuroSys ’21. New York, NY, USA: Association
for Computing Machinery, 2021, p. 162–177. [Online]. Available:
https://doi.org/10.1145/3447786.3456235[12] K. Matsubara and Y. Takagawa, “Adaptive os switching for improving
availability during web traffic surges: A feasibility study,” in Proc.
of 2020 IEEE 44th Annual Computers, Software, and Applications
Conference (COMPSAC), 2020, pp. 1176–1182.
[13] “LinuxApps
FreeBSDWiki—
wiki.freebsd.org,”
https://wiki.freebsd.org/LinuxApps, [Accessed 11-12-2023].