[Security] Data/config files are insecure in Docker image. Read permission for 'others' by default

[jsalgado78]

Subject of the issue

Vaultwarden data/config files are insecure. Read permission for 'others' by default

Deployment environment

Docker

Steps to reproduce

docker run -it --rm vaultwarden/server:latest
 
Save configuration from Vaultwarden admin web UI

docker exec -it ls -las /data

Expected behaviour

Data/config files should have permission 0600. Read-write to owner
config.json should be encrypted if it's possible

Actual behaviour

Files like config.json and database are created with permission 0644 by default
config.json contains admin token in plaintext

4 drwxr-xr-x. 3 root root 4096 May 3 11:05 .
8 drwxr-xr-x. 1 root root 4096 May 3 10:04 ..
4 -rw-r--r--. 1 root root 1160 May 3 10:04 config.json
164 -rw-r--r--. 1 root root 167936 May 3 10:04 db.sqlite3
32 -rw-r--r--. 1 root root 32768 May 3 11:05 db.sqlite3-shm
0 -rw-r--r--. 1 root root 0 May 3 11:05 db.sqlite3-wal
4 drwxr-xr-x. 2 root root 4096 May 3 10:04 icon_cache
4 -rw-------. 1 root root 1193 May 3 10:04 rsa_key.der
4 -rw-------. 1 root root 1679 May 3 10:04 rsa_key.pem
4 -rw-r--r--. 1 root root 270 May 3 10:04 rsa_key.pub.der

[BlackDex]

I'm going to move this to the discussions under Ideas, also to keep the issues for actual issues to the software.

There are also some ways to have the user-id configurable via ENV's like some other docker images of some tools provide.
Not sure if that would be a good thing for this project, but i think we are open for any good written and documented PR regarding this.

[0x0aNL]

Looking at the new SECURITY.md, I guess this issue fell under:

• Missing security best practices that do not directly lead to a vulnerability (You may still report them as a normal issue)

.. but it seems to me that this should still be a regular issue? Any piece of software in the Vaultwarden image could access the admin token in the described case - the files couldn't be less secure. It's not about the user ID, just the permissions.

[RealOrangeOne]

It's not a security issue necessarily, but it'd still be nice to do, so I've opened a PR to implement it #1842