From: Stephen Frost <sfrost@snowman.net>
To: Kohei KaiGai <kaigai@kaigai.gr.jp>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: ktm@rice.edu <ktm@rice.edu>
Cc: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Oleg Bartunov <obartunov@gmail.com>
Cc: Greg Smith <greg@2ndquadrant.com>
Cc: PgHacker <pgsql-hackers@postgresql.org>
Subject: Re: [v9.4] row level security
Date: Sat, 31 Aug 2013 15:40:14 -0400
Message-ID: <20130831194013.GQ2706@tamriel.snowman.net> (raw)
In-Reply-To: <CADyhKSWMvA-Ri7zD2gvz9bq2GiDLPQ_Hqmq86A5AL2r+em9+pw@mail.gmail.com>
References: <CAPpHfdsgMrBnzu9um48O6kwY=_pRFuRrBrHqnA03fCAo8x3-Gg@mail.gmail.com>
<CADyhKSUpcYKNm3rQRwCFqkTZfO3_ZrqYKjAqDxKeA6WeLezSbw@mail.gmail.com>
<20130829142321.GA30496@aart.rice.edu>
<CADyhKSUD7qdQeTndZ6mDpp05V6MnRBzQO1FmYBq1+Zp37oyRrg@mail.gmail.com>
<WM!685df689dd4d8f8c5349d5ef7b8e285db1e99ea32d22ab5d35f3981c29eac19dbd725c9b5e0227def9d782de274d1354!@asav-3.01.com>
<521F7DFB.8060602@agliodbs.com>
<CADyhKSW_o2nVWFytdTY84DUXZSuZkD_EtY2d8wAjR18UruOXYQ@mail.gmail.com>
<WM!fb94ecb91cd381e69d8e4773d3810f48e4e0ef000525cc806c4ee509f215ce1a39c8c2a1c3ffde72ba2ddb1a07ebcdc9!@asav-2.01.com>
<5220D832.7090104@agliodbs.com>
<CADyhKSWMvA-Ri7zD2gvz9bq2GiDLPQ_Hqmq86A5AL2r+em9+pw@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
KaiGai,
* Kohei KaiGai (kaigai@kaigai.gr.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
Attachments:
[application/pgp-signature] signature.asc (197B, ../20130831194013.GQ2706@tamriel.snowman.net/2-signature.asc)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, kaigai@kaigai.gr.jp, josh@agliodbs.com, ktm@rice.edu, aekorotkov@gmail.com, obartunov@gmail.com, greg@2ndquadrant.com
Subject: Re: [v9.4] row level security
In-Reply-To: <20130831194013.GQ2706@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox