Uh ... why not just drop the constraint, and re-add it later if you want
it again?
My 0.02¤ : maybe because you must keep track of the constraint details to
do so, this it is significantly more error prone than disable / enable
when the bookkeeping is done by the system and if everything is in a
transaction... If the ENABLE is automatically done on the next COMMIT,
that would be even better.
This seems like adding a lot of mechanism (and possible bugs) for a
rather marginal use-case.
That is possible!

--
Fabien.
From pgsql-hackers-owner@postgresql.org Fri Aug 30 19:25:45 2013
Received: from makus.postgresql.org ([2001:4800:7903:4::125])
  by malur.postgresql.org with esmtp (Exim 4.80)
  (envelope-from <sfrost@tamriel.snowman.net>)
  id 1VFUKF-00012n-Rn
  for pgsql-hackers@postgresql.org; Fri, 30 Aug 2013 19:25:43 +0000
Received: from tamriel.snowman.net ([2001:4830:167b::11])
  by makus.postgresql.org with esmtp (Exim 4.80)
  (envelope-from <sfrost@tamriel.snowman.net>)
  id 1VFUKC-0007Xe-Tx
  for pgsql-hackers@postgresql.org; Fri, 30 Aug 2013 19:25:43 +0000
Received: by tamriel.snowman.net (Postfix, from userid 1000)
  id 7908B5F77D; Fri, 30 Aug 2013 15:27:29 -0400 (EDT)
Date: Fri, 30 Aug 2013 15:27:29 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Josh Berkus <josh@agliodbs.com>
Cc: Kohei KaiGai <kaigai@kaigai.gr.jp>, "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
Message-ID: <20130830192729.go2706@tamriel.snowman.net>
References: <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
  protocol="application/pgp-signature"; boundary="XtiAonEK111imN34"
Content-Disposition: inline
In-Reply-To: <5220d832.7090104@agliodbs.com>
X-Editor: Vim http://www.vim.org/
X-Info: http://www.snowman.net
X-Operating-System: Linux/3.8.0-25-generic (x86_64)
X-Uptime: 14:55:50 up 48 days, 15:05, 6 users, load average: 0.10, 0.07,
  0.06
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Pg-Spam-Score: -4.0 (----)
X-Archive-Number: 201308/1389
X-Sequence-Number: 232954


--XtiAonEK111imN34
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Josh,

* Josh Berkus (josh@agliodbs.com) wrote:
On 08/30/2013 03:05 AM, Kohei KaiGai wrote:
Security community considers covert channel is a hard to solve problem;
nearly impossible to eliminate.
While impossible to eliminate, we should certainly consider cases like
this where we can do better and fix them. RLS certainly brings another
level of consideration to the overall PG security environment by
requiring we think about security on a row level rather than just a
table or column level.

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.
Column-level privleges have a similar problem, where you can read the
default value for a column using the catalogs. Perhaps the default
isn't sensetive (you'd certainly hope not), but it's still an issue. It
wouldn't surprise me to find that there are ways to abuse a multi-column
index which includes both a column you can manipulate and one you don't
have access to read to determine something about the hidden column
(maybe you have access to the 2nd field in the index and you can
encourage an in-order index traversal and then look at filtered rows, or
just work out a way to do timing attacks to determine the btree depth).
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.
The work we've done around secure views would lend credit to our
attempts at taking specific provisions as well; sadly, PG is slightly
more complicated than TCP. We do what we can and we've got a great
community which will point out where we can do better- and we work on it
and improve over time. Hell, when roles were first added we had a
*massive* security hole because we didn't check to make sure we weren't
overrunning the length of the GUC. It was a mistake and we should have
done better, but that doesn't mean adding roles was the wrong decision.
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.
I would argue both that we *have* been taking provisions to avoid
obvious and big covert channels, and that this patch adds value even
if it doesn't protect the system perfectly from malicious users. We're
all certainly aware of the ability for an attacker to cause major
problems to a PG system if they can issue arbitrary SQL and our
permissions system doesn't do much to protect us. A single query which
doesn't require any privileges could cause havok on the system (massive
on-disk temp file, which could be shared with pg_xlog causing the system
to PANIC, massive CPU load if they can execute multiple commands in
parallel...). Not to mention the default installation of pl/pgsql and
anonymous functions.

I could see many a web app (things like LedgerSMB) which could benefit
=66rom having more fine-grained in-database control because they already
authenticate to the database as the user and have a static or at least
controlled set of queries which they run. Today, any of those kinds of
systems have to implement their own RLS (though sometimes it's done
through independent tables for each customer or similar, rather than as
conditionals added to queries).
a) it's as good as Oracle's security features, giving us "check-box
compliance".
I'd argue that this is definitely much more than '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.
=20
Arguments against:
m) covert channels are currently broad enough to make it trivially
circumventable (are they?)
There are some which are and likely deserve to be fixed. Do they all
need to be addressed before this patch goes in? I'd argue 'no'.
n) overhead and code maintenance required is substantial
=20
So, determinative questions:
=20
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)
I'd argue 'yes' if just for the fact that it'd be simpler and easier to
use, both because it's in core and because you're using an actual
grammar instead of function calls- but this RLS does more than just
that, it's going to cause us to improve things that Veil probably can't
fix and simply ignores today.
2) do we plan to reduce the accessibility of data via covert channels
over successive releases? How?
By discovering them and fixing them as we go..? I can't imagine there
being one massive patch which goes into a single major release that
fixes *all* of them- there's going to be ones we can't even imagine
today that we discover later. Should we fix *all* of the ones that we
discover? Probably not- it's simply not possible. Should we fix the
ones that we can easily correct? Of course.
3) will accepting this patch allow our users in the Government space to
more freely adopt PostgreSQL?
There's two parts to this. On the one hand, the 'check-box' would be
filled, which by itself would make it easier (at least based on my
experience w/ the US gov't, ymmv), but also because it would require
*less work* to build a new application on PG which needed RLS. You can
already do it today, but you have to bake that into the cost of the
implementation of the overall application and accept the limitations
which come with it- trivally gotten around once you get a direct
connection to PG. Would this be perfect? No, but it'd be quite a bit
better.

  Thanks,

   Stephen

--XtiAonEK111imN34
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature



--XtiAonEK111imN34--

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 4 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedAug 30, '13 at 1:58a
activeAug 30, '13 at 6:57p
posts4
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase