From this thread alone, it should be obvious that this is a contentious topic.
CouchDB 2.0 will have a happy-path setup that requires a setup. You can get out of it, if you run a single-node instance, but for a cluster, you have to have an admin user. Discussions about this are about two years old and now is not the time to revisit them. This is a good default security that CouchDB has been dinged for over the years and the devs generally agree that having a server admin at least is a good idea. Note that this means regular doc r/w is still open to anyone, just db and ddoc creation is limited to admins. Then we have to balance this with user-friendliness of course, and I think things like the setup wizard (thanks Robert!) in Fauxton here can help. This is what normal users* and especially beginners will go through to set up one or more 2.0 nodes. As part of the setup procedure, Fauxton could offer a button “enable CORS for dev purposes“, or something else that helps them set it up correctly that would replace https://github.com/pouchdb/add-cors-to-couchdb that effectively all PouchDB users will just use without learning the consequences (FWIW, I’ve used this myself, configuring CORS is too hard in CouchDB). In addition: we have agreed last summer that we are not going to offer the /_config endpoint in 2.0 because that’d require to build a CP system on top of an AP one and we didn’t want to delay 2.0 because of that (imagine!) We made per-node /_config available under /_node/<node-fqdn>/_config and I’d be happy to have Fauxton use this to make CORS a simple setup. This wouldn’t work well for larger clusters, but that’s not the target audience here. * expert users will use deploy scripts and other ways to deploy pre-configured instances, they will know what they are doing. Best Jan -- > On 19 Apr 2016, at 08:39, Eli Stevens (Gmail) <[email protected]> wrote: > > Honestly, the entire topic feels over-thought to me. If someone sets > up a database, has it listen to a port that's open to the internet, > and doesn't set a password... The situation is pretty much hopeless. > There's zero chance that *this* is the only security hole that they > have, and IMO it's kinda silly to think that adding some CouchDB > nanny-state will result in a now-airtight system. Obviously, sane > defaults and documentation in the default config are great. > > I've been running into this with some other tools that I use - I want > to do a certain thing, but the tools prevent me, since the author of > the tool apparently has a philosophical disagreement with the workflow > I prefer (to the point of actively inserting somewhat arbitrary > precondition checks before performing operations that would otherwise > succeed). > > Needless to say, when I need to do something, and the tool has gone > out of it's way to block the thing that I'd like to do, it's quite > frustrating. Please trust me to do my job, and to know my use cases. > > FWIW, all of my CouchDB instances are in admin party, and were an > attacker to penetrate deep into our systems enough to access CouchDB, > we'd have been so hopelessly compromised that "oh, they can access the > DB too" wouldn't meaningfully increase the severity of the event. > Making me play an obfuscation shell game with a password or auth token > so that the various programs I have can access the DB isn't going to > actually make my systems more secure. > > Thanks, > Eli > > On Mon, Apr 18, 2016 at 6:32 PM, Michael Fair <[email protected]> wrote: >> SMTP open relays; wikis; and comment/bulletin board systems have taught us >> that if there's any hope of monetizing something an ip scanner can attack, >> they will. >> >> This includes a default admin password. The problem isn't really admin >> party mode; it's a trivially automated type of default attack profile. >> >> I agree with Nolan that people (myself included) succeed in getting >> started/familiar with Couch largely because of a text editor, admin party >> mode, curl, and futon. Following the breadcrumb tutorials and immediately >> creating/destroying databases; Editing data docs and design docs quickly, >> directly "on the server"; and practicing replication; without having to >> first understand the security model/settings to grant oneself permission >> (or write curl command lines embedding the passwords straight into >> bash_history). >> >> 1) >> What about only allowing admin party from a machine with the same ip >> addresses Couch is listening on. So listen to 0.0.0.0 but make source ip a >> factor in the privileges assignment. >> >> So in a sense, it's multifactor authorization defaulted to only allow >> certain source ips admin party access (role="admin", connection="source >> ip/port"). >> >> 2) >> Make modes enumerable: "Admin Party", "Production", "Development", "Client" >> (for clients connecting to server hosts and the default when not supplied), >> "<User Defined/Added>" (like "Internal Production" which would mean the >> "Client" request mode isn't allowed) >> And then by default prevent servers in different modes from >> replicating/querying each other (add "req_mode" field (the mode of the >> thing requesting); and "rep_mode" field (the mode the database replying >> should be in) to the request parameters). >> >> Make database operational settings for which request modes are enabled for >> which reply modes. >> By default: >> "Admin Party" only allows requests from "Admin Party" and "Client" >> "Production" allows "Production" and "Client" >> "Development" allows "Development" and "Client" >> >> 3) >> Reuse Erlang's magic cookie concept for any access sourced remotely. If I >> can, by default, access an admin party database remotely by adding a "magic >> cookie" (that the server generated) to the URL header in place of a login; >> and I can only get that cookie by querying the database from the same local >> machine the server is running, and the server/database must be in admin >> party mode. That's A) pretty easy to look up and get the copy/paste >> instructions to do for a default; B) a clearly placed magic cookie can be >> retrieved (because it got added to the default server/database json >> response) by any appropriately authorized user; and C) is not easy for an >> automated scanner to exploit unless it's already on the same host. >> >> A different token would be generated for each server mode; or these magic >> cookies would be purely an "Admin Party" mode thing. >> >> Thoughts? >> >> Mike >> >> A hosted service would need to have a way to communicate the magic cookies >> of new databases to their users, or require authentication; but >> >> Embedding my server's "Admin Party" <magic cookie> on a client command line >> On Apr 18, 2016 8:01 AM, "Nolan Lawson" <[email protected]> wrote: >> >>> I do think that there's a tension between the needs of first-timers and >>> production users. First-timers are already stymied by the lack of CORS by >>> default, and if we remove the Admin party from the default installation, >>> it's going to be even more impenetrable for them. >>> >>> This is why for PouchDB Server we not only made Admin Party the default, >>> but also completely-open CORS. If I were to go one step further, I might >>> even make it bind to 0.0.0.0. That has bitten me many many times before on >>> a fresh install. >>> >>> Is this something that can be done with Docker? Or maybe by adding presets >>> to the config UI? (Think Babel presets - e.g. "playground mode" or >>> "production-ready".) >>> >>> Cheers, >>> Nolan >>> >>> >>> >>> On Sun, Apr 17, 2016 at 12:16 PM, Jan Lehnardt <[email protected]> wrote: >>> >>>> >>>>> On 17 Apr 2016, at 16:43, Paul Hammant <[email protected]> wrote: >>>>> >>>>> I wasn't being snide, or insulting >>>> >>>> I’m glad to hear that you didn’t mean to be snide. >>>> >>>>> If I >>>>> wanted to write "I find the security system poorly documented, >>>>> can someone explain this to me" (your suggestion), I would have written >>>> it >>>>> as "I find the documentation of the security could be expanded for >>>> newbies, can >>>>> someone explain this to me" and avoid a reference to "poorly". >>>>> >>>>> I'm an Apache member - 'hammant' - and wouldn't do what you're claiming >>>> I'm >>>>> doing. >>>> >>>> I’m not claiming anything, I’m just telling you how this reads to me. >>>> >>>> Best >>>> Jan >>>> -- >>>> >>>> >>>>> >>>>> - Paul >>>>> >>>>> On Sun, Apr 17, 2016 at 8:24 AM, Jan Lehnardt <[email protected]> wrote: >>>>> >>>>>> >>>>>>> On 17 Apr 2016, at 05:09, Paul Hammant <[email protected]> wrote: >>>>>>> >>>>>>> (Cultural ref: https://en.wikipedia.org/wiki/Considered_harmful) >>>>>>> >>>>>>> So AdminParty is fun for there 2 minute "hey this stuff is great" >>> tour >>>> of >>>>>>> CouchDB, but it leaves me (and others) worried that we don't know the >>>> 52 >>>>>>> specialist knowledge things to do to lock down a couch install >>>>>> completely. >>>>>>> You know: 443-only, a top-level administrator, sub administrators, >>>>>> regular >>>>>>> accounts, different read vs write permissions, etc etc. We can't >>>> imagine >>>>>>> going live with a CouchDB solution without that, and it makes us >>> think >>>> we >>>>>>> should look for other technologies when there is no cohesive 100% >>>>>> dev-team >>>>>>> endorsed page on how to close down the party once and for all. >>> Sooooo - >>>>>> *if >>>>>>> that page exists, I can't find it*. >>>>>> >>>>>> >>>>>>> Is the comummunity even in agreement - is it changes to default.ini, >>>>>> local.ini >>>>>>> (server side), or is it a series of curl statements over the wire >>> (and >>>>>> why)? >>>>>> >>>>>> No need to be snide about this. A “Why are there two ways to configure >>>>>> CouchDB?” would have sufficed. >>>>>> >>>>>> CouchDB has a config system. It is persisted in two .ini files. You >>> can >>>>>> change settings by editing local.ini and [re]starting CouchDB or >>> without >>>>>> restarting CouchDB using curl. The latter is rather beneficial in >>>>>> production >>>>>> systems that don’t want to incur downtimes. >>>>>> >>>>>> Changes done at runtime are stored in local.ini. When you install a >>>> newer >>>>>> version of CouchDB new config variables can appear in default.ini. If >>>> the >>>>>> install procedure finds an existing local.ini it will not replace it, >>> so >>>>>> local changes (hence the name) survive software upgrades. >>>>>> >>>>>> As Bob pointed out, there is a security consideration with ini vs. >>> curl: >>>>>> >>>>>> If you were to start a CouchDB instance and then add an administrator >>>> via >>>>>> curl, there is an ever so slight chance that someone else gets there >>>> before >>>>>> you. The exact scenario is somewhat convoluted, so I won’t bore you >>> with >>>>>> it. >>>>>> Suffice it to say, creating an admin in local.ini before the first >>>> launch >>>>>> of CouchDB completely avoids said issue. >>>>>> >>>>>> * * * >>>>>> >>>>>> If you don’t feel confident using CouchDB then I suggest you look for >>>>>> alternative technology, or ask someone nicely to explain this to you, >>>>>> but pressuring the dev team with an somewhat insulting email is not >>>>>> appreciated here. Again, a “I find the security system poorly >>>> documented, >>>>>> can someone explain this to me?” would have been much more productive. >>>>>> >>>>>> >>>>>> Best >>>>>> Jan >>>>>> -- >>>>>> Apache CouchDB PMC Chair >>>>>> http://couchdb.apache.org/conduct.html >>>>>> >>>>>> >>>>>> >>>> >>>> -- >>>> Professional Support for Apache CouchDB: >>>> https://neighbourhood.ie/couchdb-support/ >>>> >>>> >>> >>> >>> -- >>> Nolan Lawson >>> nolanlawson.com >>> github.com/nolanlawson >>> -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
