Message-ID: <555A3D60.1050004@agliodbs.com>
Date: Mon, 18 May 2015 12:28:32 -0700
From: Josh Berkus <josh@agliodbs.com>
Organization: PostgreSQL Experts Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Jim Nasby <Jim.Nasby@BlueTreble.com>, =?UTF-8?B?Vm9sa2VyIEHDn21hbm4=?=
 <volker.assmann@gmail.com>
CC: Stephen Frost <sfrost@snowman.net>, Tom Lane <tgl@sss.pgh.pa.us>,
 Andrew Dunstan <andrew@dunslane.net>,
 Alvaro Herrera <alvherre@2ndquadrant.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Disabling trust/ident authentication configure option
References: 
 <CA+TgmoYFWGoZVCRVpgwGYSiZhY9PFkC0mrmnYy3acFJ=aU0eEw@mail.gmail.com>
	<6837.1430946793@sss.pgh.pa.us>
	<WM!166b48023e720856eea587c0ad127e5181882abf659ccd483360b19f27293d1addb1d058c6dbdafcbaa946420b35a64b!@asav-3.01.com>
	<554A9898.9040407@agliodbs.com>	<20150507150254.GA30322@tamriel.snowman.net>
	<CA+TgmobuF2CdDm=W-gi1XK9OT3kcck511UHigWtC0mus1scGPA@mail.gmail.com>
	<20150507205749.GE30322@tamriel.snowman.net>
	<CA+TgmobkrjWGrP1vnr+D3OmQd68nGYhUsM3k6q3Nn8BJpLXdhg@mail.gmail.com>
	<CAJBpAdwwX8MmHaqMu43YCLJLrpX=1uKAgzpwRBqU8xNX=920Kw@mail.gmail.com>
	<CA+Tgmob4wt1f84k-iYPou1ZtHCwLn=gRApk4i=q8TAwnQjCx+w@mail.gmail.com>
 <CAJBpAdxWQscGEJubs-KLMXYd76tspwD_b2wmgYArsYYTX5ao7w@mail.gmail.com>
 <WM!3b761876ad683334d7afacc13949867067da229b8b4a89a6384ebd101a9ce056b35e6732803f2295acef5787aadcb6e2!@asav-1.01.com>
 <55596375.7070601@agliodbs.com> <555A06ED.3040609@BlueTreble.com>
 <WM!8b81f03c1c8391822894a8f3010f8f9a767f8dafc0e2c1635100a31cb1b6b0737505d6b56bad2a728244a858f2dabb51!@asav-2.0
 1.com>
In-Reply-To: 
 <WM!8b81f03c1c8391822894a8f3010f8f9a767f8dafc0e2c1635100a31cb1b6b0737505d6b56bad2a728244a858f2dabb51!@asav-2.01.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 05/18/2015 08:36 AM, Jim Nasby wrote:
> On 5/17/15 10:58 PM, Josh Berkus wrote:
>> The goal here was stated to preventing authentication misconfiguration
>> by shortsighted admins who have superuser access and the ability to
>> change pg_hba.conf.  This is tantamount to giving someone a gun and
>> bullets, but expecting duct tape across the cartridge slot to prevent
>> them from loading or using the gun.
> 
> The idea is to prevent *accidental* misconfiguration, not to try and
> permanently lock them out. IE: make them think before allowing them to
> just do something silly. Disabling auth methods at compile time seems a
> very reasonable way to accomplish that.

It doesn't seem like it to me.  You're talking about a mechanism which
would either require people to compile their own PostgreSQL binaries, or
have an additional set of packages available.  That's a huge amount of
overhead for something which could be just as easily accomplished by
putting the comment "#IF YOU ENABLE TRUST AUTH IN THIS FILE YOU WILL BE
FIRED" in pg_hba.conf.

Or, heck, simply putting pg_hba.conf in Puppet/Chef/Ansible/Salt and
restricting permissions to the CMS repo.  Which is something most modern
shops *already do*.

There are *real* things we could do to improve the overall security of
auth methods.  Mandatory logging of pg_hba.conf changes, for example. Or
having a way to monitor which servers have which auth methods for which
networks available in some scalable way (i.e. without reading
pg_hba.conf).  Those would also take a lot of work and thought lest they
expose additional attack surfaces.

One thing computer security history has demonstrated again and again is
that ad-hoc attempts to duct-tape over real security issues are
counter-productive, since they interfere with real work and the steps
people take to get around them create bigger security holes than the
original problem.  Let's please not do that in Postgres.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers