Lissy, here you go:

# docker-compose logs -f
Attaching to Dashy
Dashy    | yarn run v1.22.15
Dashy    | warning Skipping preferred cache folder "/.cache/yarn" because it is not writable.
Dashy    | warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-3005".
Dashy    | $ npm-run-all --parallel build-watch start
Dashy    | warning Cannot find a suitable global folder. Tried these: "/usr/local, /.yarn"
Dashy    | warning Skipping preferred cache folder "/.cache/yarn" because it is not writable.
Dashy    | warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-3005".
Dashy    | warning Skipping preferred cache folder "/.cache/yarn" because it is not writable.
Dashy    | warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-3005".
Dashy    | $ node server
Dashy    | $ vue-cli-service build --watch --mode production
Dashy    | warning Cannot find a suitable global folder. Tried these: "/usr/local, /.yarn"
Dashy    | warning Cannot find a suitable global folder. Tried these: "/usr/local, /.yarn"
Dashy    | 
Dashy    | Checking config file against schema...
Dashy    | No issues found, your configuration is valid :)
Dashy    | 
Dashy    | SSL Not Enabled: Public key not present
Dashy    | 
Dashy    | 
Dashy    |  ██████╗  █████╗ ███████╗██╗  ██╗██╗   ██╗
Dashy    |  ██╔══██╗██╔══██╗██╔════╝██║  ██║╚██╗ ██╔╝
Dashy    |  ██║  ██║███████║███████╗███████║ ╚████╔╝
Dashy    |  ██║  ██║██╔══██║╚════██║██╔══██║  ╚██╔╝
Dashy    |  ██████╔╝██║  ██║███████║██║  ██║   ██║
Dashy    |  ╚═════╝ ╚═╝  ╚═╝╚══════╝╚═╝  ╚═╝   ╚═╝
Dashy    | 
Dashy    | *******************************************************************************************
Dashy    | Welcome to Dashy! 🚀
Dashy    | Your new dashboard is now up and running with Docker
Dashy    | After updating your config file, run  'docker exec -it [container-id] yarn build' to rebuild
Dashy    | *******************************************************************************************
Dashy    | 
Dashy    | 
Dashy    | Using Dashy V-1.9.2. Update Check Complete
Dashy    | ✅ Dashy is Up-to-Date
Dashy    | 
Dashy    | 
Dashy    | -  Building for production...
Dashy    |  WARN  A new version of sass-loader is available. Please upgrade for best experience.
Dashy    |  ERROR  Error: EACCES: permission denied, rmdir '/app/dist'
Dashy    | Error: EACCES: permission denied, rmdir '/app/dist'
Dashy    | error Command failed with exit code 1.
Dashy    | info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Dashy    | ERROR: "build-watch" exited with 1.
Dashy    | error Command failed with exit code 1.
Dashy    | info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Tested on a RHEL 8 based host (functionally the same as CentOS 8, Rocky Linux 8, etc) with Docker CE. Also verified that the issue exists with SELinux policy enforcement disabled.

Could you please provide a sanitized copy of your compose file or Docker options? Also a procps/ps output displaying the container processes, which is the only effective way to prove that the container is indeed running unprivileged.

Also, you must take into account that the only real safe way to operate a Docker container under the privileges of an unprivileged user is to start it already as that user. Dropping privileges and capabilities on runtime is a tricky game, and often any leftover privileges can be used to re-escalate.

You can find a very extensive look at this issue here:
https://wiki.sei.cmu.edu/confluence/display/c/POS36-C.+Observe+correct+revocation+order+while+relinquishing+privileges

Now, back to our issue with Dashy: so far, nothing I have observed, using the compose file suggested, or the arguments in the documentation you provide, results in effective privilege removal:

root      281366  0.0  0.2 711960  9380 ?        Sl   12:01   0:00 /usr/bin/containerd-shim-runc-v2 -namespace moby -id XXX -address /run/containerd/containerd.sock
root      281386  3.7  1.8 320356 69944 ?        Ssl  12:01   0:00 node /opt/yarn-v1.22.15/bin/yarn.js build-and-start
root      281456  3.0  1.1 288832 42332 ?        Sl   12:01   0:00 /usr/local/bin/node /app/node_modules/.bin/npm-run-all --parallel build-watch start
root      281467  4.4  1.8 320392 69520 ?        Sl   12:01   0:00 /usr/local/bin/node /opt/yarn-v1.22.15/bin/yarn.js run build-watch
root      281468  4.4  1.8 320140 70016 ?        Sl   12:01   0:00 /usr/local/bin/node /opt/yarn-v1.22.15/bin/yarn.js run start
root      281489  7.7  1.4 305500 56384 ?        Sl   12:01   0:00 /usr/local/bin/node server
root      281490  118  5.1 432836 196540 ?       Rl   12:01   0:13 /usr/local/bin/node /app/node_modules/.bin/vue-cli-service build --watch --mode production
root      281513 48.0  2.9 358140 113284 ?       Ssl  12:01   0:03 /usr/local/bin/node /app/node_modules/thread-loader/dist/worker.js 20
root      281535 56.8  2.6 343732 101908 ?       Ssl  12:01   0:03 /usr/local/bin/node /app/node_modules/thread-loader/dist/worker.js 20
root      281541 53.8  2.7 345824 104636 ?       Ssl  12:01   0:03 /usr/local/bin/node /app/node_modules/thread-loader/dist/worker.js 20

Once the build completes, the situation is the same:

root      281386  0.5  1.5 309656 59676 ?        Ssl  12:01   0:00 node /opt/yarn-v1.22.15/bin/yarn.js build-and-start
root      281456  0.3  1.1 288832 42180 ?        Sl   12:01   0:00 /usr/local/bin/node /app/node_modules/.bin/npm-run-all --parallel build-watch start
root      281467  0.6  1.5 310192 59964 ?        Sl   12:01   0:00 /usr/local/bin/node /opt/yarn-v1.22.15/bin/yarn.js run build-watch
root      281468  0.5  1.5 310208 59948 ?        Sl   12:01   0:00 /usr/local/bin/node /opt/yarn-v1.22.15/bin/yarn.js run start
root      281489  0.8  1.4 305568 56388 ?        Sl   12:01   0:00 /usr/local/bin/node server
root      281490 56.7  5.8 445300 223408 ?       Sl   12:01   0:55 /usr/local/bin/node /app/node_modules/.bin/vue-cli-service build --watch --mode production

The compose file used to produce the above output:

---
version: "3.8"
services:
  dashy:
    # To build from source, replace 'image: lissy93/dashy' with 'build: .'
    # build: .
    image: lissy93/dashy
    container_name: Dashy
    #user: '3005:3005'
    # Pass in your config file below, by specifying the path on your host machine
    volumes:
      - ./my-config.yml:/app/public/conf.yml:Z
    ports:
      - XXX:80
    # Set any environmental variables
    environment:
      - NODE_ENV=production
    # Specify your user ID and group ID. You can find this by running `id -u` and `id -g`
      - UID=9999
      - GID=9999
    # Specify restart policy
    restart: unless-stopped
    # Configure healthchecks
    healthcheck:
      test: ['CMD', 'node', '/app/services/healthcheck']
      interval: 1m30s
      timeout: 20s
      retries: 3
      start_period: 40s

Exactly the same as you suggest in the documentation. I'm time constrained, but a cursory look through your code (entrypoint scripts, etc) indicates there is no use of the provided UID/GID, and definitely the container executes as root:

# docker-compose exec dashy id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)

With a whole host of unwise groups (dialout can allow privileged IO to devices, video can allow the same to GPU devices, etc...).

Furthermore, searching for files owned by the UID/GID confirms this:

# docker-compose exec dashy find / -user 9999
/app/public/conf.yml

You should mark this as a security issue, as the documentation provides a false sense of security with the implicit assumption that privilege drop will work, where this is obviously not the case. The way the image is developed, it assumes and relies on running as root as far as the above tests show.

POS36-C. Observe correct revocation order while relinquishing privileges - SEI CERT C Coding Standard - Confluence

[BUG] Cannot run as unprivileged container #340

Company

Community

Support

Connect