From d4909507a0bd687f5ff6d5c04449e18e9e954ba8 Mon Sep 17 00:00:00 2001 From: Wonderfall Date: Thu, 31 Mar 2022 04:01:50 +0200 Subject: [PATCH] improvement --- content/posts/docker-hardening.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/docker-hardening.md b/content/posts/docker-hardening.md index 928dc70..9f6f9b1 100644 --- a/content/posts/docker-hardening.md +++ b/content/posts/docker-hardening.md @@ -83,7 +83,7 @@ root can be avoided in different ways in the final container: - Container creation time: via the tools available (`user:` in the Compose file). - Container runtime: degrading privileges with entrypoints scripts (`gosu UID:GID`). -Well-made images with security in mind will have a `USER` instruction. In my experience, most people will run images blindly, so it's good harm reduction. Setting the user manually works in some images that aren't designed without root in mind, and it's also great to mitigate some *scenarii* where the image is controlled by an attacker. You also won't have surprises when mounting volumes, so I highly recommend setting the user explicitly and make sure volume permissions are correct once. Some images allow users to define their own UID/GID user with environment variables, with an entrypoint script that runs as root and takes care of the volume permissions before dropping privileges. While technically fine, it is still attack surface, and it requires the `SETUID`/`SETGID` capabilities to be available in the container. +Well-made images with security in mind will have a `USER` instruction. In my experience, most people will run images blindly, so it's good harm reduction. Setting the user manually works in some images that aren't designed without root in mind, and it's also great to mitigate some *scenarii* where the image is controlled by an attacker. You also won't have surprises when mounting volumes, so I highly recommend setting the user explicitly and make sure volume permissions are correct once. Some images allow users to define their own user with UID/GID environment variables, with an entrypoint script that runs as root and takes care of the volume permissions before dropping privileges. While technically fine, it is still attack surface, and it requires the `SETUID`/`SETGID` capabilities to be available in the container. ### User namespaces: sandbox or paradox? As mentioned just above, [user namespaces](https://www.man7.org/linux/man-pages/man7/user_namespaces.7.html) are a solution to ensure root in the container is not root on the host. Docker supports user namespaces, for instance you could set the default mapping in `/etc/docker/daemon.json`: