From: Josh Berkus <josh@agliodbs.com>
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: Sun, 01 Sep 2013 11:05:58 -0700
Message-ID: <52238206.2060705@agliodbs.com> (raw)
In-Reply-To: <WM!12ab40873dea1bdff46421b93993af10c7940c289ac32373a30649be9839739492ccb794e20a8b018ced351a2e740d55!@asav-3.01.com>
References: <51E8A8C1.2050700@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>
<5220D832.7090104@agliodbs.com>
<CADyhKSWMvA-Ri7zD2gvz9bq2GiDLPQ_Hqmq86A5AL2r+em9+pw@mail.gmail.com>
<WM!12ab40873dea1bdff46421b93993af10c7940c289ac32373a30649be9839739492ccb794e20a8b018ced351a2e740d55!@asav-3.01.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Kaigai,
>> 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.
>>
> 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.
That's an astonishingly weak argument, because the bandwidth you're
talking about is still very high, as in *hundreds* or *thousands* of
values per minute. It's one thing to make the bandwidth argument for
things like monitoring power draw, where the leakage is one character
per hour, but the covert channels we're talking about are several orders
of magnitude faster than that.
So, I repeat: if you continue to pursue the argument that the covert
channels identified aren't significant because of bandwidth, you will
doom this patch. The valid arguments are only two:
a) clearly identified use case X doesn't care about covert channels for
reason Y, and will find RLS extremely useful.
b) we can't fix these covert channels now, but plan to work on them in
the future, and have ideas for how to approach them.
> Security community also concludes it is not avoidable nature as long
> as human can observe system behavior and estimate something, thus,
> security evaluation criteria does not require eliminate covert-channels
> or does not pay attention about covert-channels for the products that
> is installed on the environment with basic robustness (that means,
> non-military, regular enterprise usage).
To be completely blunt, the security community does not understand
databases. At all. I'd think if anything had become clear through the
course of work on SEPosgres, it would be that.
>> 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)
>>
> Yes. This RLS implementation targets the environment that does not
> have requirement for a particular bandwidth upperbound on covert-
> channels. It allows to centralize the place where we have to care
> about access control on main-channel, so it well fits multi-tenant
> applications.
Again, please abandon your bandwidth arguments. They are irrelevant to
whether or not this patch gets accepted.
So, please try again?
>> 3) will accepting this patch allow our users in the Government space to
>> more freely adopt PostgreSQL?
>>
> Government has two spaces. Most of their environment requires similar
> requirement as enterprise grade system doing. On the other hand,
> military environment often requires upper-bound of covert channel,
> as a story I introduce on upthread, but they are minority and have
> budget to develop special purpose database system designed for
> security with first priority.
I don't think I understood this answer. What I'm asking is: will
government agencies be sigificantly more likely to adopt PostgreSQL if
we have RLS, in this form? Or do we need "military-grade" before it
makes a difference?
--
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
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: josh@agliodbs.com, 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: <52238206.2060705@agliodbs.com>
* 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