Re: [PATCH] Fix leaky VIEWs for RLS

On Fri, Jun 4, 2010 at 4:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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.

> 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company