Hardware virtualization is often seen as a requirement to provide an additional isolation layer for untrusted applications. However, hardware virtualization requires expensive bare-metal machines or cloud instances to run safely with good performance, increasing cost and complexity for Cloud users. gVisor, however, takes a more flexible approach.
In the previous two posts we talked about gVisor’s security design principles as well as how those are applied in the context of networking. Recently, a new container escape vulnerability (CVE-2020-14386) was announced that ties these topics well together. gVisor is not vulnerable to this specific issue, but it provides an interesting case study to continue our exploration of gVisor’s security. While gVisor is not immune to vulnerabilities, we take several steps to minimize the impact and remediate if a vulnerability is found.
In our first blog post, we covered some secure design principles and how they guided the architecture of gVisor as a whole. In this post, we will cover how these principles guided the networking architecture of gVisor, and the tradeoffs involved. In particular, we will cover how these principles culminated in two networking modes, how they work, and the properties of each.
This blog is a space for engineers and community members to share perspectives and deep dives on technology and design within the gVisor project. Though our logo suggests we’re in the business of space exploration (or perhaps fighting sea monsters), we’re actually in the business of sandboxing Linux containers. When we created gVisor, we had three specific goals in mind; container-native security, resource efficiency, and platform portability. To put it simply, gVisor provides efficient defense-in-depth for containers anywhere.