Message-ID: <52240A43.3000100@2ndQuadrant.com>
Date: Sun, 01 Sep 2013 23:47:15 -0400
From: Greg Smith <greg@2ndQuadrant.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Greg Stark <stark@mit.edu>
CC: Kohei KaiGai <kaigai@kaigai.gr.jp>, Josh Berkus <josh@agliodbs.com>,
 "ktm@rice.edu" <ktm@rice.edu>, Alexander Korotkov <aekorotkov@gmail.com>,
 Oleg Bartunov <obartunov@gmail.com>,
 PgHacker <pgsql-hackers@postgresql.org>
Subject: Re: [v9.4] row level security
References: <51E8A8C1.2050700@2ndQuadrant.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>
 <52238206.2060705@agliodbs.com>
 <CADyhKSXKdH2u4qa0Tgv3qUmfuHA9MprDOVfjCxRQyqP+UcC=kg@mail.gmail.com>
 <CAM-w4HOSTZh+gZxtJt+qbiFzwFQHXMiAqZJs2rxe53H+6Nn1RA@mail.gmail.com>
In-Reply-To: 
 <CAM-w4HOSTZh+gZxtJt+qbiFzwFQHXMiAqZJs2rxe53H+6Nn1RA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 9/1/13 5:54 PM, Greg Stark wrote:
> So I think up above Tom is wrong about why it's ok that INSERT leaks
> keys when it reports a unique key violation. The reason why it's ok
> that there's a covert channel there is that the DBA can avoid that
> covert channel by being careful when creating unique constraints. He
> or she should be aware that creating a unique constraint implicitly
> provides a kind of limited access to data to users who have INSERT
> privilege even if they lack the real SELECT privilege.

And if someone can INSERT values that they can't actually see once 
they're committed, that's a similarly bad we should describe.  People 
should be dumping their trash in their neighbor's yard.  I think 
eventually this needs to be wrestled to the ground in a robust way.  I 
want to see if all unique violations might be changed to give less 
information in this sort of RLS context.

One rough early idea is to create a new error condition that means you 
hit something protected by RLS, but doesn't leak any more information 
than that.  Just a generic "Security restriction operation" that comes 
out of fishing for keys, inserting outside your area, etc.  I want to 
think through some use cases and review the code to see whether that 
concept helps or not.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers