2013/9/1 Greg Stark <st...@mit.edu>: > On Sun, Sep 1, 2013 at 8:31 PM, Kohei KaiGai <kai...@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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers