Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VGCsU-0004WE-2q for pgsql-hackers@arkaria.postgresql.org; Sun, 01 Sep 2013 19:00:02 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VGCsT-00036Z-En for pgsql-hackers@arkaria.postgresql.org; Sun, 01 Sep 2013 19:00:01 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VGCsR-00036O-5G for pgsql-hackers@postgresql.org; Sun, 01 Sep 2013 18:59:59 +0000 Received: from tamriel.snowman.net ([2001:4830:167b::11]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VGCsJ-0006PY-IT for pgsql-hackers@postgresql.org; Sun, 01 Sep 2013 18:59:58 +0000 Received: by tamriel.snowman.net (Postfix, from userid 1000) id E5F455F77D; Sun, 1 Sep 2013 15:01:42 -0400 (EDT) Date: Sun, 1 Sep 2013 15:01:42 -0400 From: Stephen Frost To: Josh Berkus Cc: Kohei KaiGai , "ktm@rice.edu" , Alexander Korotkov , Oleg Bartunov , Greg Smith , PgHacker Subject: Re: [v9.4] row level security Message-ID: <20130901190142.GS2706@tamriel.snowman.net> References: <20130829142321.GA30496@aart.rice.edu> <521F7DFB.8060602@agliodbs.com> <5220D832.7090104@agliodbs.com> <52238206.2060705@agliodbs.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kHqR/hpBn1gMcN6E" Content-Disposition: inline In-Reply-To: <52238206.2060705@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:23:33 up 50 days, 14:33, 6 users, load average: 0.00, 0.04, 0.05 User-Agent: Mutt/1.5.21 (2010-09-15) X-Pg-Spam-Score: -4.3 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org --kHqR/hpBn1gMcN6E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Josh, * Josh Berkus (josh@agliodbs.com) wrote: > 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. =20 I agree that, in this specific case, we should do something about it. > 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. That's actually not an accurate representation of the bandwidth associated with power draw measurements, but even if I convinced you it was in the hundreds or thousands of values per minute, I doubt you'd change your mind regarding the Filtered Rows issue or claim that we should fix the power draw measurement issue. :) > 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: There is actually another argument, which I mentioned up-thread.. There are cases where you can't guarantee all the promises which can be asked for. In the unique-value case, we can't guarantee both that the values are unique and that existing values can't be detected by an individual with insert access. We should make the user aware that allowing insert access (or perhaps 'explain') opens up these cases. > a) clearly identified use case X doesn't care about covert channels for > reason Y, and will find RLS extremely useful. These certainly exist and I'd argue that's part of why Veil exists.. Users of Veil (which I admit, I'm not) would likely be much happier with an in-core solution because it will be much easier to use and much more performant. > 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. I expect we will find more covert chanels which need to be fixed. > 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. That's just false and it's poor of you to claim it. The security community is not one individual nor even some small group. They're not very obviously involved with PostgreSQL but that's no reason to claim that they do not understand databases. > 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? =46rom my experience, the answer would be 'yes' to your first question. Thanks, Stephen --kHqR/hpBn1gMcN6E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlIjjxYACgkQrzgMPqB3kigDhwCdE6EX2wIAUP6387+I3PCymxhs t48An3QDwlnWnklWFiOjw/cSDQE91cKF =Wgft -----END PGP SIGNATURE----- --kHqR/hpBn1gMcN6E--