couchdb
couchdb copied to clipboard
apache
Security: Make databases private by default
Summary
Currently the config warns, that if no roles or members are configured, the database will be publicly accessible.
If you just PUT {} into <db>/_security, the database will be public.
But in a database it should be very hard to release something to the public and data should be private by default.
The motivation behind this could be a scenario like this: The database holds sensitive data, e.g. from health care. An issue comes up that requires immediate action, e.g. a leak in a client application which allows to get database account data. Now the admin currently on duty at 4am thinks: "okay, if i just kick all roles with access from the db, I should be fine".
If you're doing everything right, your database remains private with the current implementation. Things don't always go right however and CouchDB should help the user here to avoid mistakes.
Desired Behaviour
If there is no access configured, only admins should have access, not everyone. If needed, a config option can be added, that imitates the old behavior. (This should NOT be the default)
Possible Solution
I added a andalso false as POC in https://github.com/apache/couchdb/blob/0059b8f90e58e10b199a4b768a06a762d12a30d3/src/couch/src/couch_db.erl#L700
This worked in a simple test and denied access, when no roles or members were set, thus the false could be replaced with a config option. The config option should default to false and if true behaves like the current CouchDB.
We made this change in https://github.com/apache/couchdb/pull/2339 some time ago.
It is also referenced from the 3.0 release notes https://docs.couchdb.org/en/stable/whatsnew/3.0.html
From my experiments and how I understand the PR you added a default _admin role to a newly created DBs. Still, the behavior is: if you remove all roles and members, the DB is accessible by everyone.
Maybe the title is a big misleading here. Feel free to change it.
Right, if you don't set the security object yourself, it is implicitly;
{
"members" : { "roles" : [ "_admin" ] },
"admins" : { "roles" : [ "_admin" ] }
}
which means only admins can read/write/etc.
If you change it to {}, you are opening it up to everyone.
Exactly, this is what the issue is about.
The database holds sensitive data, e.g. from health care. An issue comes up that requires immediate action, e.g. a leak in a client application which allows to get database account data. Now the admin currently on duty at 4am thinks: "okay, if i just kick all roles with access from the db, I should be fine".
CouchDB should help the user to prevent unintentional data leakage and make it hard to release data to the public.
I think what you are asking for is for {} to mean private and not public. I sympathise with that position but there is a huge backward compatibility issue there that troubles me. {} has had the meaning of "public" in CouchDB since the introduction of the _users database (circa 1.2).
The https://github.com/apache/couchdb/pull/2339 PR addressed the surprising "public by default" behaviour in a more careful way, and we phased its rollout over releases.
CouchDB does now help prevent unintential data leakage by making databases private unless changed to public by an administrator.
You are saying that administrators might set databases to public by accident and I agree; we can all make mistakes.
At this point I'm not sure where to go with this issue and invite others to add their thoughts. Would changing the long-standing meaning of the {} security object be too disruptive? If we did change it to mean "private", how would one open a database for public read+write?
I wouldn’t mind adding an off-by-default config option that when enabled means “empty security means admin-only-access”
How about adding a config option with a warning, that the default will change in the future. With some bigger release the default can then be flipped.
not sure we will address this before we do a (much needed) major revamp, so let’s not worry about future announcements here.
No, unfortunately not. We will just have a proxy in front which checks the authentication separately and blocks unwanted access, thus this risk is mitigated for us anyway.