Re: [PATCH] Fix leaky VIEWs for RLS - Mailing list pgsql-hackers

(2010/06/07 10:38), Robert Haas wrote:
> On Fri, Jun 4, 2010 at 4:12 PM, Tom Lane<tgl@sss.pgh.pa.us>  wrote:
>> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>  writes:
>>> On 04/06/10 22:33, Tom Lane wrote:
>>>> A counterexample: suppose we had a form of type "text" that carried a
>>>> collation specifier internally, and the comparison routine threw an
>>>> error if asked to compare values with incompatible specifiers.  An index
>>>> built on a column of all the same collation would work fine.  A query
>>>> that tried to compare against a constant of a different collation would
>>>> throw an error.
>>
>>> I can't take that example seriously. First of all, tacking a collation
>>> specifier to text values would be an awful hack.
>>
>> Really?  I thought that was under serious discussion.  But whether it
>> applies to text or not is insignificant; I believe there are cases just
>> like this in existence today for some datatypes (think postgis).
>>
>> The real point is that the comparison constant is under the control of
>> the attacker, and it's not part of the index.  Therefore "it didn't
>> throw an error during index construction" proves nothing whatever.
>>
>>> ... Secondly, it would be a
>>> bad idea to define the b-tree comparison operators to throw an error;
>>
>> You're still being far too trusting, by imagining that only *designed*
>> error conditions matter here.  Think about overflows, out-of-memory,
>> (perhaps intentionally) corrupted data, etc etc.
> 
> btree comparison operators should handle overflow and corrupted data
> without blowing up.  Maybe out-of-memory is worth worrying about, but
> I think that is a mighty thin excuse for abandoning this feature
> altogether.  You'd have to contrive a situation where the system was
> just about out of memory and something about the value being compared
> against resulted in the comparison blowing up or not.  I think that's
> likely to be rather hard in practice, and in any case it's a covert
> channel attack, which I think everyone already agrees is beyond the
> scope of what we can protect against.  You can probably learn more
> information more quickly about the unseen data by fidding with
> EXPLAIN, analyzing query execution times, etc.  As long as we are
> preventing the actual contents of the unseen tuples from being
> revealed, I feel reasonably good about it.
> 
It seems to me a good point. In general, any software have
possibility to leak information via cover-channels, and it is
nearly impossible to fix all the channels.
However, from a security perspective, covert channels with low
bandwidths represent a lower threat than those with high bandwidths.
So, evaluation criteria stands on the viewpoint that it does not
necessary to eliminate all the covert channels more than necessity.

Even if we can estimate the contents of invisible tuples from error
messages or EXPLAIN output, its bandwidths are quite limited.

But, lowrite() might write out the given argument somewhere, if it
is invoked prior to security policy functions.
In this case, the contents of invisible tuples will be moved to
another large object unexpectedly with unignorable speed.
Such a direct data flow channel should be fixed at first, because of
its large bandwidth.

>> I think the only real fix would be something like what Marc suggested:
>> if there's a security view involved in the query, we simply don't give
>> the client the real error message.  Of course, now our "security
>> feature" is utterly disastrous on usability as well as performance
>> counts ...
> 
> Not pushing anything into the view is an equally real fix, although
> I'll be pretty depressed if that's where we end up.
> 
I could not find out any certified commercial RDBMS with functionality
to tackle covert channel. It includes Oracle's row-level security stuff.
So, I don't think it is our goal to prevent anything into views.

An idea is that we focus on the direct data flow which allows to move
information to be invisible into another tables, files and so on.
In this stage, I don't think the priority of error messages are high.

Thanks,
-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>