Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it Possible to add gVisor Support to minimize the risk of an container escape exploit? #126

Closed
Anish-M-code opened this issue Sep 11, 2021 · 5 comments · Fixed by #590

Comments

@Anish-M-code
Copy link

Anish-M-code commented Sep 11, 2021

@micahflee @mikaelf @haplo @legoktm @mig5 @deeplow gVisor ( https://gvisor.dev/ ) provides a virtualized environment in order to sandbox containers. The system interfaces normally implemented by the host kernel are moved into a distinct, per-sandbox application kernel in order to minimize the risk of an container escape exploit.

Sorry, If it is a dumb question, But as far as i see being OCI and runsc ,podman should be compatible with gvisor , so adding support for gVisor might help increase security. Is it possible with dangerzone or will there be any possible issues with this approach on linux?

Incase if gvisor is compatible i guess it might be useful for high risk users.

@apyrgio
Copy link
Contributor

apyrgio commented Nov 15, 2022

Hi @Anish-M-code! This is not a dumb question at all. In fact, making syscalls more difficult to exploit is one of the goals for this release, and our plan is to start working on this via stricter seccomp filters: #225. Now, one of gVisor's main selling points is the fact that they provide an emulation layer between the Linux Kernel and the application, which also aids in syscall hardening, complimentary to seccomp filters. So, this is indeed very important for this project.

Having said that, my biggest concern is not integration with Podman (Linux users), but Docker Desktop (Windows and MacOS users). Ideally, we want to protect as many users as possible, and seccomp filters are a multi-platform way to do that. With gVisor several questions arise:

  • Is it compatible with Docker Desktop?
  • Can it run in M1 Macs?
  • Does it require manual steps by the user to enable it?

These are some of the things we need to consider before we start experimenting with it.

@apyrgio
Copy link
Contributor

apyrgio commented Nov 15, 2022

Also, an interesting route is using gVisor within the container. This is not a typical way to use gVisor, but it's multi-platform and is a solid start. I have actually verified that the following works from within a container:

$ runsc -ignore-cgroups -network none -rootless do echo ok
ok

@apyrgio
Copy link
Contributor

apyrgio commented Nov 16, 2022

Stumbling into an issue when running gVisor in rootless Podman:

$ runsc -debug -network none -rootless do echo ok
Error reading mounts file: error unmarshaling mounts: unexpected end of JSON input
JSON bytes:

creating container: cannot create sandbox: cannot read client sync file: waiting for sandbox to start: EOF

It seems that the underlying Gopher process does not properly read the mounts for the container.


EDIT: I have opened a relevant issue in the gVisor repo: google/gvisor#8205

@apyrgio
Copy link
Contributor

apyrgio commented Dec 11, 2023

Update regarding the upstream issue. It seems that the devs have a fix for this bug (google/gvisor#8205 (comment)), which paves the way to use rootless gvisor within rootless Podman.

@apyrgio
Copy link
Contributor

apyrgio commented Jun 10, 2024

I have some exciting news in this front! Dangerzone will be integrated with gVisor very soon. Keep an eye on #590...

apyrgio pushed a commit that referenced this issue Jun 10, 2024
This wraps the existing container image inside a gVisor-based sandbox.

gVisor is an open-source OCI-compliant container runtime.
It is a userspace reimplementation of the Linux kernel in a
memory-safe language.

It works by creating a sandboxed environment in which regular Linux
applications run, but their system calls are intercepted by gVisor.
gVisor then redirects these system calls and reinterprets them in
its own kernel. This means the host Linux kernel is isolated
from the sandboxed application, thereby providing protection against
Linux container escape attacks.

It also uses `seccomp-bpf` to provide a secondary layer of defense
against container escapes. Even if its userspace kernel gets
compromised, attackers would have to additionally have a Linux
container escape vector, and that exploit would have to fit within
the restricted `seccomp-bpf` rules that gVisor adds on itself.

Fixes #126
Fixes #224
Fixes #225
Fixes #228
EtiennePerot added a commit to EtiennePerot/dangerzone that referenced this issue Jun 12, 2024
This wraps the existing container image inside a gVisor-based sandbox.

gVisor is an open-source OCI-compliant container runtime.
It is a userspace reimplementation of the Linux kernel in a
memory-safe language.

It works by creating a sandboxed environment in which regular Linux
applications run, but their system calls are intercepted by gVisor.
gVisor then redirects these system calls and reinterprets them in
its own kernel. This means the host Linux kernel is isolated
from the sandboxed application, thereby providing protection against
Linux container escape attacks.

It also uses `seccomp-bpf` to provide a secondary layer of defense
against container escapes. Even if its userspace kernel gets
compromised, attackers would have to additionally have a Linux
container escape vector, and that exploit would have to fit within
the restricted `seccomp-bpf` rules that gVisor adds on itself.

Fixes freedomofpress#126
Fixes freedomofpress#224
Fixes freedomofpress#225
Fixes freedomofpress#228
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants