2

Can --cap-add SYS_CHROOT on a docker container be questioned as a potential security risk, and why?

I'm seeking references and information from security professionals about using the chroot tool (and the SYS_CHROOT Linux capability) inside a docker container.

(background) I'm developing an application to run inside a Docker container; the application receives requests from various users; each request is allocated a working directory with files and requires a third-party command line tool; isolation of users and requests must be guaranteed. Specifically, a threat actor may submit a request that tries to read or override files of other users or previous requests; this may seem like a matter of fundamental path validation, but it's not: the third-party tool can be trusted, but its user-provided configuration is complex, cannot be analyzed by my application, cannot be trusted and cannot be validated either. There may be other risks, but I'm focused on isolating the working directory allocated to the request. Then chroot would be perfect, as the assigned working directory would be my fake root.

I may be confused by various sources I've found telling me that:

  1. A compromised application may use techniques to escape a chroot jail, so if this risk has to be considered authentic, then chroot may not be regarded as an appropriate and secure solution.
  2. There is news about Unprivileged chroot: a patch on recent kernel versions that may make Chroot safe against previous escape techniques (and available to unprivileged users, without SYS_CHROOT), invalidating the above point (1).
  3. The same news from above discusses the patch and says that chroot is obsolete, so the patch may even be rejected, reverted in future versions, or adopted with differences depending on the Linux distribution (e.g., Debian vs. others).
  4. Some users and blog posts tell me that to use chroot inside a docker container, I need to specify --cap-add SYS_CHROOT...
  5. The docker documentation says that the SYS_CHROOT capability is granted by default (maybe only from recent versions after the above patch). I can use chroot from a Debian Docker without any --cap-add.
  6. A blog post suggesting to explicitly drop the SYS_CHROOT capability for better security.

For sure, any solution is better than having no isolation method. Still, it looks like adopting and configuring my system to allow me to use chroot may decrease the whole system's security.

1 Answer 1

1

first to look at SYS_CHROOT, it's correct to say that it is enabled inside a default docker container. We can confirm this with amicontained (scroll the window below to the right to see that cap :) )

docker run -it raesene/alpine-containertools /bin/bash
bash-5.1# amicontained
Container Runtime: not-found
Has Namespaces:
        pid: true
        user: false
AppArmor Profile: docker-default (enforce)
Capabilities:
        BOUNDING -> chown dac_override fowner fsetid kill setgid setuid setpcap net_bind_service net_raw sys_chroot mknod audit_write setfcap
...

In terms of the risks, it's not likely to allow for container breakout, as we only have that capability inside the containers namespaces.

All that said reading your initial problem statement, if you have untrusted data from different users, I'd be inclined to spin up a new container for each user, mount their data into that container, run your process and then remove the container. One of the benefits of containerization is that there's a relatively low overhead to starting new instances, so it can make sense to start a clean environment for each one.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .