2013/8/31 Stephen Frost <sfr...@snowman.net>: > KaiGai, > > * Kohei KaiGai (kai...@kaigai.gr.jp) wrote: >> The point we shouldn't forget is information leakage via covert-channel >> has less grade of threat than leakage via main-channel, because of >> much less bandwidth. > > While true, this argument can't be used to simply ignore any and all > covert channels. There are covert channels which are *not* much less > bandwidth, and the Filtered Rows one is one of those- it's simply too > big to ignore. There are likely other which are equally large and > until we clean those up our RLS implementation will be questioned by > our users. > > This does not mean that we need to clean up all covert channels and > things which are clearly intractable don't need to be addressed (eg: > the unique constraint situation; we can't both guarantee uniqueness > and hide the existance of an entry). > >> Security community also concludes it is not avoidable nature as long >> as human can observe system behavior and estimate something, > > This particular case is actually beyond 'estimation'. > >> Even if attacker has enough knowledge, the ratio they can estimate >> hidden values is very limited because of much less bandwidth of >> covert channels. > > You really need to back away from this argument in this case. The > example shown isn't based on estimation and provides quite high > bandwidth because it can be run by a computer. This argument can't > be used for every situation where information is leaked. > >> However, in general, it is impossible to eliminate anything in spite of >> less degree of threats because of smaller bandwidth. So, I don't think >> this is an issue to spent much efforts to solve. > > I don't see a lot of complexity required to fix this specific case. A > great deal of effort will be involved in going through the rest of the > code and various options and working to eliminate other similar cases, > but that's a reality we need to deal with. Hopefully the cases found > will not require a lot of additional code to deal with. We will need to > be mindful of new code which adds leaks or changes behavior such that > RLS doesn't function properly (hopefully, sufficient regression tests > will help to address that as well). > You're saying that we need to fix up cover-channels with unignorable threat degree, even though it does not mean elimination of all the covert-channels. I almost agree and feel it a reasonable stance.
One thing we need to pay attention is, how large covert-channel is we need to fix-up and how small is we can ignore. The reason why I used the term of "estimation", even heuristic or machinery way, is this covert-channel does not expose the raw data on the display. I (personally) used this criteria to decide whether the covert-channel is ignorable, or not. Thus, I tackled leaky-function problem on interaction with views for security purpose. It seems to me a rough watermark, rather than my criteria above, is necessary to determine which covert-channel is hit for us. Anyway, I try to investigate the scenario that Korotkov pointed out. It should be a common problem for views with security_barrier attribute, not only RLS feature, because it is designed on a common infrastructure. 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
