Robert Haas <robertmh...@gmail.com> writes:
> ... I agree it's hopeless to
> prevent all side-channel leaks, but I'd describe the goal like this:
> Prevent access to the actual tuple contents of the hidden rows.
> Failing to solve this problem at the database level doesn't remove the
> business requirement. I've solved this problem in the past by
> ensuring that only trusted users have access to the database, and
> forcing everyone else to go through an application that restricts the
> set of queries they can issue. That doesn't eliminate the
> side-channel leak, though: they can still pull out a stopwatch and
> attempt to infer the size of the table from the query execution time.
I think you were missing the point of my comment about performance.
If the goal is "prevent users from inferring whether value X is present
in the table", I believe this patch cannot fix it because it's possible
(in some cases) to infer that from performance measurements, ie how long
does it take to execute a query that mentions X versus one that mentions
Y. I agree that it's unlikely to be practical to extract values that
you don't already have a clue about, but broad claims like "prevent all
access" are untenable.
I believe that we might be able to solve your case of ensuring that a
user can't trivially extract the entire table contents, but I don't
believe we can solve Kevin's version of the problem, which is whether
a stalker can verify the address of a victim that he's not supposed to
be able to see. So we need a pretty clear description of exactly what
it is we're going to be able to prevent and why such a facility is worth
the mess (and future security bugs) it's going to result in.
BTW, I thought Kevin's example view was mighty interesting, because it
applies the security check in a totally different way than what we've
all been implicitly assuming. Ie, instead of
select * from underlying_table where security_check();
he did
select security_wrapper(underlying_col) from underlying_table;
Offhand these approaches seem to have quite different properties.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
