From: Stephen Frost <sfrost@snowman.net>
To: Kohei KaiGai <kaigai@kaigai.gr.jp>
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: Thu, 29 Aug 2013 13:09:59 -0400
Message-ID: <20130829170959.GU2706@tamriel.snowman.net> (raw)
In-Reply-To: <CADyhKSUD7qdQeTndZ6mDpp05V6MnRBzQO1FmYBq1+Zp37oyRrg@mail.gmail.com>
References: <51E8ADD9.5020600@2ndQuadrant.com>
<CAEZATCXdj4E8uPHxq7jiE=1gGVB0xyeHtE8wUjHoX385sHhx4Q@mail.gmail.com>
<CADyhKSWw1RY01tyuhRzu2HAa_+B9Z5qS6Jv+HEA1w0C9Ua2QLQ@mail.gmail.com>
<521D1C2B.8090503@2ndQuadrant.com>
<CAF4Au4xDXzACfC_KrXXpu=4et3XhUe5NtK=6y6yq39Cs2U0XKg@mail.gmail.com>
<CADyhKSWkHrPqbRsFK0LjPMOOTsbKGWOuN75GqYJrxCDO3CKWtA@mail.gmail.com>
<CAPpHfdsgMrBnzu9um48O6kwY=_pRFuRrBrHqnA03fCAo8x3-Gg@mail.gmail.com>
<CADyhKSUpcYKNm3rQRwCFqkTZfO3_ZrqYKjAqDxKeA6WeLezSbw@mail.gmail.com>
<20130829142321.GA30496@aart.rice.edu>
<CADyhKSUD7qdQeTndZ6mDpp05V6MnRBzQO1FmYBq1+Zp37oyRrg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-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
Attachments:
[application/pgp-signature] signature.asc (197B, ../20130829170959.GU2706@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, ktm@rice.edu, aekorotkov@gmail.com, obartunov@gmail.com, greg@2ndquadrant.com
Subject: Re: [v9.4] row level security
In-Reply-To: <20130829170959.GU2706@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