incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: rewrite security
Date Thu, 06 May 2010 12:20:41 GMT
On Thu, May 6, 2010 at 12:35 AM, J Chris Anderson <jchris@gmail.com> wrote:
> Devs,
>
> Today I wrote a patch and backported to 0.11.x, concerning the security guarantees made
by the rewriter.
>
> Previously we'd allowed the rewriter to include as many ".." segments in the target path
as the developer wanted. This is great for flexibility, and allows you to create a vhost which
doesn't provide the full couchdb api but also can access more than one database.
>
> I've changed the default behavior so that you can only have a maximum of 2 ".." segments
in your rewrite paths, so eg you can rewrite from /db/_design/foo/_rewrite to /db/ or /db/somedoc
or /db/_design/foo/_show/bar but you CAN'T rewrite to /otherdb/anything
>
> This allows databases to be "jailed" inside vhosts, which is very important for security
as we move forward. Prior to this patch, there was no way to run untrusted apps on the same
CouchDB VM as each other. Now, using vhosts and by putting apps/dbs on different domains,
we can protect the applications from each other.
>
> My patch maintains the previous functionality (unlimited rewriting), but it is configured
to be off by default. By default secure_rewrites=true. So if you are currently relying on
cross-db rewrites, you'll need to edit your local.ini file to set secure_rewrites=false
>
> There are some missing parts in my implementation. I plan to finish this change by making
a configurable whitelist of global_httpd handlers that *can* be accessed within vhosts. The
ones I can think of are:
>
> _utils
> _uuids
> _session
> _oauth
> _users
>
> And some installations might want to turn on others (_replicate, _stats, etc), hence
the list should be configurable.
>
> My plan is to implement this as a whitelist that is checked by the vhost engine, so that
these global handlers are available on all vhosts. This way you can easily add a database
that needs to be available to all your vhosts using a single configuration directive.
>
> I think this plan is sane, but please let me know if you see issues that I'm missing.
>
> Chris
>
>
>


Well vhost don't stop someone to access to the whole db currently if
so remove the Host info or such.

But I'm not sure this path worth it since we can limit security per
database for readers & such. In fact, I would do in the other way, ie
secure the resource that need to be secured: _replicate, _all_dbs,
_users, ... . And maybe secure by default all resource to admin or a
default group of user. Using this way would allow other users of
couchdb (those who aren't using couchapps) to have a way to secure
these accesses to between untrusted users.

In your case, for hosting multiple non trusted couchapps, you would
just have to set default permissions to a couchdb node and it would do
the trick too.

What do you think about it ?

- benoit

Mime
View raw message