Re: [v9.4] row level security

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [v9.4] row level security
Date: 2013-08-31 19:40:14
Message-ID: 20130831194013.GQ2706@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

KaiGai,

* Kohei KaiGai (kaigai(at)kaigai(dot)gr(dot)jp) wrote:
> The point we shouldn't forget is information leakage via covert-channel
> has less grade of threat than leakage via main-channel, because of
> much less bandwidth.

While true, this argument can't be used to simply ignore any and all
covert channels. There are covert channels which are *not* much less
bandwidth, and the Filtered Rows one is one of those- it's simply too
big to ignore. There are likely other which are equally large and
until we clean those up our RLS implementation will be questioned by
our users.

This does not mean that we need to clean up all covert channels and
things which are clearly intractable don't need to be addressed (eg:
the unique constraint situation; we can't both guarantee uniqueness
and hide the existance of an entry).

> Security community also concludes it is not avoidable nature as long
> as human can observe system behavior and estimate something,

This particular case is actually beyond 'estimation'.

> Even if attacker has enough knowledge, the ratio they can estimate
> hidden values is very limited because of much less bandwidth of
> covert channels.

You really need to back away from this argument in this case. The
example shown isn't based on estimation and provides quite high
bandwidth because it can be run by a computer. This argument can't
be used for every situation where information is leaked.

> However, in general, it is impossible to eliminate anything in spite of
> less degree of threats because of smaller bandwidth. So, I don't think
> this is an issue to spent much efforts to solve.

I don't see a lot of complexity required to fix this specific case. A
great deal of effort will be involved in going through the rest of the
code and various options and working to eliminate other similar cases,
but that's a reality we need to deal with. Hopefully the cases found
will not require a lot of additional code to deal with. We will need to
be mindful of new code which adds leaks or changes behavior such that
RLS doesn't function properly (hopefully, sufficient regression tests
will help to address that as well).

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2013-08-31 19:43:25 Re: CREATE FUNCTION .. SET vs. pg_dump
Previous Message Andres Freund 2013-08-31 18:34:26 Re: INSERT...ON DUPLICATE KEY IGNORE