Closed pimlie closed 1 month ago
There is no sane default you can configure here. Some users are relying on the world readable to be able to backup for example. Setting it to 660/770 or 640/750 could also be causing issues, but probably less.
Also, there unfortunately is no quick and easy solution to solve this exxcept by always setting the modes during all write actions. That might cause some overhead. And also, there is no general umask functionality in Rust which respect these settings.
We might be able to centralize all file writing actions maybe and allow something like a umask behavior. Only file uploads need to be handled differently since those are done by Tempfile.
Though, the default then still would first be 644/755 i think to not break existing installations.
There is no sane default you can configure here
It is often best to be secure-by-default, and allow users to be less secure if they have a need for that like with your backup example (even though they should configure that through the group and add their backup user to the vw group). Especially for a product like a password manager, the sane default should be as strict as what is at minimum needed for vw to run.
there unfortunately is no quick and easy solution to solve
Aren't there something like a pre-start or post-release-upgrade hooks? For existing installations, I don't think this is something that needs to be checked on every write, should be fine just on startup and/or after an upgrade. For new installations, it sounds like you are saying that configuration files are created implicitly instead of explicitly? Isn't it possible to detect if a file exists and if not create it & set umask after creating it instead of f.e. doing all at once?
the default then still would first be 644/755 i think to not break existing installations
It would probably be best to come up with a migration path that would allow us to fix this behaviour without breaking user space indeed. Cause the rsa_key
is world readable too, which is pretty unsafe. Also compare this to ssh behaviour, if your ssh keys are world readable then as a security consideration you often can't even use them at all.
F.e. a migration path could look something like this:
For docker, it would probably be best to just always run the vw server as a user instead of root, but let the user specify UID & GID through environmental variables. In docker it should then also be safe to change the default UMASK for that user to 027
A quick reply regarding the docker user, that isn't something easily changed, as that also breaks existing setups. If something like that is to be done it needs to be announced upfront for a long time. There might be some way to have root still as a default and be adjustable. But the migration is very error prone.
I do agree that the current way isn't ideal, but changing it also is not that easy with all the different setups already running.
I "fixed" the issue on my side by setting the permissions of the /etc/vaultwarden
and /data
directories to 750
and using a separate vaultwarden
uaer and group.
I'm using vaultwarden w/o docker and with MySQL, but your data dir is a bind mount, so you can always change the dir permissions easily.
I discovered this configuration error accidentally after installing my vaultwarden instance. I'm sorry if this is unhappy for you to hear, but there is no way that the rsa_key should ever be world-readable by default. I don't know enough about Bitwarden to say whether the sqlite databases should be private, too, but I'm hoping these are encrypted and shouldn't require special care. Having said that, it will be nice to have them not world-readable, too.
With the current settings, Vaultwarden is a security liability and I would not recommend it to anyone.
With the current settings, Vaultwarden is a security liability and I would not recommend it to anyone.
Hmm, I don't think you know what you are talking about. It is certainly not ideal, but it is not a security liability. I suggest you look at the architecture and the security implementation.
Was taking a look at this today, and it's actually very easy to solve this. Vaultwarden containers already have an option to run custom scripts before Vaultwarden starts, via this way you set the umask your self.
Ill see if i can add this in a simple way by default though via an ENV.
Simple example:
scripts/umask.sh:
#!/usr/bin/env sh
umask 077
docker run --rm -it \
-e DISABLE_ADMIN_TOKEN=true \
-e ROCKET_PORT=8080 \
-v "${PWD}/data/:/data" \
-v "${PWD}/scripts/:/etc/vaultwarden.d/:ro" \
--network=host \
--name vwtest \
vaultwarden/server:testing-alpine
Or via docker compose:
---
services:
vaultwarden:
image: vaultwarden/server:testing-alpine
network_mode: host
container_name: vwtest
restart: unless-stopped
volumes:
- ./data/:/data/
- ./scripts/:/etc/vaultwarden.d/:ro
environment:
- TZ=Europe/Amsterdam
- ROCKET_PORT=8080
- LOG_FILE=/data/vaultwarden.log
- DISABLE_ADMIN_TOKEN=true
I have created a PR which allows setting a custom UMASK
which should solve your issue.
We will not set the default right now to a more secure mask to not break current installations though.
Ill create/update a wiki once tagged.
Subject of the issue
After setting up a new (docker) instance of vaultwarden, all configuration files/folders have 644/755 permissions
Deployment environment
Your environment (Generated via diagnostics page)
Steps to reproduce
Start a new vaultwarden docker instance and mount the
/data
volume to a new folderExpected behaviour
Vaultwarden configuration files should not be world readable, maybe even don't let groups have (write) access by default. So all files under /data should have at least 660/770 permissions and maybe 640/750 or 600/700
Actual behaviour
Vaultwarden configuration files are world readable
Troubleshooting data