Hi Everyone- I am just an end user of couch right now, but the development of these security features are important to me so I thought I would share my thoughts.
In general and specifically regarding points 5 and 9, I have to agree very passionately with Brian. There is no way that I want my users having access to the email addresses, usernames, password hashes, etc... of any other users on my system. That would be a very bad thing and potentially even derail some sort of use cases I had thought of for couch in the future. I would also prefer couch to be closed by default and open as needed, but this doesn't matter too much as long as I can close it down. I also like the idea of restricting _all_dbs to return only the databases that the user has access to. I would accept it as an admin only resource if thats what everyone thought was best or the only option, but it seems crazy to allow users to see the names of databases that they dont have access to. There is no point imho. They don't have access for a reason. Lastly I would have to say that I would much rather have 0.11 and the feature freeze for 1.0 held off for weeks or even months if required to get this security stuff worked out properly. It's incredibly important before very many real world applications with sensitive data can actually be built. I really believe couch is an amazing piece of software that could create so many new opportunities by utilizing it's unique features such as replication and hosted applications. But, the true potential of couch really depends on rock solid authorization capabilities. Without that, I dont think couch is truly ready for a 1.0 release. Proper authorization probably isn't an easy thing to solve and I understand the desire to punt on this stuff and just get something working, but I just don't think its a good long term strategy. I hope I have not come off as unappreciative or demanding. I truly appreciate all the work that you guys are doing regarding security and with couch in general. I also understand that my opinion probably carries very little relative weight here since I am not a contributor, but I would really plead with everyone not to rush a release or freeze the api without really making sure that these issues have been thought through carefully, tested, etc... Thanks, James Hayton -----Original Message----- From: Brian Candler [mailto:[email protected]] Sent: Wednesday, February 03, 2010 1:24 PM To: [email protected] Subject: Re: DB ACLs (was Re: 0.11 Release / Feature Freeze for 1.0) On Wed, Feb 03, 2010 at 09:21:10AM -0800, Chris Anderson wrote: > Let me see if I can address some of these concerns. Thank you for taking the time to reply in detail and to implement some of the changes. > > I believe that in its current form, _all_dbs simply won't scale to millions > > of databases on a box if you want to limit it to accessible dbs only. > > This is an interesting one. _all_dbs won't scale indefinitely even > before this patch, because it has no built-in pagination abilities. > Enhancing this feature to look into each file and keep going to till > it finds N that can be listed isn't hard to code. It will be a little > more work to make _all_dbs respect startkey and endkey. I agree that it's not hard to code. What I mean is that it won't scale if the server has to open and read a million files on disk to find the two that you have access to. Making _all_dbs an admin-only resource as Jan proposed is brutal but effective in protecting the server. (Admins probably do want _all_dbs paginated, but that's a separate issue). Futon would of course have to be changed so that non-admin users type in the name of the database they want to access. So far this hasn't answered the question: why not put the authorization in the _users document instead? But I think we're getting to that :-) > > (2) _readers is a single monolithic object. I believe that it won't scale to > > millions of users having access to the same database. > > It's not meant to support this use case. If you have millions of users > with the same access rights, give them a common role and give that > role access to the database. That doesn't scale either, because what couchdb calls "roles" are really what I'd call "groups". That is, they are a system-wide collection of users. They are only maintainable by a system-wide administrator. What I'm thinking of is that database1 contains application1, with a collection of users. database2 contains application2, with another collection of users, and so on. These databases/applications are hosted on the same server, but belong to third parties. IMO it's an unrealistic expectation for the database1 owner to come along to the system administrator and say: 1. I'm having problems with scaling my _readers. 2. Please create a new role I can use, and apply this to all my existing readers. 3. More importantly, every time I need to add a new user to my application, I will come back to you and ask you to add this role that user. Then for the database2 owner to come along and ask for the same. That is, because roles are *system-wide* not *database-wide* then the management of them doesn't scale if you want to use them for database-level access controls. Given the above: as system administrator you could decide to create roles like "database1:_reader" to simplify administration and avoid role name clashes. You could even arrange the validate_doc_update in the _users database so that a delegated person in database1 is able to add and remove database1:* roles without having to trouble the systemwide admin. But that's exactly what my proposal was. In which case, why can we not just use this mechanism in the first place? > > (3) _readers has no concurrency control. One admin making an ACL change in > > futon (say) will silently overwrite changes made around the same time by > > another admin. This will get worse the more frequently users are added and > > removed. > > _readers / _admins / _security are stored as a raw object without > concurrency control, because keeping them as a document adds too much > performance overhead on each request. Concurrency control is a > tradeoff we make here. Sorry to be blunt, but do you have numbers to back that up? This smells very much of premature optimisation. In any case: if db:_reader and db:_admin are just roles, you have them in the userctx object already. That's clearly *more* efficient than having them separately in the database. _security is an edge case. I consider it as an adjunct to the design doc. You could, after all, hardcode var security = { .... }; in the top of your validate_doc_update; it just avoids you having to touch your design doc so often. Since there's only a single _security document it's going to end up cached anyway. > The database-specfic roles and names don't belong in the users db. The > users db is for answering the question: "who is the user and what > roles do they have". The ACLs say which names and roles can read or > admin a given database. > > It's a fact of life that users can rsync db-files around. If the names > / roles are in the users db, they get wrong when databases are moved > to another host or renamed on the current host. The last sentence I agree with. The same is true if you delete a DB and recreate one with the same name. However, database uuids were proposed recently. If the _users doc authorized against uuids rather than database names, would that issue be solved? (The ability to have a per-user _all_dbs view would be lost, if there wasn't a fast way to map a uuid back to a database name, but we've already decided we can live without that) > 4 is fixed. Thanks. It didn't even add any data privacy, since an _admin could always add themselves as a _reader anyway. > > (5) Non-admin readers can view the entire _readers, _admins and _security > > resources. I think this is quite a severe privacy concern, but it is easily > > fixed. > > They can also read the design document. I'm not sure why this is a > privacy concern. A user may need to contact a db admin for help with > something, it's handy to be able to get a list of them. And it only > makes sense that you should be able to see the list of users who can > also access the same db you can. > > If there's consensus that this is indeed an issue, it's not a hard > thing to change in the code. I await what others say. However I would certainly *not* want the internal E-mail addresses of my admins being available to the whole world. And as an end-user of a facebook-style application, I would not want my E-mail address known to every other user anywhere on that database. For comparison: if you're granted SELECT, INSERT, UPDATE and DELETE privileges as an Oracle user, that does not mean you get to find out the usernames of the admins, or indeed any other users with rights to the same database. And for comparison: if someone signs up for the [email protected] mailing list, they do not get to see the E-mail addresses of all the other members of this list, and nor should I. (I think the latter comparison is fair; a couchapp BBS would be a very sweet thing to have) > > (9) The _users db itself is world-readable (showing not only who your users > > are, but their password hashes). Highly undesirable. > > I actually consider this a feature. We'd like to get some stronger > password hashing (see the bcrypt threads) which should help with the > password parts. At the end of the day, bcrypt is still a hash of a password. Any password hash is open to off-line brute-force attack. You can tune the cost with bcrypt, but dictionary attacks are still going to succeed for 90% of users. You may be running couchdb on a modest server but your attacker is thousands of times more powerful than you, and can spend years doing it if they want. Put it another way: if I suggested that people should start making /etc/shadow world-readable, people would laugh. If I suggested that they also post it on their public webserver, I would be laughed out of town. Blocking _users is probably good enough for now. I'd be more comfortable if _readers didn't fail-open. I'm also concerned that newcomers may not be impressed to find couchdb so "insecure" in its default state. However, if _users could be blocked, but there were a restricted API for manipulating it (something like _update and _show handlers, allowing users only to see and change their own records), that would be much better IMO. Regards, Brian.
