Re: Re: Row Level Security − leakproof-ness and performance implications

On Thu, Feb 28, 2019 at 10:49 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com> writes:
> > On Thu, Feb 28, 2019 at 9:12 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >> So... you're just going to replace ALL error messages of any kind with
> >> "ERROR: missing error text" when this option is enabled? That sounds
> >> unusable. I mean if I'm reading it right this would get not only
> >> messages from SQL-callable functions but also things like "deadlock
> >> detected" and "could not read block %u in file %s" and "database is
> >> not accepting commands to avoid wraparound data loss in database with
> >> OID %u". You can't even shut it off conveniently, because the way
>
> > This makes complete sense to me. The client side of a client/server
> > protocol doesn't have any way to fix 'could not read block %u in file
> > %s', the client doesn't need that kind of detailed information about a
> > server, and in fact that information could be security sensitive.
>
> I agree with Robert that this idea is a nonstarter. Not only is it
> a complete disaster from a usability standpoint, but *it does not
> fix the problem*. The mere fact that an error occurred, or didn't,
> is already an information leak. Sure, you can only extract one bit
> per query that way, but a slow leak is still a leak. See the Spectre
> vulnerability for a pretty exact parallel.

How is leakproof defined WRT Postgres? Generally speaking a 1 bit
error path would be considered a covert channel on most systems and
are relatively slow even compared to e.g., timing channels.

Redacting error information, outside of the global leakproof setting,
seems useful to prevent data leakage to a client on another system,
such as Robert's example above "could not read block %u in file %s".

Although, and Joe may hate me for saying this, I think only the
non-constants should be redacted to keep some level of usability for
regular SQL errors. Maybe system errors like the above should be
removed from client messages in general.

> The direction I think we're going to need to go in is to weaken our
> standards for what we'll consider a leakproof function, and/or try
> harder to make common WHERE-clause operators leakproof. The thread
> over at
> https://www.postgresql.org/message-id/flat/7DF52167-4379-4A1E-A957-90D774EBDF21%40winand.at
> raises the question of why we don't expect that *all* indexable
> operators are leakproof, at least with respect to the index column
> contents. (Failing to distinguish which of the inputs can be
> leaked seems like a pretty fundamental mistake in hindsight.
> For instance, some opclasses can directly index regex operators,
> and one would not wish to give up the ability for a regex operator
> to complain about an invalid pattern. But it could be leakproof
> with respect to the data side.)
>
> regards, tom lane