2013/8/29 David Fetter <david@fetter.org>:
> On Thu, Aug 29, 2013 at 10:05:14AM -0400, Tom Lane wrote:
>> Alexander Korotkov <aekorotkov@gmail.com> writes:
>> > On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>> >> It is out of scope for this feature. We usually calls this type
>> >> of information leakage "covert channel"; that is not avoidable in
>> >> principle.
>>
>> > I think there is another "covert channel" much more serious than
>> > constrains. You can gather information about hidden data by
>> > reading query plans.
>>
>> I'm not convinced by this argument that covert channels are "out of
>> scope". That would be a fine justification for, say, a thesis
>> topic. However, what we're talking about here is a real-world
>> feature that will be of no real-world use if it can't stand up
>> against rather obvious attack techniques. I'm not interested in
>> carrying the maintenance and runtime overhead of a feature that's
>> only of academic value.
>
> Looking at the real-world perspective, what covert channels do our
> competitors in the space currently claim to do anything about?
>
I'm not sure whether minor dbms that is designed for extreme secure
environment already got certified. (If they have such functionality,
they should take certification for promotion.)
Oracle lists some of their certified products:
http://www.oracle.com/technetwork/topics/security/security-evaluations-099357.html
However, these are based on protection profile for basic robustness that is
designed for environment where we don't care about covert channel.
> This would represent the bar we need to clear at least as far as
> documenting what we do (do the access constraint before anything else,
> e.g.) or why we don't do things (disabling EXPLAIN, e.g.).
>
+1. I'd like to add description about this scenario.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
