Re: [PATCH] Fix leaky VIEWs for RLS

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: KaiGai Kohei <kaigai@ak.jp.nec.com>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, marc@bloodnok.com, pgsql-hackers@postgresql.org
Date: 2010-06-07T11:53:47Z
Lists: pgsql-hackers
On 07/06/10 14:06, Stephen Frost wrote:
> * Heikki Linnakangas (heikki.linnakangas@enterprisedb.com) wrote:
>> The big difference is what information can be obtained, not how fast it
>> can be obtained.
>
> Actually, I disagree.  Time required to acquire the data does matter.

Depends on the magnitude, of course. If it takes 1 year per row, that's 
probably acceptable. If it takes 1 second, that's extremely slow 
compared to normal queries, but most likely still disastreous from a 
security point of view.

>> Imagine a table that holds username/passwords for users. Each user is
>> allowed to see his own row, including password, but not anyone else's.
>> EXPLAIN side-channel might give pretty accurate information of how many
>> rows there is in the table, and via clever EXPLAIN+statistics probing
>> you might be able to find out what the top-10 passwords are, for
>> example. But if you wanted to know what your neighbor's password is, the
>> side-channels would not help you much, but an error message would reveal
>> it easily.
>
> Using only built-ins, could you elaborate on how one could pick exactly
> what row was revealed using an error case?  That strikes me as
> difficult, but perhaps I'm not thinking creatively enough.

WHERE should do it:

SELECT * FROM secrets_view WHERE username = 'neighbor' AND 
password::integer = 1234;
ERROR:  invalid input syntax for integer: "neighborssecretpassword"

Assuming that username = 'neighbor' is evaluated before the cast.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com