> 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
