Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: "James Hayton" <theboss@purplebulldog.com>
To: <dev@couchdb.apache.org>
References: <e282921e1002030921g53af1711r3b46ebe31f4cb38b@mail.gmail.com>
 <20100203212426.GA10515@uk.tiscali.com>
In-Reply-To: <20100203212426.GA10515@uk.tiscali.com>
Subject: RE: DB ACLs (was Re: 0.11 Release / Feature Freeze for 1.0)
Date: Wed, 3 Feb 2010 15:33:06 -0800
Message-ID: <015a01caa529$3d24e230$b76ea690$@com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcqlF1o5GX/nOVRSSS60nOSl8NwdTQACgQaA
Content-Language: en-us

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. =20

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. =20

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
that=92s what everyone thought was best or the only option, but it seems =
crazy
to allow users to see the names of databases that they don=92t have =
access to.
There is no point imho.  They don't have access for a reason. =20

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 don=92t 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 it=92s a good long term
strategy. =20

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... =20

Thanks,=20

James Hayton


-----Original Message-----
From: Brian Candler [mailto:B.Candler@pobox.com]=20
Sent: Wednesday, February 03, 2010 1:24 PM
To: dev@couchdb.apache.org
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.
>=20
> 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.
>=20
> 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.
>=20
> _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.=20
You could, after all, hardcode

    var security =3D { .... };

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.
>=20
> 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. =A0I think this is quite a severe privacy concern, but it =
is
easily
> > fixed.
>=20
> 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.
>=20
> 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 dev@apache.org 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.
>=20
> 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.=20
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.