From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Volker Aßmann <volker(dot)assmann(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Disabling trust/ident authentication configure option |
Date: | 2015-05-18 19:28:32 |
Message-ID: | 555A3D60.1050004@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Volker Aßmann | 2015-05-18 19:32:23 | Re: Disabling trust/ident authentication configure option |
Previous Message | Peter Geoghegan | 2015-05-18 19:21:34 | Re: jsonb concatenate operator's semantics seem questionable |