(2010/10/05 23:56), Tom Lane wrote:
> Robert Haas<robertmhaas@gmail.com> writes:
>> Checking the functions of the operators is the right thing to do, but
>> assuming that internal = safe does not work. For example, pushing
>> down arithmetic operators allows you to probe for any given value in a
>> hidden row by testing whether 1 / (x - constant) throws a division by
>> zero error.
>
> Well, if the goal is "make it impossible to tell whether such-and-such a
> value exists", I think this approach can't meet it at all. There are
> too many side channels. You're focusing here on the error-report side
> channel, but there's also performance, ie how long did the query take.
> (BTW, is the intent to somehow lobotomize EXPLAIN so you can't use that
> to see what happened?)
>
Good point. Major commercial RDBMS with row-level access control
(such as Oracle VPD) does not care about any side channels that
allows us to infer existence of a certain value.
Their features focus on control regular data channels. It allows
malicious users to transfer contents of invisible tuples into others
unexpectedly. It corresponds to a user defined function which insert
the supplied argument into temporary table in my example.
So, if we should catch up same level earlier, I think we need to
ignore such kind of side channel attacks.
If so, the matter become much simple. We need to consider whether
contents of the error messages are delivered via main-channel or
side-channel.
If we consider it is a side-channel, we can trust all the buili-in
functions because nothing tries to write out the supplied argument
into somewhere.
If we consider it is a regular-channel, we need to distinguish safe and
unsafe functions based on a certain criteria, maybe, 'safe' flag in
pg_proc.
In my opinion, I like to categorize error messages as side-channel,
because its through-put is much less than regular-channels, so scale
of the threat is relatively small.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
