Defense in Depth - Prevent attacker from becoming root within the container #224
Labels
Milestone
Comments
This was referenced Oct 17, 2022
|
4.3 can be considered part of the scope of #232. |
|
I agree and I updated the issue description. This issue should not close as long as #232 is open. |
|
With the integration of Dangerzone with gVisor, we can now close this issue. Some requirements are not yet satisfied (such as the removal of the |
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
Parent issue: #221
Once an attacker has found a flaw that allows them to take control of a process (see #222), they will probably attempt to become root within the container. Currently, this is not easy for two reasons:
dangerzone, UID 1000).--security-opt=no-new-privileges, so the kernel does not allow a process to elevate their privileges.However, it may be worth ensureing that it's not easy to become root in the container, even if this safeguard does not manage to work. For an extra layer of security, we could follow the latest CIS Docker advisories (official link, mirror).
Because the advisories are numerous, there are tools that check if a container image/runtime complies with the advisories:
I have already ran these two tools on Windows and Linux, and the noteworthy sections that were reported are the following:
sudo, which is not used and can be removed.We can easily placate section 4.8 by removing
sudo, and section 5.12 by running thepodman/dockercommand with the--read-onlyflag. The 4.3 section requires a bit more digging and is tracked in #232.The text was updated successfully, but these errors were encountered: