Re: SE-PostgreSQL and row level security

KaiGai Kohei <kaigai@ak.jp.nec.com> writes:

> Martijn van Oosterhout wrote:
>> On Mon, Feb 16, 2009 at 11:10:19AM +0900, KaiGai Kohei wrote:
>>> At the previous discussion, two items were pointed out.
>>>
>>> The one is called as covert channel. When a tuple with PK is refered by
>>> one or more tuples with FK, row-level control prevents to update or delete
>>> the PK, even if the FK is invisible from users. It allows users to infer
>>> existence of invisible FK. 
>> 
>> One thing I keep missing in this discussion: the term "row-level
>> security" in the above senstence in not the important part. Right now
>> you can revoke SELECT permission on a table with a foreign key and it
>> will still prevent UPDATEs and DELETEs of the primary key, allowing
>> users to infer the existance of an invisible FK.
>> 
>> This is the same "covert channel", so why is it a problem for
>> SE-Postgres and not for normal Postgres?
>
> Please note that I don't consider it is a problem, even if SE-PostgreSQL.
>
> Both of SE-PostgreSQL and vanilla PostgreSQL don't give an assurance to
> eliminate information leaks via such kind of covert channels, so they
> don't violate any specifications of them. Thus, it is not a problem.

If that's true then I don't see why we would try to automatically hide records
you don't have access to. The only reason to do so is to try to close these
covert channels and if we can't do that then I don't see any benefit to doing
so. 

If users want to select "all matching records the user has access to" they
should just put that in the WHERE clause (and we should provide a convenient
function to do so). If we implicitly put it in the WHERE clause then
effectively we're providing incorrect answers to the SQL query they did
submit.

This is a big part of the "breaking SQL semantics" argument. Since the
automatic row hiding provides different answers than the SQL query is really
requesting it means we can't trust the results to follow the usual rules.

I think there's more to it though. Tom pointed out some respects in which the
hooks are too late and too low level to really know what privilege set is in
effect. The existing security checks are all performed earlier in plan
execution, not at low level row access routines. This is a more fundamental
change which you'll have to address before for *any* row level security scheme
even without the automatic data hiding.

So, assuming the SELinux integration for existing security checks is committed
for 8.4 I think the things you need to address for 8.5 will be:

1) Row level security checks in general (whether SELinux or native Postgres  security model) and showing that the hooks
arein the right places for  Tom's concerns.
 

2) Dealing with the scaling to security labels for billions of objects and  dealing with garbage collecting unused
labels.I think it might be simpler  to have security labels be explicitly allocated and dropped instead of  creating
themon demand.
 

3) The data hiding scheme -- which frankly I think is dead in the water. It  amounts to a major change to the SQL
semanticswhere every query  effectively has a volatile function in it which produces different answers  for different
users.And it doesn't accomplish anything since the covert  channels it attempts to address are still open.
 

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!