incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: roadmap 0.11/1.0
Date Sun, 01 Nov 2009 22:13:28 GMT
> couchjs security
>
>  The couchjs process is currently "secure enough" for the context
> where only admins can modify design documents. However, as CouchDB
> spreads, we're sure to see misconfigured instances out there. Also,
> making the JS capabilities more controlled will definitely protect
> against some attacks in shared hosting environments. (Eg those where
> many users have private dbs on the same node.)
>
>  Currently JS functions can hack the sandbox to make http requests
> via curl. We need this functionality for the test suite, but not for
> the design document OS process. So we should use a command line flag
> to --enable-http that the test runner can use.
>
>  We can also be more secure in our ["reset"] handling. Because
> there's no such thing as a real JS sandbox, if we move our ["reset"]
> handling to C, and have it swap out the JS context for a new one,
> we'll avoid the case where databases on the same node can spy on each
> other, by say, overwriting the emit() function to also store important
> values for later playback to the attacker db. There could be some
> performance impacts of a C-based reset (as it would involve compiling
> all of main.js after each reset).
>  An alternate way to implement this is just to stop recycling
> processes in Erlang, and through them out after each use. I think that
> will get expensive (but maybe not much worse than C-based reset). This
> is trivial patch if anyone needs to run extra securely in a
> shared-host environment today.

I'm getting ready to push in the refactor work I've been doing on
couchjs to make these types of things possible. As soon as I can get
make distcheck to run the JS tests I'm gonna start pushing that in.
Since they need a running couchdb node it gets a bit interesting with
the weird path changes that distcheck does.

The first step to securing cURL handlers I'm going to tackle is the
basic all-or-nothing HTTP support. With something like --with-http as
Chris suggests. Mark also made a suggestion on including a
--with-http-host=127.0.0.1 or similar to support HTTP requests to a
specific host only. This is probably doable but I'll have to think a
bit harder on how to force that in the cURL handlers.

As to C based resets, its something I've been contemplating. I'm
pretty sure that we won't need to complete trounce the OS process to
do it though. The one thing that I will note is that I haven't seen a
single view server implementation that's even as locked down as the JS
one tries. Most of the other languages (including Erlang) allow for
arbitrary code execution running as the same user as CouchDb. This
means reading from the filesystem, network connections you name. Hence
why its disabled by default.

Just my random thoughts for now. I hope to figure out this make
distcheck path business so I can get the  refactored bits in.

Paul Davis

Mime
View raw message