Re: pie-in-sky idea: 'sensitive' function parameters

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pie-in-sky idea: 'sensitive' function parameters
Date: 2020-05-29 16:38:16
Message-ID: 5ED13A78.3050008@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Just giving this thread a bump in honor of the mention of sensitive
things in logs in the cryptography unconference session.

I'm not partisan about any of the particular syntax examples I gave
earlier, but it seems like there were two key ingredients:

1. In what is sent from the client to the server, certain parameters
are marked as sensitive in ways that are obvious early at parse time,
before having to look up or analyze anything.

2. But those markings are later compared to the actual declarations of
things, once those are resolved. It is an error either to send as
'sensitive' a parameter that isn't so declared, or to forget to send
as 'sensitive' one that is.

The first error is to prevent evildoers using the facility to hide values
from the logs arbitrarily in the queries they are sending.

The second error is to catch mistakes during app development. It's possible
that a query sent by an app under development won't have the right things
marked 'sensitive' yet, and it's possible those queries get exposed in the
logs because the early parse-time indication that they shouldn't be is
missing.

But at that stage of development, the values being sent shouldn't really
be sensitive ones, and making such a query an error ensures such omissions
are caught and fixed.

Regards,
-Chap

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-05-29 17:24:27 Re: Expand the use of check_canonical_path() for more GUCs
Previous Message Pavel Stehule 2020-05-29 16:14:37 Re: proposal: possibility to read dumped table's name from file