One critical attack that exploits kernel vulnerabilities through system call invocations is considered a serious threat to container security since it results in the privilege escalation followed by the infamous container escape. The seccomp kernel feature provides the first line of defense against it. Further, secure container runtimes such as gVisor also make use of it to strengthen security. However, it is known to be brittle since it operates at the granularity of the individual system call. Inadvertent filtering of necessary system calls may inhibit the correct execution while overly generous rules allow the attacks. We believe that, by looking at the sequence of system calls, we can achieve more accurate and effective blocking of attacks in containers. To this end, we built a software tool, Nimos, that performs a combination of static and dynamic analyses of exploit codes in an automated way and investigated the existence of such commonly occurring system call sequences. Then, we analyzed the expected defensive power from applying the sequence-based filtering mechanisms using a large set of collected kernel vulnerabilities to assess the feasibility. We found that there exist a significant number and forms of commonly appearing system call sequences that can be used as a clear signature of the class of attacks. We characterize these common system call sequences that exist among the exploit codes and evaluate the expected effectiveness of a sequence-based system call filtering mechanism for containers.

Container-based clouds—in which containers are the basic unit of isolation—face security concerns because, unlike Virtual Machines, containers directly interface with the underlying highly privileged kernel through the wide and vulnerable system call interface. Regardless of whether a container itself requires dangerous system calls, a compromised or malicious container sharing the host (a bad neighbor) can compromise the host kernel using a vulnerable syscall, thereby compromising all other containers sharing the host.

The emergence of verified eBPF bytecode is ushering in a new era of safe kernel extensions. In this paper, we argue that eBPF's verifier---the source of its safety guarantees---has become a liability. In addition to the well-known bugs and vulnerabilities stemming from the complexity and ad hoc nature of the in-kernel verifier, we highlight a concerning trend in which escape hatches to unsafe kernel functions (in the form of helper functions) are being introduced to bypass verifier-imposed limitations on expressiveness, unfortunately also bypassing its safety guarantees. We propose safe kernel extension frameworks using a balance of not just static but also lightweight runtime techniques. We describe a design centered around kernel extensions in safe Rust that will eliminate the need of the in-kernel verifier, improve expressiveness, allow for reduced escape hatches, and ultimately improve the safety of kernel extensions.

This paper presents Protected Execution Facility (PEF), a virtual machine-based Trusted Execution Environment (TEE) for confidential computing on Power ISA. PEF enables protected secure virtual machines (SVMs). Like other TEEs, PEF verifies the SVM prior to execution. PEF utilizes a Trusted Platform Module (TPM), secure boot, and trusted boot as well as newly introduced architectural changes for Power ISA systems. Exploiting these architectural changes requires new firmware, the Protected Execution Ultravisor. PEF is supported in the latest version of the POWER9 chip. PEF demonstrates that access control for isolation and cryptography for confidentiality is an effective approach to confidential computing. We particularly focus on how our design (i) balances between access control and cryptography, (ii) maximizes the use of existing security components, and (iii) simplifies the management of the SVM life cycle. Finally, we evaluate the performance of SVMs in comparison to normal virtual machines on OpenPOWER systems.