Hello again I'm Dustin Kirkland and I'm joined this time by Ian Lewis, Developer Advocate
at Google.
He is going to tell us a little about a new open source container isolation sandbox called
gVisor.
Right, so gVisor is a sandbox isolation project for containers.
It provides a lightweight execution mode for containers, but also gives you very secure
isolation between those containers.
It's really all about the security isn't it?
Exactly, so for things like containers they provide isolation in the form of namespaces
and c groups and as a feature of the Linux kernel but you are exposed to kernel bugs
and things like that and unforeseen issues as where they are to the Linux kernel, so
if any sort of new bug happens or that type of thing a zero day happens you are exposed
to that and so what this does is actually helps you mitigate those type of issues.
Right, it reduces the surface, as I understand it, right?
Right.
So it actually provides a separate layer in between the running application and the Linux
kernel,.
And what is that layer?
So that layer is actually a user space implementation or user space kernel so to be a little bit
detailed it implements a lot of Linux or most of the Linux syscalls and then provides user
space virtualization for the container.
Cool.
And you've got a demo for us today?
Tell us a little about this demo and how it's going to work.
Yes, this particular demo is going to show a kernel vulnerability and what we are going
to do is we are going to show how that vulnerability can be used to break out of the container
and then out of a normal container that is a Linux container that's using namespaces
and how that can actually be mitigated when using something like - or when using gVisor.
And this is a real vulnerability, not something that you've instrumented?
Right.
This is a vulnerability that has since been patched obviously but it's one that if it
was released to it would have been Sure, it would have been protected better by gVisor.
By gVisor, exactly.
Interesting.
So what we are going to do is we are going to take advantage of the dirty cow vulnerability
in the Linux kernel.
What I have here is an OCI image or an OCI bundle and in the configuration here we've
got the UID and GID set to a user and here we're going to run a dirty cow vulnerability
and this is going to write to a file that is controlled by root from a user from within
a container.
So when they run this using runc, this takes a little while but what's happening here is
that we are doing a couple syscalls in parallel in order to trigger a race condition in the
Linux Kernel and that's going to allow us to write to a file that's controlled by root
and effectively get a privilege escalation.
Okay, so the exploit has run and so what we're going to do here is we're going to check the
file that we're going to write to.
So here we were trying to write to the password file and in this case our particular exploit
wrote to the beginning of the password file.
So here you can imagine that you can write an entirely new line for our road user and
give a new password and essentially get privilege escalation.
So, what we're going to do here is we're going to run the exact same vulnerability in the
gVisor sandbox so here I have the exact same OCI bundle, so we'll look at the config.
Here we have the exact same user ID setup, UID and GID, as well as the same exploit that
we're going to try to run here.
And so what we'll do is we'll use the runsc command to invoke gVisor and we'll run this
with the ptrace and strace commands and what this will do is allow us to see the syscalls
that are being made by the exploit.
Here we can see a lot of debug.
This particular exploit is running, is calling the syscalls in a loop.
In a tight loop in two different threads and so we can see those syscalls being made here
being intercepted by gVisor.
Because we have this extra layer between the application and the Linux kernel here the
gVisor provides, we can intercept those and prevent the vulnerability from actually happening.
So now we've dropped out of the command and we're just going to take a look at our password
file to see if it has actually been written to.
So here we're going to look at the contents of the file and we can see here that the exploit
was not actually able to write to the file.
So that's super interesting actually, if a user interested in downloading gVisor, maybe
running it today, what's the minimum requirements.
How does someone get started?
Right now it's a normal open source project so we have that released on GitHub so you
can check that out and compile and run gVisor on your own it's very similar in the end to
runc in the sense that it provides two things - it provides a kind of library that you can
use to run sandbox containers as well a command called runsc which is very similar to runc
in the sense that it's a drop in, kind of replacement for runc so you can use things
like Docker to actually run a container.
Okay, great.
And if someone wants to contribute to this project?
It's an open source project as much as Kubernetes is an open source project?
Sure, absolutely, so you can contribute to the project by engaging with us through GitHub
and submitting issues and patches there and joining in the community by providing feedback
through GitHub.
That's great, thanks Ian.