couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nolan Lawson <no...@nolanlawson.com>
Subject Re: Admin party considered harmful
Date Tue, 19 Apr 2016 14:53:23 GMT
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 <jan@apache.org> 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) <wickedgrey@gmail.com>
> 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 <michael@daclubhouse.net>
> 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" <nolan@nolanlawson.com> 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 <jan@apache.org> wrote:
> >>>
> >>>>
> >>>>> On 17 Apr 2016, at 16:43, Paul Hammant <paul@hammant.org>
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 <jan@apache.org>
> wrote:
> >>>>>
> >>>>>>
> >>>>>>> On 17 Apr 2016, at 05:09, Paul Hammant <paul@hammant.org>
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message