2013/9/1 Greg Stark <stark@mit.edu>:
> On Sun, Sep 1, 2013 at 8:31 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>> Or, any other criteria even though?
>>
>> My (current) preference is plan (c: we will be able to fix up *this*
>> cover-channel with reasonable efforts on explain code. probably,
>> we can close it if we don't print filtered rows under the sub-query
>> with security-barrier attribute.
>
> I think the criteria being discussed in this thread are too strict.
>
> It may be the case that Postgres cannot make a strong general case
> that it protects against covert channels. However it may still be able
> to make the much weaker case that it is *possible* to arrange your
> database such that the covert channels are kept under control.
>
Yes. I have to admit it is difficult to determine a strict and regular rule
to handle covert-channel scenario.
Sorry, the later half of this sentence is uncertain for me.
Are you saying, even if we could have a strict rule, we may have many
possible covert channel for information leakage??
> So I think up above Tom is wrong about why it's ok that INSERT leaks
> keys when it reports a unique key violation. The reason why it's ok
> that there's a covert channel there is that the DBA can avoid that
> covert channel by being careful when creating unique constraints. He
> or she should be aware that creating a unique constraint implicitly
> provides a kind of limited access to data to users who have INSERT
> privilege even if they lack the real SELECT privilege.
>
IIRC, we discussed and concluded that the above information leakage
scenario shall be described in the documentation, and the way to
avoid valuable information leakage using alternative keys, a few years
before.
> Likewise, as long as the covert channels in RLS are things the DBA has
> even a modicum of control over I wouldn't be too worried. Afaict from
> skimming the thread it looks like creating any indexes on columns
> leaks what values of the index key exist in the table. Is it the case
> that non-indexed columns do not get leaked?
>
According to the scenario reported by Korotkov, he could find number
of rows being filtered by the given qualifier, thus it implies existence of
the row with a value in a particular range.
Its solution is that I noted above, and I'm working for it now.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>