From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Steven Siebert <smsiebe(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #10680: LDAP bind password leaks to log on failed authentication |
Date: | 2014-10-12 20:21:36 |
Message-ID: | 20141012202136.GZ28859@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > 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)?
>
> And then what? This other file can't possibly be so simple that
> it's immune to having syntax errors, for example.
Uh, no, that's exactly the point of the independent file.
It's *only* the password.
fopen() - fails, then log that you can't open the file
fgets() - fails, then log that you can't read the file
(check for newline and remove it, if it's there)
If it grows to be a complex configuration file which can have syntax
errors, then it loses the point, I agree, but I don't hear anyone
complaining about SSL keys or SSH keys or Kerberos keytabs being leaked
in log files- and I'm pretty darn sure they would be complaining if it
was happening, regardless of any "keep your log files secure and only
let trusted people look at them" requirement.
> You're just moving
> the same problems from point A to point B. More, this would complicate
> configuration and thereby create a whole new set of possible config
> errors, which we'd then feel pressure to ameliorate by adding more
> logging showing what the postmaster is doing. And that logging would
> have this same issue of maybe it's exposing information that person A
> doesn't want logged ... even though person B needs that very same info
> to help him figure out his configuration mistake. A likely example of
> that is feeding the wrong password/secret to some auth infrastructure
> service, because you referenced the wrong item in this secondary file.
This is done in other systems and has worked well from my experience.
> The core problem here is that we *need* to put security-relevant info
> into the postmaster log in order to help people resolve problems. Moving
> around configuration details isn't going to fix that; indeed, the more
> complicated the configuration files, the worse the problem will be.
Having pg_hba be complicated but not having passwords in secrets in it
isn't making this problem worse- we can log all we want about pg_hba.
The point is to remove the sensetive information from the complicated
config file, even if that makes the complicated config file a bit more
complicated.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Steven Siebert | 2014-10-13 00:31:54 | Re: BUG #10680: LDAP bind password leaks to log on failed authentication |
Previous Message | Tom Lane | 2014-10-12 20:09:56 | Re: BUG #10680: LDAP bind password leaks to log on failed authentication |