* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Steven Siebert <smsiebe@gmail.com> writes:
> > Attached is the patch (against master) for the approach we discussed:
> > sanitizing the log message by removing the sensitive information out of=
the
> > hba raw line.
>=20
> I still say that this is an ill-considered, unmaintainable, and
> fundamentally insecure approach to solving the wrong problem.
I agree that this approach is pretty grotty.
> As a single example of what's wrong with it, suppose that you
> fat-finger some syntax detail of an LDAP line in pg_hba.conf.
I've never liked that we tell users to put passwords in pg_hba.conf, be
they LDAP passwords or RADIUS secrets, it's just not the right place.
> Perhaps what we should be entertaining is a proposal to have
> multiple log channels, some containing more security-relevant messages
> and others less so. Then you could give people the ability to read only
> the non-security-relevant messages. If we arranged for *all* messages
> relevant to pg_hba.conf to go into a secure log, it'd be a lot easier to
> convince ourselves that we would not leak any security-critical info
> than if we take the approach this patch proposes.
I definitely like the idea of having multiple log channels with a way to
control what kinds of messages go to which- but I've also got a simpler
proposal:
Let's stop having passwords and secrets in a complex configuration file
which can have parsing and other failures.
How about allowing users to put that information in an independent file,
as do for SSL (admittedly, probably more because it's easier for us to
deal with OpenSSL that way, but still)?
ldapbindpwfile=3D/etc/whatever
radiussecretfile=3D/etc/whatever
as examples. The files would contain *only* the password or secret
(ignoring any newline) and must be readable by the PG user. We could
happily log any issues with pg_hba, etc, as long as we don't log what
came from those files. Keeping the passwords out of pg_hba.conf also
makes it easier for admins to manage those files across multiple systems
(eg: using puppet, chef, etc) while having local PWs for each box too.
Might not be perfect for LDAP (unless we also provide a
ldapbinduserfile), though the bind user could be handled through puppet
or similar and it isn't as secure a concern, and it'd work directly for
RADIUS which directly support different secrets for different hosts.
Thanks,
Stephen