(2010/06/01 22:16), Robert Haas wrote:
> 2010/6/1 Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>:
>> The general problem is that it seems like a nightmare to maintain this
>> throughout the planner. Who knows what optimizations this affects, and
>> do we need to hide things like row-counts in EXPLAIN output? If we try
>> to be very strict, we can expect a stream of CVEs and security releases
>> in the future while we find holes and plug them. On the other hand,
>> using views to restrict access to underlying tables is a very useful
>> feature, so I'd hate to just give up. We need to decide what level of
>> isolation we try to accomplish.
>
> I'm entirely uninspired by the idea of trying to prevent all possible
> leakage of information via side-channels. Even if we tried to
> obfuscate the explain output, the user can still potentially get some
> information by timing how long queries take to execute. I think if we
> have a hook function that can prevent certain users from running
> EXPLAIN altogether (and I believe this may already be the case) that's
> about the appropriate level of worrying about that case. I think the
> only thing that we can realistically prevent is allowing users to make
> off with the actual tuples.
>
It is a good point, I think.
Even if we can guess or estimate something from circumstances, it does not
allow unprivileged users to read information directly.
In fact, we cannot find such a functionality to prevent side-channel leaks
from the certification reports of commercial RDBMS with RLS (e.g; Oracle
Label Security).
However, the leaky VIEWs has a different characteristic.
It unintentionally allows to fetch contents of invisible tuples and move
into into other tables. It means here is a data flow channel (not side channel),
but it breaks restriction of security views.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
