Message-ID: <5220D832.7090104@agliodbs.com>
Date: Fri, 30 Aug 2013 10:36:50 -0700
From: Josh Berkus <josh@agliodbs.com>
Organization: PostgreSQL Experts Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Kohei KaiGai <kaigai@kaigai.gr.jp>
CC: "ktm@rice.edu" <ktm@rice.edu>, Alexander Korotkov <aekorotkov@gmail.com>,
 Oleg Bartunov <obartunov@gmail.com>, Greg Smith <greg@2ndquadrant.com>,
 PgHacker <pgsql-hackers@postgresql.org>
Subject: Re: [v9.4] row level security
References: <51E8A8C1.2050700@2ndQuadrant.com>
 <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>
 <WM!685df689dd4d8f8c5349d5ef7b8e285db1e99ea32d22ab5d35f3981c29eac19dbd725c9b5e0227def9d782de274d1354!@asav-3.01.com>
 <521F7DFB.8060602@agliodbs.com>
 <CADyhKSW_o2nVWFytdTY84DUXZSuZkD_EtY2d8wAjR18UruOXYQ@mail.gmail.com>
 <WM!fb94ecb91cd381e69d8e4773d3810f48e4e0ef000525cc806c4ee509f215ce1a39c8c2a1c3ffde72ba2ddb1a07ebcdc9!@asav-2.01.com>
In-Reply-To: 
 <WM!fb94ecb91cd381e69d8e4773d3810f48e4e0ef000525cc806c4ee509f215ce1a39c8c2a1c3ffde72ba2ddb1a07ebcdc9!@asav-2.01.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 08/30/2013 03:05 AM, Kohei KaiGai wrote:

>> Surely someone in the security community has discussed this?
>>
> Security community considers covert channel is a hard to solve problem;
> nearly impossible to eliminate.
> Let's see the summary in wikipedia:
>   http://en.wikipedia.org/wiki/Covert_channel

Well, in each of the cases covered in that article, the given technology
(OSI, TCP, etc.) takes specific provisions to limit the ability of
attackers to discover information via the covert channel.

However, we have yet to talk about taking any such provisions with
Postgres.  If we commit this patch, arguably we'll have a row-level
security feature which only protects data from well-behaved users, which
seems counterproductive.

So, arguments in favor of this patch:
a) it's as good as Oracle's security features, giving us "check-box
compliance".
b) it allows securing individual rows against attackers with limited
technical knowledge or limited database access, and could be very
hardened in combination with intelligent access control.
c) it is an improvement on techniques like Veil (is it)?
d) we plan to continue improving it and closing covert channels, or
limiting their bandwidth.

Arguments against:
m) covert channels are currently broad enough to make it trivially
circumventable (are they?)
n) overhead and code maintenance required is substantial

So, determinative questions:

1) are the security mechanisms supplied by this patch superior in some
way to approaches like Veil for multi-tenant applications?  (this is a
serious question, as multi-tenant applications are far less concerned
about covert channels)

2) do we plan to reduce the accessibility of data via covert channels
over successive releases?  How?

3) will accepting this patch allow our users in the Government space to
more freely adopt PostgreSQL?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers