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
