Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of bchesneau@gmail.com designates
 74.125.83.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=ZTwND28dlUaydeTCvKi9RcnkU5piG+6m5PYixHpOhm8zMmldHeb3lHnyH8RYLza9lt
         gwzMKzkI5djVMwiQBCkPB/uOIulWiUbp6pLyapXUtAKf7v+wVdd2Lp9IPlDAVwIlX9gD
         XuX2w0OAVwSHQiILuzY2W/Ss9N+T3crAzdFyE=
MIME-Version: 1.0
In-Reply-To: <FC3E10CD-BAE1-4980-9B61-A22578B077D4@gmail.com>
References: <FC3E10CD-BAE1-4980-9B61-A22578B077D4@gmail.com>
Date: Thu, 6 May 2010 14:20:41 +0200
Message-ID: <q2mb7cd8ed11005060520z5670f5bfj332e642ca26fc5ad@mail.gmail.com>
Subject: Re: rewrite security
From: Benoit Chesneau <bchesneau@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 g=
uarantees 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 bu=
t 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/_desi=
gn/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 importa=
nt for security as we move forward. Prior to this patch, there was no way t=
o run untrusted apps on the same CouchDB VM as each other. Now, using vhost=
s and by putting apps/dbs on different domains, we can protect the applicat=
ions from each other.
>
> My patch maintains the previous functionality (unlimited rewriting), but =
it is configured to be off by default. By default secure_rewrites=3Dtrue. S=
o if you are currently relying on cross-db rewrites, you'll need to edit yo=
ur local.ini file to set secure_rewrites=3Dfalse
>
> There are some missing parts in my implementation. I plan to finish this =
change by making a configurable whitelist of global_httpd handlers that *ca=
n* 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 vhost=
s 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