From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: 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: Fri, 30 Aug 2013 16:24:06 -0400
Message-ID: <20130830202406.GP2706@tamriel.snowman.net> (raw)
In-Reply-To: <16798.1377891794@sss.pgh.pa.us>
References: <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>
<20130830192729.GO2706@tamriel.snowman.net>
<16798.1377891794@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > We have issues with covert channels even without RLS though and holding
> > up RLS because it doesn't fix all the covert channels isn't sensible.
>
> I think it's entirely sensible to question whether we should reject (not
> "hold up") RLS if it has major covert-channel problems.
Rejecting RLS because we've suddently realized that covert channels
exist is foolishness. It's akin to rejecting the ability to add stored
procedures because we don't protect prosrc from people who don't own or
can't execute the function.
> The scenario I'm worried about is where somebody says "hey, Postgres has
> RLS now, I can rely on that to hide my sooper sekrit data from other users
> in the same database", and later they have a security breach through some
> covert-channel attack. Are they going to blame themselves? No, they're
> gonna blame Postgres. Or consider the case where some bozo publishes
> a method for such an attack and uses it to badmouth us as insecure.
In my experience, issues are discovered, patched, and released as
security updates. Does adding RLS mean we might have more of those?
Sure, as did column level privileges and as does *any* such increase in
the granularity of what we can provide security-wise.
> I don't think we need the headaches that will result from promising
> (or at least appearing to promise) something we can't deliver. Nor am
> I convinced that we're really doing users any favors by providing such a
> feature. They'd be *far* better advised to put their critical data in a
> separate database.
We've barely got cross-database queries with FDWs. The notion that
adding such complexity into those as RLS, which each individual user
will need to figure out how to do themselves and most will likely get
far wrong and much worse than what we'd implement, is "better" for
our users is just ridiculous.
> In short, "we can check some check-box" is a really, really bad reason
> to accept a security-related feature. If we're going to put up with
> all the downsides of RLS, I want the end result to be something that's
> actually secure, not something that gives the illusion of security.
> And right now, I do not believe we can get past the illusion stage,
> ever (certainly not in a release or two).
I'm not argueing for this because it fulfills some check-box; the
question about if it would help a given set of clients (ones which I no
longer have any direct relationship with, as it turns out) adopt PG was
asked and I answered it as best I could.
I certainly think we need to get past the 'illusion' stage also. I'm
certainly more optimistic about that than you are but I also understand
it's not going to be perfect in the first release- but I do think it'll
be better than the 'illusion' stage. It'll get there because we'll
continue to discuss it, people will test it, etc; as one hopes happens
with all new features, but this even more than others.
Thanks,
Stephen
Attachments:
[application/pgp-signature] signature.asc (197B, ../20130830202406.GP2706@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, tgl@sss.pgh.pa.us, 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: <20130830202406.GP2706@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