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

From KaiGai Kohei
Subject Re: [PATCH] Fix leaky VIEWs for RLS
Date
Msg-id 4C0CA016.5070204@ak.jp.nec.com
Whole thread Raw
In response to Re: [PATCH] Fix leaky VIEWs for RLS  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: [PATCH] Fix leaky VIEWs for RLS  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
(2010/06/07 15:48), Heikki Linnakangas wrote:
> On 07/06/10 06:06, Stephen Frost wrote:
>> Also, perhaps I'm not being paranoid enough, but all this concern over
>> error cases really doesn't really worry me that much. The amount of
>> data one could acquire that way is pretty limited.
> 
> It's not limited. It allows you to read all contents of the underlying 
> table or tables. I don't see much point doing anything at all if we 
> don't plug that.
> 
IIRC, Oracle pays attention not to expose function's arguments via
error messages due to the security reasons, although it focuses on
that does not provide a hint to attacker who tries SQL injection.

It seems to me it is a matter of degree.

If we allows to execute lowrite() inside of the join loop, it can
be abused to move massive invisible information into visible large
objects within a little time. So, its priority is relatively higher
than error messages.

However, we cannot move massive information via error messages in
a little time, although it may expose whole of the arguments.
So, its threat is relatively smaller.

> There's many side channels like exposing row counts in EXPLAIN and 
> statistics and timing attacks, that are not as critical, because they 
> don't let expose all data, and the attacker can't accurately choose what 
> data is exposed. Those are not as important.
> 
It also means; because they can provide much smaller bandwidth to leak
invisible information than error messages, these are not as important.
Is it right?

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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: nvarchar notation accepted?
Next
From: Dimitri Fontaine
Date:
Subject: Re: exporting raw parser