Giving a sandbox CAP_SYS_ADMIN

[Ryan Nguyen]

Hi,

I'm one of the engineers working on container runtimes at Modal and am currently investigating the usage of Docker inside gVisor. We saw that giving CAP_SYS_ADMIN and CAP_SYS_NET to the sandbox is required for it to work and wanted to ask a few questions about the security implications of doing so:

1. Does granting CAP_SYS_ADMIN to the sandbox give admin capabilities with respect to the host? If we understand correctly, the host does not see the runsc-sandbox process as having admin capabilities.
2. How does granting CAP_SYS_ADMIN increase the vulnerable surface of the sandbox?
3. In general, is there a downside with gVisor to granting more capabilities from a security perspective?

Cheers,

Ryan

[Guillaume Seguin]

I'm unclear about the stack you are running. The sandbox here would be gVisor I assume?

You can run gVisor without `CAP_SYS_ADMIN` if you use the `--rootless` option. It makes it possible to run it as an unprivileged user, but you don't get all of the security features. Knowing that gVisor will drop its privileges before actually running the sandboxee, I would rather recommend making an entry for `runsc` in your sudoers file.

Are you trying to:

1. Running gVisor on its own with `runsc` at the command line, and then run Docker in it? (https://gvisor.dev/docs/tutorials/docker-in-gvisor/)
2. Running Docker with gVisor as the runtime, and want to run another Docker in it? (http://gvisor.dev/docs/user_guide/quick_start/docker/)

--

Guillaume

[Ryan Nguyen]

Yes, the sandbox is gVisor. We're not doing 2, instead we're running runsc create and the users will be running docker inside our gVisor sandbox.

Here are the changes we needed to make to the `oci_template.yaml` used for creating the oci bundle.

We are wondering if adding these capabilities will compromise the host's security.

For example, if the sandboxee (untrusted application) calls the mount syscall, given by CAP_SYS_ADMIN, the sentry will intercept this call and will not emit a mount syscall to the host because the sentry does not have CAP_SYS_ADMIN with respect to the host. Is my understanding correct?

Ryan

[Ryan Nguyen]

If there is any misunderstandings, we'd love to hop on a call to discuss!

[Etienne Perot]

> if the sandboxee (untrusted application) calls the mount syscall, given by CAP_SYS_ADMIN, the sentry will intercept this call and will not emit a mount syscall to the host because the sentry does not have CAP_SYS_ADMIN with respect to the host. Is my understanding correct?

Correct. Capabilities listed in the capability set of the container spec passed to runsc do not translate to any capabilities on the host kernel. They only change the set of capabilities that the sandboxed workload has within the gVisor userspace kernel. You can verify this by looking at the Capabilities field of the host's /proc/[PID of `runsc boot`]/status, where you should see that this set does not expand regardless of which capabilities you specify in the container spec. But if you look at the Capabilities field of /proc/1/status inside the sandbox (which you can do for example by running runsc exec), you'll see that that one is growing.

So your application does have CAP_SYS_ADMIN permission against the gVisor kernel, while the gVisor process itself does not have CAP_SYS_ADMIN against the host kernel. The application's mount syscall will succeed, because it is modifying the gVisor-kernel-internal mount tree that the sandboxed application is perceiving as its own reality. The state of mounts on the host will not change, and cannot change anyway because the gVisor process doesn't have the host kernel permissions to do so.

--
You received this message because you are subscribed to the Google Groups "gVisor Users [Public]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gvisor-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/gvisor-users/4c7441df-5d9a-46f5-9cf8-cb631d7945ban%40googlegroups.com.