couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Admin party considered harmful
Date Tue, 19 Apr 2016 07:09:03 GMT
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/


Mime
View raw message