Re: [v9.4] row level security - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [v9.4] row level security
Date
Msg-id 20130829170959.GU2706@tamriel.snowman.net
Whole thread Raw
In response to Re: [v9.4] row level security  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
List pgsql-hackers
* Kohei KaiGai (kaigai@kaigai.gr.jp) wrote:
> Although I didn't touch this task by myself, my senior colleague said that we
> calculated some possible bandwidth of leakage as an evident when we ship
> supercomputer system with MAC feature for customer who worry about security.
> I'm not sure how to measure it. However, if we assume a human can run up to
> 5 query per seconds, he needs 2-3 seconds to identify a particular integer value
> less than 10000, it means bandwidth of this covert channel is less than 5bps.
> I'm not sure whether enterprise-grade dbms has to care about these amount
> of covert channel.

A human isn't necessary in this particular scenario- you're doing a
simple binary search through the space, which computers can be awful
good at.  Using the type's bounds (eg: an 'integer' field is only
32bits) and forcing index scans, you could tell how many records exist
and then break down how many exist in the first half, second half, and
then split those..  Eventually, you could work out every value in the
column.

That could be applied to variable length values also, though it'd be
more costly to get down to the exact values.

I don't have a solution to these issues offhand except to suggest that,
in such an environment, having a "don't allow these users to run
EXPLAIN" and similar options would probably be welcome.  Even then there
are potential timing attacks, but that certainly increases the level of
effort involved.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: [v9.4] row level security
Next
From: Tom Lane
Date:
Subject: Re: [v9.4] row level security