Re: SE-PostgreSQL and row level security

>>> 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. 

It is incorrect.
It seems to me you confound a covert channel and granularity in access
controls. The purpose of row-level security is to provide users more
flexibility in access controls, not related to covert channels.

> 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.

When he want to see all the tuple within a relation, it is necessary to
invoke SQL query with highest privileges.

Since we don't have row-level granularity now, same query always returns
same result (if client has enough privileges on tables/columns) due to
the uniform access controls on tuples.
But, it is not correct when once we have the row-level granulariry.

Could you imagine a case when we see a table via a view with a condition
depending on user's identifier. I don't think it breaks something.
In fact, prior commercial database with row-level security (Oracle, DB2)
adopts similar way which implicitly modify WHERE clause.

> 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.

SE-PostgreSQL also checks table/column level privilges on the head of plan
execution, as if the existing security checks doing. Please check my patches.
(It is also same in r1530.)

At first, please note that the existing security checks don't have row-level
granularity now. So, it is necessary to add a condition on WHERE clause, or
add a trigger on target relations, as BogDan did at first.
(At least, it is a simple way to achive row-level controls now.)
SE-PostgreSQL checks reader permission on tuples just after evaluation of
conditional clause on ExecScan(), and also checks writter permission just
after before-row triggers invoked.
I don't think it is too late. Please note that we cannot know what tuples
are accessed until we actually execute the given query.

> 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:

Anyway, the reason why we postponed row-level features was lack of time
to review, to discuss, to conclude and others.
I don't forget to open discussion these issue on the v8.5 development cycle.
However, I think it is unproductive to heat up row-level facilities before
the first step.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>