Thanks Jan, a setup wizard sounds awesome. Believe me, no one would be happier than me to deprecate add-cors-to-couchdb! :)
- Nolan On Tue, Apr 19, 2016 at 3:09 AM, Jan Lehnardt <[email protected]> wrote: > 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/ > > -- Nolan Lawson nolanlawson.com github.com/nolanlawson
