couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Stevens (Gmail)" <wickedg...@gmail.com>
Subject Re: Admin party considered harmful
Date Tue, 19 Apr 2016 06:39:57 GMT
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
>>

Mime
View raw message