diff options
-rw-r--r-- | content/blog/1_security_basics/index.md | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/content/blog/1_security_basics/index.md b/content/blog/1_security_basics/index.md index cbcdc1b61..afbd6ca7e 100644 --- a/content/blog/1_security_basics/index.md +++ b/content/blog/1_security_basics/index.md @@ -21,7 +21,7 @@ Future posts will address _resource efficiency_ (how gVisor preserves container Delivering on each of these goals requires careful security considerations and a robust design. -## What does “sandbox" mean? +## What does "sandbox" mean? gVisor allows the execution of untrusted containers, preventing them from adversely affecting the host. This means that the untrusted container is prevented from attacking or spying on either the host kernel or any other peer userspace processes on the host. @@ -62,7 +62,7 @@ In order to discuss design principles, the following components are important to It is important to emphasize what is being protected from the untrusted application in this diagram: the host OS and other userspace applications. -In this post, we are only discussing security-related features of gVisor, and you might ask, “What about performance, compatibility and stability?" We will cover these considerations in future posts. +In this post, we are only discussing security-related features of gVisor, and you might ask, "What about performance, compatibility and stability?" We will cover these considerations in future posts. ## Defense-in-Depth @@ -73,7 +73,7 @@ It may seem strange that we would want our own software components to distrust e And this leads us to how Defense-in-Depth is applied to gVisor: no single vulnerability should compromise the host. -In the “Attacker’s Advantage / Defender’s Dilemm +In the "Attacker’s Advantage / Defender’s Dilemm ____ ![Figure 2](./figure2.png) @@ -149,11 +149,11 @@ At a higher level, boundaries in software might be describing a great many thing Security boundaries are interfaces that are designed and built so that entire classes of bugs/vulnerabilities are eliminated. -For example, the Sentry and Gofers are implemented using Go. Go was chosen for a number of the features it provided. Go is a fast, statically-typed, compiled language that has efficient multi-threading support, garbage collection and a constrained set of “unsafe" operations. +For example, the Sentry and Gofers are implemented using Go. Go was chosen for a number of the features it provided. Go is a fast, statically-typed, compiled language that has efficient multi-threading support, garbage collection and a constrained set of "unsafe" operations. Using these features enabled safe array and pointer handling. This means entire classes of vulnerabilities were eliminated, such as buffer overflows and use-after-free. -Another example is our use of very strict syscall switching to ensure that the Sentry is always the first software component that parses and interprets the calls being made by the untrusted container. Here is an instance where different platforms use different solutions, but all of them share this common trait, whether it is through the use of ptrace “a la PTRACE_ATTACH"[^11] or kvm’s ring0[^12]. +Another example is our use of very strict syscall switching to ensure that the Sentry is always the first software component that parses and interprets the calls being made by the untrusted container. Here is an instance where different platforms use different solutions, but all of them share this common trait, whether it is through the use of ptrace "a la PTRACE_ATTACH"[^11] or kvm’s ring0[^12]. Finally, one of the most restrictive choices was to use seccomp, to restrict the Sentry from being able to open or create a file descriptor on the host. All file I/O is required to go through Gofers. Preventing the opening or creation of file descriptions eliminates whole categories of bugs around file permissions [like this one](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4557)[^13]. |