From 5b952068b76ca0f08432847e7a3300d1dd6f6de3 Mon Sep 17 00:00:00 2001 From: Jeremy Lin Date: Thu, 11 Jun 2020 16:39:30 -0700 Subject: [PATCH] Docker hardening updates --- Hardening-Guide.md | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/Hardening-Guide.md b/Hardening-Guide.md index f195e43..1fe3665 100644 --- a/Hardening-Guide.md +++ b/Hardening-Guide.md @@ -35,13 +35,18 @@ The subsections below cover hardening related to Docker. ## Run as a non-root user -The bitwarden_rs Docker image is configured to run the container process as the `root` user by default. This allows bitwarden_rs to read/write any data [bind-mounted](https://docs.docker.com/storage/bind-mounts/) into the container without permission issues, even if that data is owned by another user (e.g., your user account on the Docker host). As a general policy, it's better security-wise to run processes with the minimum privileges required, though this is somewhat less of a concern with programs written in a memory-safe language like Rust. +The bitwarden_rs Docker image is configured to run the container process as the `root` user by default. This allows bitwarden_rs to read/write any data [bind-mounted](https://docs.docker.com/storage/bind-mounts/) into the container without permission issues, even if that data is owned by another user (e.g., your user account on the Docker host). +The default configuration provides a good balance of security and usability -- running as root within an unprivileged Docker container provides a reasonable level of isolation on its own, while also making setup easier for users who aren't necessarily well-versed in how to manage ownership/permissions on Linux. However, as a general policy, it's better security-wise to run processes with the minimum privileges required; this is somewhat less of a concern with programs written in a memory-safe language like Rust, but note that bitwarden_rs does also use some library code written in C (SQLite, OpenSSL, MySQL, PostgreSQL, etc.). To run the container process (bitwarden_rs) as a non-root user (uid/gid 1000) in Docker: - docker run -u 1000:1000 -e ROCKET_PORT=8080 -p :8080 [...other args...] bitwardenrs/server:latest + docker run -u 1000:1000 -e ROCKET_PORT=8080 -p :8080 \ + [...other args...] \ + bitwardenrs/server:latest -The default user in many Linux distros has uid/gid 1000 (run the `id` command to verify), so this is a good value to use if you prefer to be able to easily access your bitwarden_rs data without changing to another user, but you can adjust the uid/gid as needed. `ROCKET_PORT` defaults to 80, and needs to be 1024 or higher when running as a non-root user. +The default user in many Linux distros has uid/gid 1000 (run the `id` command to verify), so this is a good value to use if you prefer to be able to easily access your bitwarden_rs data without changing to another user, but you can adjust the uid/gid as needed. Note that you'll most likely need to specify a numeric uid/gid, because the bitwarden_rs container doesn't share the same mapping of user/group names to uid/gid (e.g., compare the `/etc/passwd` and `/etc/group` files in the container to the ones on the Docker host). + + `ROCKET_PORT` defaults to 80, which is a [privileged port](https://www.w3.org/Daemon/User/Installation/PrivilegedPorts.html); it needs to be 1024 or higher when running as a non-root user, or else you'll get a permission denied error when bitwarden_rs attempts to bind and listen for connections on that port. To do the same in `docker-compose`: @@ -52,9 +57,11 @@ To do the same in `docker-compose`: user: 1000:1000 environment: - ROCKET_PORT=8080 - + ... other configuration ... +Since `ROCKET_PORT` is being changed here, make sure to also update your reverse proxy config to proxy bitwarden_rs traffic to port 8080 (or whatever higher port you chose) instead of 80. + ## Mounting data into the container Generally, only data that bitwarden_rs needs to operate properly should be mounted into the bitwarden_rs container (typically, this is just your data directory, and maybe a directory containing SSL/TLS certs and private keys). For example, don't mount your entire home directory, `/var/run/docker.sock`, etc. unless you have a specific reason and know what you're doing.