Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VF375-0001Ft-5B for pgsql-hackers@arkaria.postgresql.org; Thu, 29 Aug 2013 14:22:19 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VF374-0008C4-CF for pgsql-hackers@arkaria.postgresql.org; Thu, 29 Aug 2013 14:22:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VF373-0008Bv-6Y for pgsql-hackers@postgresql.org; Thu, 29 Aug 2013 14:22:17 +0000 Received: from proofpoint1.mail.rice.edu ([128.42.201.100] helo=pp1.rice.edu) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VF36x-0005Sz-72 for pgsql-hackers@postgresql.org; Thu, 29 Aug 2013 14:22:16 +0000 Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id r7T8fh1F013152; Thu, 29 Aug 2013 09:22:03 -0500 Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by pp1.rice.edu with ESMTP id 1eh1mbs12c-1; Thu, 29 Aug 2013 09:22:03 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh3.mail.rice.edu, auth channel X-SMTP-Auth: no X-SMTP-Auth: no X-SMTP-Auth: no X-SMTP-Auth: no X-SMTP-Auth: no Received: from aart.rice.edu (aart.rice.edu [168.7.56.48]) by mh3.mail.rice.edu (Postfix) with ESMTP id 84F814017B; Thu, 29 Aug 2013 09:22:03 -0500 (CDT) Received: by aart.rice.edu (Postfix, from userid 18612) id 0BE0C10063D; Thu, 29 Aug 2013 09:23:21 -0500 (CDT) Date: Thu, 29 Aug 2013 09:23:21 -0500 From: "ktm@rice.edu" To: Kohei KaiGai Cc: Alexander Korotkov , Oleg Bartunov , Greg Smith , PgHacker Subject: Re: [v9.4] row level security Message-ID: <20130829142321.GA30496@aart.rice.edu> References: <51E8A8C1.2050700@2ndQuadrant.com> <20130719030347.GV15510@tamriel.snowman.net> <51E8ADD9.5020600@2ndQuadrant.com> <521D1C2B.8090503@2ndQuadrant.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) X-Pg-Spam-Score: -4.4 (----) 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 On Thu, Aug 29, 2013 at 04:14:53PM +0200, Kohei KaiGai wrote: > 2013/8/29 Alexander Korotkov : > > On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote: > >> > >> 2013/8/28 Oleg Bartunov : > >> > btw, there is serious problem with row-level security and constraints. > >> > For > >> > example, user with low security level could use unique constraint to > >> > know > >> > about existence of a row with higher security. I don't know, what is > >> > the > >> > best practice to avoid this. > >> > ... > > > A principle of this row-level security feature is, it prohibits to > leak invisible > datum itself, but might allow users to expect existence of records with > a particular value. In fact, we never push down function that may leak > the given argument, that does not have leakproof attribute, even if it can > be utilized for index-scan. > My opinion is, we should deal with it is "a limitation" of this feature, as > long as it does not expose the raw data to be hidden. Estimation takes > time to carry out much hidden data via covert channel, thus traditional > secure operating system specification with MAC implementation says > its degree of threat is not significant as long as bandwidth of covert > channel is not so much. I think it is a reasonable standpoint. > > Thanks, > -- > KaiGai Kohei > Okay, given that argument, how would you monitor such attempts to access data through the covert channel and shut it down? Regards, Ken -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers