From: | KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: leaky views, yet again |
Date: | 2010-10-05 15:49:23 |
Message-ID: | 4CAB4903.7070502@kaigai.gr.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(2010/10/06 0:33), KaiGai Kohei wrote:
> (2010/10/05 23:56), Tom Lane wrote:
>> Robert Haas<robertmhaas(at)gmail(dot)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
Sorry, prevents ^^^^^^
> 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(at)kaigai(dot)gr(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2010-10-05 15:52:28 | Re: querying the version of libpq |
Previous Message | Robert Haas | 2010-10-05 15:46:29 | Re: standby registration (was: is sync rep stalled?) |