Re: SE-PostgreSQL and row level security

KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)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 are in 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 them on demand.

3) The data hiding scheme -- which frankly I think is dead in the water. It
amounts to a major change to the SQL semantics where 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!