Re: [v9.4] row level security

2013/8/31 Stephen Frost <sfrost(at)snowman(dot)net>:
> KaiGai,
>
> * Kohei KaiGai (kaigai(at)kaigai(dot)gr(dot)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 <kaigai(at)kaigai(dot)gr(dot)jp>