On Fri, May 29, 2020 at 12:38 PM Chapman Flack <chap@anastigmatix.net> wrote:
> Just giving this thread a bump in honor of the mention of sensitive
> things in logs in the cryptography unconference session.
I agree that there's a problem here and I would like to see a solution
to it, too. Several EnterpriseDB customers have complained about the
fact that ALTER USER .. PASSWORD logs the password, which is a similar
kind of problem, though it involves DDL rather than DML.
But, I don't really see a way forward that doesn't involve breaking
stuff that works today. We have options to log queries before parsing
them. You can't redact sensitive details at that point because you
don't know whether the query contains any such details, or where they
are located. You can't postpone logging the query without changing the
behavior of the system in user-visible ways. What if parsing gets
stuck in an infinite loop and you want to look at the log to see which
query got stuck? What if you want to look at the timestamps on the log
messages to know when the server started dealing with some particular
query?
On a related note, what if parsing fails? Not only should the logging
that happens before parsing already have been done, but the parse
error itself should also log the query that triggered it, so that the
user has some chance of troubleshooting the situation. However, since
we haven't completed parsing, there's no way to redact what gets
logged in such a case; we can't know where the sensitive stuff is.
Now, you might say that you only care about redacting queries that are
well-formed, but parsing can fail for other reasons - e.g. because you
ran out of memory. You could argue that such cases are unlikely enough
that you don't care about them, but that doesn't mean somebody else
won't file a CVE.
Also, even if you are logging after parsing has been successfully
completed, does that mean that you know which parts of the query
contain sensitive information? Parse trees contain some positional
information, but I'm not sure that there's enough information there,
or that we have it in all the cases somebody might want to redact.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
