Perhaps we should start by explaining what a sandbox is. No, its that box on the beach that has sand in it, but that is a pretty good visualization of a virtual sandbox. It is a container that one can work within that may have limited or restricted access to critical parts of the operating system.
So, why would we want to limit ourselves?
To be truthful, we don’t voluntarily ever really want to limit ourselves. But … we want to limit those unruly apps that we may have just downloaded ( Yeah, you really shouldn’t you know ). These are the apps that in a moment of weakness, we decided to trust then the app lets us down and now we have a ransomware situation.
So, these sandboxes are partitions within our work spaces that have restrictions placed on them to protect us from mistakes that might actually be unintentional ( Your own developers creating an application that ends up having memory leaks ) or at home, perhaps your child getting on your computer and downloading a game his friend just told him about. That game may have a virus simply waiting for the right moment to be activated months later.
That virus may do you and your computer no direct harm, but may act as a gateway perhaps into the VPN for your workplace.
Hence the need for sandboxes, places where we can either play safely or create stronger security in order to slow down hackers so that you can have a look at their hacking efforts, ha ha.
Google has released gVisor, a new kind of sandbox that can be used to provide secure isolation for containers that is less resource intensive than running a full virtual machine (VM). At its core, gVisor is an open source user-space kernel that implements a substantial portion of the Linux system surface. It is written in Go and designed with different trade-offs than existing container technology. The project includes an Open Container Initiative (OCI) runtime called “runsc” that integrates with Docker and Kubernetes.
The gVisor project GitHub README states that the core of gVisor is a kernel that runs as a normal, unprivileged process that supports most Linux system calls. Just like within a VM, an application running in a gVisor sandbox gets its own kernel and set of virtualized devices, distinct from the host and other sandboxes. gVisor provides a strong isolation boundary by intercepting application system calls and acting as the guest kernel, and can be thought of as an extremely paravirtualized operating system with a “flexible resource footprint and lower fixed cost than a full VM”. However, this flexibility has associated tradeoffs with performance and compatability: gVisor may provide poor performance for system call heavy workloads; and although gVisor implements a large part of the Linux system API (currently 200 system calls), several system calls and arguments are not supported (and neither are some parts of the /proc and /sys filesystems), which means that not all applications will run inside gVisor.