On Mon, Feb 16, 2009 at 12:08 PM, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
>>>> 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.
No, I claim it's you that's confounding the data hiding scheme with
row-level granular access controls.
If a user types "SELECT count(*) from table" they should either get
the correct count of records from that table or get a permission
failure.
If they want to get the count of records for which they have read
access they should have to write "SELECT count(*) from table where
access_check(security_label, current_user())" or something like that.
The only reason to make the above automatic is to hide from the user
the fact that there are records they're not seeing. Since we can't do
that effectively there's no point in having it at all, especially
since it breaks the interpretation of the query in ways that interfere
with other functionality.
--
greg