Re: leaky views, yet again - Mailing list pgsql-hackers

On Wed, Oct 13, 2010 at 9:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> With the possible exception of Tom,
>> everyone seems to agree that it would be a good step forward to
>> provide a way of plugging these holes, even if it didn't cover subtler
>> information leaks such as by reading the EXPLAIN output or timing
>> query execution.
>
>> 1. Does anyone wish to argue (or continue arguing) that plugging these
>> more overt information leaks is not worthwhile?
>
> Yeah, I will.  Plugging an "overt" information leak without plugging
> other channels in the same area isn't a security improvement.It's
> merely PR, and rather lame PR at that.  An attacker is not bound to
> use only the attack methods you'd like him to.

You may as well argue that I shouldn't bother locking the doors to my
house because a determined attacker could simply break the windows.
They certainly could, and yet I am altogether convinced that a habit
of locking my doors when I am away reduces the chances that my house
will be burgled.  Breaking the windows would be altogether more
obvious and more likely to be result in the police being summoned.
Locking the doors won't protect me against someone who is bound and
determined to rob my house specifically, but it provides fairly good
protection against someone who walks around the neighborhood and robs
each unlocked house, which is not an unrealistic threat model.  But
let us suppose that I went a step further and purchased the best
burglar alarm money can buy, reinforced steel doors, and an expensive
alarm monitoring service.  Further, let us suppose that I retained a
24x7 armed guard.  This would likely be a waste of money because
there's not a whole lot in my house worth stealing (and if there were
I wouldn't post the details to a public mailing list) but let us
suppose that I did it anyway.  I would now be about as secure against
burglary as one can hope to be, and yet I'm still pretty sure that the
CIA could manage to clandestinely remove something from my home
against my will, were they of a mind to do so.

In other words - true, an attacker isn't bound to use only the attack
methods I'd like him to - but on the other hand, I'm not bound to care
about protecting myself against every type of attack.  I set a goal
for what level of security I'd like to achieve, and then I try to meet
it.  You seem to believe that being able to infer the total size of a
table or the frequency of some particular key in the table is
equivalent to being able to trivially read every row of it.  That
seems off the wall to me, and I'd like to see you justify that
position.  I and others have already posted examples of situations
where this is not the case, such as my example of allowing sales reps
to view only their own customers.  I believe Kevin has posted similar
examples: the number of cases is not a secret, but details of
individual ones may be.  These cases are taken from real business
situations and I don't understand, what, if anything, you find
implausible about them.

http://archives.postgresql.org/pgsql-hackers/2010-10/msg00299.php

> This would only be a security improvement if there were plausible attack
> scenarios in which the attacker would have access to the plugged channel
> and not access to the other known channels.  Now, perhaps that's the
> case, but no one has put forward an argument showing it.  I think the
> burden of proof is on those who favor the patch to put forward that
> argument, not for those who don't favor it to try to prove that no such
> scenario exists.

I don't favor this particular patch, but I think you're the only
person arguing that there is no subset of this problem which is both
tractable and useful.  As far as I can tell, Heikki, KaiGai, Stephen
Frost, Kevin Grittner, and myself are all on approximately the same
page about where a meaningful dividing line can be drawn.  The
question is not really whether the attacker would have access to the
un-plugged channels but how much and what type of information they
actually leak.  AIUI, the vectors that the proposed approach doesn't
block are basically EXPLAIN and query response times.  What can you
infer from those?  AFAICS, you're not going to be able to do better
than inferring whether a given value is an MCV, which is of a totally
different order than the wholesale data leakage which can be trivially
created using today's system.  And even that can be made much harder
by blocking EXPLAIN, which can be done quite easily using
ProcessUtility_hook, and therefore doesn't need to be addressed by the
patch.  But even suppose someone can reliably infer MCVs.  It does not
follow that because I'm worried about someone enumerating the contents
of my entire table that I am also worried about them learning the MCVs
of those columns which have non-unique indices.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company